Amazon ANS-C01: Производительность сети и мониторинг — Руководство по подготовке
Часть AWS Advanced Networking Specialty ANS-C01 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Amazon, или пройдите тесты на время на ExamRoll.io.
Улучшенная сетевая производительность и низколатентная среда
Улучшенная сетевая производительность (Enhanced networking) в AWS — это набор функций на уровне ОС и гипервизора, которые значительно увеличивают количество пакетов в секунду (packets-per-second), снижают задержку и нагрузку на ЦП, а также обеспечивают более высокую пропускную способность на каждый виртуальный интерфейс. Основными технологиями являются Elastic Network Adapter (ENA), который обеспечивает высокопроизводительную сеть на базе SR-IOV для большинства современных семейств инстансов EC2, и Elastic Fabric Adapter (EFA), который представляет собой устройство с обходом ОС (OS-bypass), подобное RDMA, и предназначен для HPC и тесно связанных рабочих нагрузок MPI/libfabric. Чтобы включить ENA, необходимо убедиться, что тип инстанса поддерживает ENA и что в Linux AMI есть драйвер ENA; программно его можно включить или запросить с помощью вызовов EC2 API, таких как RunInstances с параметром InterfaceType=efa, когда это необходимо, или ModifyInstanceAttribute для поддержки ena. EFA подключается путем создания сетевого интерфейса с InterfaceType=efa (aws ec2 create-network-interface –interface-type efa) или запуска инстансов с сетевым интерфейсом, поддерживающим EFA; инстанс должен работать под управлением поддерживаемого ядра с модулем ядра libfabric/efa и обычно размещаться в группе размещения cluster (cluster placement group) для получения минимальной задержки между хостами и максимальной двунаправленной пропускной способности (bisection bandwidth).
Группы размещения (Placement groups) влияют на производительность, контролируя размещение инстансов в базовой сетевой среде. Группа размещения cluster размещает инстансы на одной стойке или в сетевом домене с низкой задержкой, чтобы обеспечить максимальную пропускную способность в горизонтальном направлении (east-west bandwidth) и стабильную задержку — это требуется для многих сценариев использования EFA. Группа размещения spread обеспечивает распределение на уровне хостов, чтобы избежать коррелированных сбоев, но не улучшает задержку. Для сценариев с пиковой высокой пропускной способностью семейство инстансов и количество vCPU определяют базовые квоты на пропускную способность сети; например, для некоторых размеров инстансов заявлена скорость до 25 Гбит/с или 100 Гбит/с, но обработка пакетов и стеки TCP могут стать узким местом без ENA/EFA. При проектировании систем для тысяч одновременных TCP-соединений (например, gRPC через TLS) выбирайте типы инстансов с высокой емкостью одновременных подключений, включайте ENA и отдавайте предпочтение NLB с target-type=ip для прямой адресации подов при работе в EKS, чтобы избежать узких мест в портах узлов (node port).
Ключевые сервисы и конфигурации для наблюдаемости и контроля
Мониторинг состояния сети и диагностика узких мест основываются на комбинации VPC Flow Logs, метрик CloudWatch, Traffic Mirroring и анализаторов Reachability/Access Analyzer. VPC Flow Logs предоставляют метаданные для каждого потока (IP-адреса источника/назначения, порты, пакеты, байты, действие), которые можно отправлять в CloudWatch Logs или S3 и запрашивать с помощью CloudWatch Logs Insights для поиска префиксов с большим объемом трафика или самых активных источников («top talkers»). Для инспекции на уровне пакетов в реальном времени Traffic Mirroring позволяет создать цель зеркалирования (mirror target) и фильтр, а затем создавать сессии (aws ec2 create-traffic-mirror-target, aws ec2 create-traffic-mirror-session) для копирования трафика с ENI на инспектирующее устройство, работающее в EC2, или партнерам AWS Network Packet Broker.
CloudWatch предоставляет релевантные метрики для разных уровней: метрики инстансов EC2, такие как NetworkIn/NetworkOut и NetworkPacketsIn/NetworkPacketsOut, метрики Application Load Balancer в пространстве имен AWS/ApplicationELB, например RequestCount, ActiveConnectionCount и ClientTLSNegotiationErrorCount, метрики Network Load Balancer в AWS/NetworkELB, такие как ProcessedBytes и NewFlowCount, и метрики AWS/DirectConnect для виртуального интерфейса, например BytesIn/BytesOut. Используйте CloudWatch Alarms и Contributor Insights для журналов потоков (flow logs), чтобы обнаруживать потоки, вызывающие насыщение канала. Для проверки путей и конфигурации Reachability Analyzer (через EC2 API StartNetworkInsightsAnalysis / CreateNetworkInsightsPath) позволяет моделировать и тестировать сквозные пути прохождения пакетов через таблицы маршрутизации, NACL, группы безопасности и подключения VPN/Direct Connect, в то время как Network Access Analyzer помогает обнаруживать непреднамеренные пути доступа к сети в ваших VPC и AWS Organizations.
Архитектурные шаблоны и компромиссы для балансировки нагрузки и безопасного доступа
Когда вам требуется настоящее сквозное шифрование TLS с взаимной аутентификацией (mutual TLS) на бэкенде при поддержке тысяч gRPC-соединений, предпочтительным шаблоном является использование Network Load Balancer в режиме TCP. NLB по умолчанию сохраняет исходный IP-адрес клиента и может быть создан контроллером AWS Load Balancer Controller для сервисов EKS с использованием аннотаций, таких как
undefined
и target-type=ip, для отправки трафика напрямую на IP-адреса подов. Использование проброса TCP-трафика (passthrough) через порт 443 означает, что бэкенд-под терминирует mutual TLS (проверяя сертификаты клиента и сервера), поэтому трафик никогда не расшифровывается в балансировщике нагрузки, сохраняя двустороннюю аутентификацию. Этот шаблон хорошо масштабируется по количеству соединений, поскольку NLB разработан для миллионов одновременных соединений и имеет низкие накладные расходы на каждое соединение.
Для архитектур, требующих терминирования TLS на балансировщике нагрузки и маршрутизации на основе пути к нескольким целевым группам (target groups), правильным выбором будет Application Load Balancer, поскольку он поддерживает HTTP/2 и gRPC, маршрутизацию на основе пути и правила на основе хоста. Чтобы обеспечить точное логирование IP-адресов клиентов при терминировании TLS на ALB, убедитесь, что бэкенд-приложение анализирует заголовки X-Forwarded-For (ALB добавляет их автоматически), или используйте протокол PROXY с NLB, если вам нужно сохранить исходный IP-адрес на уровне TCP. Если вы используете Global Accelerator для предоставления статических anycast IP-адресов и хотите предотвратить обход ускорителя клиентами и прямое обращение к URL-адресу ALB, ограничьте группу безопасности ALB, чтобы она принимала входящий трафик только со статических IP-адресов Global Accelerator (двух статических адресов, назначенных ускорителю), таким образом, прямой доступ из интернета будет запрещен.
Для общих сервисов в мультиаккаунтной среде со строгим контролем для каждого бизнес-подразделения и высокими требованиями к масштабированию AWS PrivateLink (сервисы VPC Endpoint, работающие на базе внутренних NLB) часто является наиболее безопасным и масштабируемым шаблоном. VPC с общими сервисами публикует их через эндпоинты Network Load Balancer (
undefined
с целевыми группами) и предоставляет их как сервис VPC Endpoint. Аккаунты-потребители создают в своих VPC интерфейсные эндпоинты (interface endpoints), которые подключаются к NLB провайдера; провайдер контролирует доступ с помощью политик эндпоинтов и групп безопасности, и трафик никогда не проходит через централизованный уровень маршрутизации. Transit Gateway подходит, когда вам нужна полная видимость маршрутизации и транзитивное соединение, но он централизует маршрутизацию и обеспечивает менее гранулярный контроль доступа к отдельным сервисам по сравнению с PrivateLink.
Распространенные ошибки и критерии принятия решений
Распространенная ошибка — предполагать, что заявленная пропускная способность инстанса не ограничена; семейства и размеры инстансов устанавливают жесткие сетевые ограничения, и при масштабировании следует учитывать распределение нагрузки по нескольким ENI и размещение в cluster placement groups для обеспечения стабильной производительности. Другая типичная ошибка — полагаться исключительно на метрики CloudWatch NetworkIn/NetworkOut, не сопоставляя их с VPC Flow Logs для атрибуции трафика к конкретному VPC, подсети или бизнес-подразделению; Flow Logs и Traffic Mirroring необходимы, чтобы определить, какой именно виртуальный интерфейс или приложение вызывает перегрузку Direct Connect. Также избегайте терминирования TLS на ALB, когда требуется сквозное взаимное TLS-шифрование (mutual TLS). Если политика требует, чтобы бэкенд видел сертификат клиента, выбирайте сквозную передачу TLS (TLS passthrough) с помощью NLB или выполняйте TLS-бриджинг с надлежащей проверкой сертификатов, но при этом четко определяйте, где устанавливаются отношения доверия.
При диагностике периодических перегрузок на общих физических каналах, таких как Direct Connect, сопоставляйте метрики на разных уровнях: метрики AWS/DirectConnect для виртуальных интерфейсов, VPC Flow Logs для подсчета байтов по подсетям/ENI и метрики EC2 Network* для анализа поведения на уровне инстансов. Используйте Reachability Analyzer, чтобы проверить, не вызваны ли проблемы с обратным маршрутом асимметричной маршрутизацией или неверным распространением маршрутов, и применяйте Traffic Mirroring для захвата дампов пакетов с целью глубокого анализа протоколов.
Практическая задача: сценарий использования
Компания AcmeIoT столкнулась с проблемой: торговые автоматы по всему миру должны подключаться по gRPC с использованием mutual TLS к бэкенду, размещенному в EKS. Количество подключений должно исчисляться тысячами, сервис должен оставаться зашифрованным на всем пути (end-to-end), а поды бэкенда должны динамически масштабироваться с помощью Cluster Autoscaler и HPA.
Создайте AWS LoadBalancer типа Network Load Balancer для сервиса Kubernetes, используя AWS Load Balancer Controller и аннотации, чтобы указать тип NLB и
target-type=ip(service.beta.kubernetes.io/aws-load-balancer-type: "nlb"иservice.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"). Настройте TCP-прослушиватель на порту 443, чтобы NLB выполнял чистую сквозную передачу TCP (TCP passthrough); не настраивайте TLS-сертификаты на NLB.Реализуйте терминирование и проверку mutual TLS в подах приложения. Каждый под должен предоставлять серверный сертификат и проверять клиентские сертификаты, используя процесс ротации сертификатов с коротким сроком жизни, интегрированный с AWS Secrets Manager или SSM Parameter Store. Убедитесь, что IP-адреса подов доступны, используя
target-type ip, и что проверки состояния, настроенные в целевой группе (target group), являются проверками TCP или gRPC.Обеспечьте высокую масштабируемость подключений, выбрав инстансы с поддержкой ENA и достаточной пропускной способностью сети. Включите ENA (убедитесь в наличии драйвера ENA в AMI и используйте
aws ec2 modify-instance-attributeдля включенияena-supportпри необходимости) и развертывайте поды на нескольких узлах, при этом Cluster Autoscaler должен масштабировать узлы на основе запросов подов. Используйте placement groups для тесно связанных кластеров, требующих стабильной задержки, и развертывайте достаточное количество узлов в разных зонах доступности (AZ).Выполняйте мониторинг и проверку с помощью CloudWatch и VPC Flow Logs. Создайте метрики и оповещения CloudWatch для
ActiveFlowCount/NewFlowCountбалансировщика NLB иNetworkIn/Outдля рабочих узлов EKS (EC2). Используйте VPC Flow Logs для выявления наиболее активных источников трафика (top-talkers) и Reachability Analyzer (StartNetworkInsightsAnalysis/CreateNetworkInsightsPath) для проверки путей маршрутизации во время событий автомасштабирования. Если требуется отладка на уровне пакетов, создайте сеансы Traffic Mirroring, направляющие трафик на инстанс для анализа.
Обоснование со стороны AWS: Network Load Balancer в режиме TCP сохраняет исходный IP-адрес, поддерживает огромное количество одновременных подключений и обеспечивает сквозное TLS-шифрование, поскольку не терминирует TLS. Target-type ip вместе с AWS Load Balancer Controller интегрируется с семантикой автомасштабирования EKS, благодаря чему IP-адреса новых подов динамически регистрируются в качестве целевых объектов (targets). ENA и правильный подбор размера инстанса обеспечивают необходимую сетевую производительность для обработки тысяч одновременных TLS-подключений без исчерпания ресурсов CPU хоста, а комбинация CloudWatch, VPC Flow Logs, Reachability Analyzer и Traffic Mirroring предоставляет наблюдаемость, необходимую для обнаружения и устранения перегрузок или проблем с маршрутизацией.
← Доставка контента и периферийные сети · Все домены · Автоматизация →
Отработать эти вопросы → · Тесты на время на ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Сдайте экзамен →