Microsoft AZ-104: Балансировка нагрузки Azure и управление трафиком — Руководство по подготовке

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Часть Microsoft Azure Administrator Associate AZ-104 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Azure предлагает многоуровневый портфель решений для распределения и защиты трафика: Azure Load Balancer (уровень 4, TCP/UDP), Application Gateway (уровень 7, HTTP/S), Azure Front Door (глобальный пограничный сервис уровня 7), Azure Traffic Manager (на основе DNS) и Azure CDN (пограничное кэширование). Каждый из них нацелен на определенный сегмент пути запроса — от принятия решений на уровне глобального DNS и пограничных точек присутствия (POP) до региональной маршрутизации HTTP и внутреннего трафика «восток-запад». Мастерство заключается в выборе правильного сервиса для конкретного протокола и аудитории, их грамотной компоновке и настройке проб работоспособности и правил, обеспечивающих надежное аварийное переключение.

Azure Load Balancer (L4): SKU, составные блоки, NAT/исходящий трафик и плавающий IP

Standard Load Balancer — это L4-балансировщик нагрузки производственного уровня. Он поддерживает зоны доступности/избыточность между зонами, порты высокой доступности (HA Ports), расширенную диагностику/метрики, безопасность по умолчанию (входящий трафик запрещен, пока не определены правила), настраиваемые правила для исходящего трафика и масштабирование до большого числа бэкендов. Basic — это устаревший SKU с ограниченным масштабом/функциональностью и без избыточности между зонами; он выводится из эксплуатации и не должен выбираться для новых рабочих нагрузок.

Основные компоненты определяют, как проходит трафик:

• Frontend IP: VIP-адрес, доступный клиентам. Внешние балансировщики используют Public IP или Public IP Prefix; внутренние — статический частный IP-адрес из подсети. Standard поддерживает несколько frontend-интерфейсов и избыточные между зонами публичные IP-адреса.
• Backend pool: Сетевые интерфейсы (NIC), их IP-конфигурации или экземпляры VM scale set в том же регионе/VNet. Один пул может обслуживать множество правил. Standard поддерживает бэкенды в разных зонах доступности в пределах одного региона.
• Health probes (Пробы работоспособности): Определяют, какие экземпляры бэкенда работоспособны. TCP-пробы выполняют полное рукопожатие; HTTP/HTTPS-пробы отправляют GET-запрос по указанному пути и считают успешным ответ с кодом 200–399. Вы управляете протоколом, портом, путем (для HTTP/S), интервалом и порогом неработоспособности (количество последовательных сбоев, после которого экземпляр помечается как неработоспособный).
• Load balancing rules (Правила балансировки нагрузки): Связывают frontend (IP/порт/протокол) с пулом бэкендов и пробой работоспособности. Настройки правила включают порт бэкенда, протокол (TCP/UDP), сохранение сеанса (session persistence), тайм-аут простоя (idle timeout) и плавающий IP (Floating IP / Direct Server Return).

Правила Inbound NAT — это трансляции для конкретных ВМ, которые перенаправляют трафик с определенного порта frontend на один сетевой интерфейс/порт бэкенда (например, для предоставления доступа по RDP или SSH к одной ВМ без балансировки нагрузки). Они не используют пробы работоспособности и не являются механизмом масштабирования.

Правила для исходящего трафика (Outbound rules) определяют поведение SNAT для бэкендов Standard Load Balancer, инициирующих подключения к интернету через публичные frontend-интерфейсы балансировщика. Они позволяют контролировать, какие frontend-интерфейсы предоставляют порты для SNAT и сколько портов выделяется на каждый экземпляр бэкенда, помогая избежать исчерпания портов SNAT при высокой нагрузке исходящих подключений. Если к подсети подключен NAT Gateway, он имеет приоритет над SNAT балансировщика; для стабильного и масштабируемого исходящего трафика предпочтительнее использовать NAT Gateway.

Floating IP (Direct Server Return) — это опция в правиле, используемая, когда IP-адрес/порт назначения должны сохраняться на всем пути трафика. Это необходимо для кластерных сценариев, таких как прослушиватели групп доступности SQL Server Always On. Для SQL AG используйте внутренний Standard Load Balancer с TCP-пробой (не HTTP) на порт пробы кластера и включите Floating IP в правиле балансировщика; не проверяйте порт 1433 с помощью HTTP, так как SQL не является HTTP-нагрузкой.

Выбор между внутренним и внешним балансировщиком нагрузки зависит от аудитории и периметра безопасности. Используйте внутренний балансировщик (internal LB) для предоставления доступа к частному VIP-адресу внутри VNet или через частное подключение (VPN/ExpressRoute) для бизнес-приложений, баз данных и сетевых виртуальных модулей (NVA). Используйте внешний балансировщик (external LB) для L4-сервисов, доступных из интернета. Для внутренних балансировщиков назначьте статический частный frontend-адрес в целевой подсети; для внешних — привяжите Standard Public IP и при необходимости используйте несколько frontend-интерфейсов.

Cross-region Load Balancer обеспечивает глобальную anycast-балансировку нагрузки уровня 4 между регионами. Вы развертываете Standard Public Load Balancer в каждом регионе (региональный уровень) и помещаете их публичные frontend-интерфейсы в бэкенд единого глобального балансировщика нагрузки (глобальный уровень). Глобальный балансировщик использует пробы работоспособности для каждого регионального балансировщика и направляет клиентов в ближайший работоспособный регион (по задержке), обеспечивая симметрию потоков на основе хеширования 5 кортежей (5-tuple hashing). Он работает только с TCP/UDP — без терминирования TLS — и дополняет региональные шлюзы L7.

Application Gateway (L7) и Azure Front Door (глобальный L7)

Application Gateway — это региональный обратный прокси-сервер 7-го уровня (L7) с WAF. Он терминирует HTTP/HTTPS-трафик, проверяет заголовки и пути, а затем направляет запросы на частные или публичные бэкенды.

Ключевые компоненты Application Gateway:

• Прослушиватели (Listeners): Привязывают внешний IP-адрес/порт/имя хоста и параметры SSL для приема трафика. SNI позволяет размещать несколько сайтов с TLS на одном IP-адресе. Используйте базовые прослушиватели для одного сайта, многосайтовые (multi-site) — для маршрутизации на основе хоста, и wildcard-хосты для широкого охвата.
• Правила маршрутизации и настройки HTTP: Правила сопоставляют прослушиватели с пулами бэкендов и определяют настройки HTTP, применяемые к бэкендам (протокол, порт, переопределение заголовка хоста, привязка сеанса на основе cookie, плавное закрытие соединений, тайм-аут запроса). Вы можете перенаправлять, перезаписывать заголовки или маршрутизировать трафик на основе сегментов пути URL.
• Пулы бэкендов (Backend pools): Целями могут быть IP-адреса сетевых интерфейсов (NIC), полные доменные имена (FQDN), службы приложений или масштабируемые наборы виртуальных машин. Пользовательские пробы работоспособности проверяют определенные пути/хосты и учитывают успешные коды состояния.
• WAF: Защита на основе набора основных правил OWASP (Core Rule Set) в режиме обнаружения или предотвращения с пользовательскими правилами, списками исключений и привязкой к маршрутам в версии v2. В версии v2 поддерживаются автомасштабирование и избыточность между зонами.

Продвинутые сценарии использования L7:

• Маршрутизация на основе пути URL: Направляйте /api/* на микросервисы, а /images/* — на статический источник или CDN, реализуя распределение запросов (fanout) к микросервисам за одним VIP.
• Размещение нескольких сайтов (Multi-site hosting): Размещайте contoso.com и fabrikam.com на одном шлюзе, используя прослушиватели SNI и правила на основе заголовка хоста. Полезно для консолидации с надежной изоляцией с помощью политик WAF для каждого сайта.
• Терминирование SSL: Снимайте нагрузку по обработке TLS на шлюзе для централизованного управления сертификатами и проверки трафика WAF. Используйте сквозное шифрование TLS (end-to-end TLS, повторное шифрование), когда бэкенды требуют шифрования или проверки клиентских сертификатов.

Azure Front Door обеспечивает глобальную балансировку нагрузки и ускорение HTTP/HTTPS на периметре сети (edge) с помощью anycast, разделения TCP (split TCP) и оптимизации пути от POP до источника. Он лучше всего подходит для приложений, доступных из интернета, которым требуется глобальная маршрутизация, WAF

Варианты проектирования, межрегиональная интеграция и поведение проб работоспособности

Выбор между внутренними и внешними балансировщиками нагрузки зависит от аудитории и доступности маршрутов. Если потребители находятся только в частных сетях, используйте внутренние балансировщики, чтобы избежать публичного доступа и упростить управление NSG. Для интернет-пользователей или партнёров используйте публичные фронтенды. Для исходящих подключений в большом масштабе предпочтительнее использовать NAT Gateway, а не SNAT балансировщика нагрузки; зарезервируйте правила для исходящего трафика для случаев, когда фронтенд балансировщика должен обеспечивать SNAT.

Cross-region Load Balancer интегрируется с региональными Standard Public Load Balancer для достижения глобальной отказоустойчивости на уровне 4 (Layer 4) в режиме active-active для служб TCP/UDP. Поместите публичные фронтенды региональных балансировщиков в бэкенд-пул глобального балансировщика. Пробы работоспособности на глобальном уровне отражают доступность регионов; маршрутизация направляет трафик в здоровый регион с наименьшей задержкой и автоматически выполняет отработку отказа, если весь регион (или его региональный балансировщик) становится неработоспособным. Комбинируйте это с Front Door, когда вам нужна поддержка обоих протоколов (например, TCP-сервисы через Cross-region LB и HTTP/S через Front Door) под отдельными VIP.

Пробы работоспособности — это источник истины для отработки отказа:

• Пробы TCP: Работают для любой службы TCP. Успехом считается завершённое трёхстороннее рукопожатие (3-way handshake). Подходят для SQL, SMTP или пользовательских протоколов TCP.
• Пробы HTTP/HTTPS: Проверяют работоспособность на уровне приложения, запрашивая определённый путь и ожидая код ответа 200–399. Они позволяют настраивать хост/путь и могут выявлять частичные сбои приложения. Пробы HTTPS проверяют согласование TLS, но не валидность сертификата за пределами рукопожатия; используйте правильные заголовки хоста для приложений с виртуальным хостингом.
• Пороги неработоспособности: Azure Load Balancer помечает бэкенд как неработающий после N последовательных сбоев пробы (настраивается; интервалы по умолчанию короткие для ускорения отработки отказа). Application Gateway и Front Door проводят пробы из нескольких точек и считают источник неработающим, когда накапливается достаточное количество последовательных сбоев по всему набору проб. Для восстановления требуется несколько последовательных успешных проб. Настройте интервал и порог, чтобы сбалансировать чувствительность и избежать «флаппинга» (частых переключений состояния); убедитесь, что пробы достигают легковесной конечной точки, осведомлённой о зависимостях.

Практический сценарий

Компании Adobe необходимо глобально развернуть многорегиональный SaaS, состоящий из веб-фронтендов, микросервисов и группы доступности SQL Server Always On, с жёсткими требованиями к безопасности, быстрой отработкой отказа и низкой задержкой для пользователей по всему миру. Они также используют устаревшую службу сбора телеметрии на основе TCP.

1. Разместить Azure Front Door Standard на границе сети с политикой WAF и маршрутами для www.adobe.com и api.adobe.com. Источниками являются Application Gateways в регионах East US и West Europe, сгруппированные с маршрутизацией на основе задержки и приоритетной отработкой отказа.

• Почему: Front Door обеспечивает глобальный anycast, WAF на границе сети и опциональное кэширование для ускорения и защиты интернет-трафика HTTP/S; он автоматически выбирает ближайший работоспособный регион.

2. Развернуть Application Gateway v2 с WAF в каждом регионе. Настроить многосайтовые прослушиватели с SNI для обоих имён хостов, маршрутизацию на основе URL-путей к микросервисам и пользовательские пробы работоспособности к /healthz на каждом сервисе. Включить сквозное шифрование SSL с переопределением имени хоста бэкенда на FQDN сервисов.

• Почему: Application Gateway предлагает региональную маршрутизацию L7, проверку WAF вблизи приложения, распределение трафика по путям и политики для каждого маршрута; он безопасно подключается к частным бэкендам и обрабатывает перезапись/перенаправление заголовков.

3. Развернуть внутренний Standard Load Balancer в каждом регионе для прослушивателя группы доступности SQL (AG). Настроить статический частный фронтенд, пробу работоспособности TCP на порт пробы Windows Failover Cluster и правило балансировки нагрузки с включённым Floating IP на порт прослушивателя.

• Почему: Прослушиватель SQL требует L4 с прямым ответом от сервера (direct server return). Floating IP сохраняет семантику назначения, а проба TCP точно отражает владение AG. Это соответствует известному требованию, что HTTP-проба на порту 1433 недействительна.

4. Для статических веб-ресурсов использовать правила кэширования Azure Front Door для /static/* с долгим TTL и повторной проверкой, а также создать профиль и конечную точку Azure CDN для загрузки больших медиафайлов на downloads.adobe.com с кэшированием для конкретных путей и вариацией по строке запроса.

• Почему: Кэширование в Front Door снижает задержку для основного статического веб-контента в рамках пограничной маршрутизации, в то время как выделенная конечная точка CDN оптимизирует доставку больших объектов и обеспечивает независимость политики кэширования для загрузок.

5. Опубликовать устаревшую службу сбора телеметрии по TCP через региональный Standard Public Load Balancer в каждом регионе, а затем использовать Cross-region Load Balancer в качестве единого публичного VIP перед ними. Настроить глобальные пробы для каждого регионального балансировщика и использовать маршрутизацию на основе задержки.

• Почему: Сервис работает по TCP, а не HTTP; Cross-region Load Balancer обеспечивает глобальную L4-доступность в режиме active-active с автоматической отработкой отказа и выбором региона с наименьшей задержкой.

6. Добавить Azure Traffic Manager с политикой приоритета (Priority) только для внешней конечной точки SFTP партнёра, размещённой вне Azure, указав основную конечную точку партнёра и резервную, размещённую в Azure.

• Почему: Traffic Manager основан на DNS и может включать внешние конечные точки; он обеспечивает простую отработку отказа в режиме active/passive для не-HTTP и сторонних целей, где проксирование не требуется.

7. Для исходящих подключений из подсетей приложений подключить NAT Gateway и устранить зависимость от SNAT балансировщика нагрузки. Отслеживать результаты проб и метрики LB/App Gateway/Front Door в Azure Monitor и настраивать интервалы/пороги неработоспособности проб для устранения «флаппинга».

• Почему: NAT Gateway надёжно масштабирует исходящие подключения без исчерпания портов SNAT; точная настройка проб работоспособности обеспечивает более быстрое и стабильное поведение отработки отказа на всех уровнях.

← Виртуальные сети Azure · Все домены · Хранилище Azure →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →