Azure Load Balancer¶

Azure Load Balancer — это распределитель сетевой нагрузки (балансировщик) уровня 4 (OSI) от компании Microsoft, входящий в состав облачной платформы Microsoft Azure. Он обеспечивает высокую доступность и масштабируемость приложений путём распределения входящего трафика между несколькими виртуальными машинами или экземплярами служб в пределах одного региона Azure. Работает на транспортном уровне модели OSI (TCP и UDP), не анализируя содержимое пакетов (HTTP-заголовки, URL и т.д.), что отличает его от балансировщиков уровня 7, таких как Azure Application Gateway.

¶История и развитие

Azure Load Balancer был запущен в 2010 году как один из первых сервисов платформы Azure. Первоначально он поддерживал только базовые сценарии балансировки для облачных служб (Cloud Services). В 2015 году, с выходом Azure Resource Manager (ARM), появилась возможность создавать балансировщики в новой модели развёртывания, что улучшило управляемость и интеграцию с другими сервисами.

В 2017 году Microsoft представила Azure Load Balancer Standard SKU, который значительно расширил функциональность по сравнению с базовым (Basic) SKU: появилась поддержка зон доступности (Availability Zones), диагностических метрик в Azure Monitor, исходящих правил (Outbound Rules), а также более строгие политики безопасности (по умолчанию трафик заблокирован до явного разрешения правилами). В 2020 году был анонсирован Azure Load Balancer с поддержкой IPv6 для конечных точек. К 2024 году сервис является одним из наиболее востребованных компонентов сетевой инфраструктуры в Azure, обрабатывая миллионы запросов в минуту для крупных корпоративных клиентов.

¶Архитектура и принцип работы

Azure Load Balancer работает как программно-определяемый балансировщик, размещённый в виртуальной сети Azure. Он не является физическим устройством; его функции выполняются программным обеспечением, запущенным на хостах гипервизора Azure.

¶Компоненты

• Frontend IP-конфигурация: Публичный или частный IP-адрес, на который клиенты отправляют запросы. Для публичного балансировщика это общедоступный IP-адрес; для внутреннего — частный IP-адрес в виртуальной сети.
• Backend pool (пул бэкенда): Набор ресурсов, которые получают трафик. Обычно это виртуальные машины (VM), масштабируемые наборы виртуальных машин (VMSS) или экземпляры служб (например, Azure Kubernetes Service). Ресурсы должны находиться в той же виртуальной сети и регионе, что и балансировщик.
• Правила балансировки (Load Balancing Rules): Определяют, как трафик от фронтенда распределяется по бэкенд-пулу. Задают протокол (TCP/UDP), порт фронтенда, порт бэкенда, метод распределения и параметры проверки работоспособности.
• Проверки работоспособности (Health Probes): Механизм, который периодически опрашивает каждый ресурс в бэкенд-пуле (по IP-адресу и порту). Если ресурс не отвечает на проверку в течение заданного количества попыток, он исключается из ротации. Поддерживаются протоколы TCP, HTTP и HTTPS.
• Исходящие правила (Outbound Rules): Управляют исходящим трафиком от виртуальных машин к интернету через публичный IP-адрес балансировщика. Доступны только в Standard SKU.

¶Алгоритмы распределения трафика

Azure Load Balancer использует два основных алгоритма:

1. Хэширование на основе 5-кортежа (5-tuple hash): По умолчанию. Трафик распределяется на основе хэша, вычисленного из IP-адреса источника, порта источника, IP-адреса назначения, порта назначения и протокола. Это гарантирует, что все пакеты одного сеанса TCP/UDP попадают на один и тот же бэкенд-ресурс (липкость сеанса).
2. Хэширование на основе 2-кортежа (2-tuple hash) или 3-кортежа (3-tuple hash): Используется при включении режима «привязка к источнику» (Source IP Affinity). В этом случае хэш вычисляется только по IP-адресу источника (2-кортеж) или IP-адресу источника и назначения (3-кортеж). Это полезно для сценариев, где клиент должен всегда подключаться к одному и тому же бэкенду (например, для веб-сокетов или шлюзов удалённого рабочего стола).

¶Зоны доступности

В регионах, поддерживающих зоны доступности (Availability Zones), Azure Load Balancer Standard может быть настроен как зонно-избыточный (zone-redundant) или зонный (zonal). Зонно-избыточный балансировщик автоматически распределяет трафик между всеми зонами региона, обеспечивая отказоустойчивость при выходе из строя целой зоны. Зонный балансировщик привязан к одной конкретной зоне.

¶SKU и типы

Microsoft предлагает два SKU для Azure Load Balancer: Basic и Standard. Выбор SKU влияет на функциональность, производительность и стоимость.

Также существует Azure Load Balancer для внутреннего использования (Internal Load Balancer), который не имеет публичного IP-адреса и используется для балансировки трафика внутри виртуальной сети Azure (например, между уровнями приложения). Публичный (External) Load Balancer, напротив, принимает трафик из интернета.

¶Применение

Azure Load Balancer применяется в широком спектре сценариев:

• Веб-приложения с высокой доступностью: Распределение HTTP/HTTPS-трафика между несколькими веб-серверами. При выходе одного сервера из строя балансировщик автоматически перенаправляет трафик на здоровые экземпляры.
• Микросервисные архитектуры: Внутренний балансировщик используется для балансировки трафика между внутренними службами (например, между API-шлюзом и сервисами бэкенда).
• Azure Kubernetes Service (AKS): AKS автоматически создаёт внутренний балансировщик для сервисов типа ClusterIP и LoadBalancer. Публичный балансировщик может быть создан для сервиса типа LoadBalancer.
• Remote Desktop Services (RDS): Балансировка подключений к серверам удалённых рабочих столов.
• VPN-шлюзы и шлюзы приложений: Часто используется в паре с другими сетевыми службами Azure, такими как Azure Firewall или Azure Application Gateway, для обеспечения многоуровневой защиты и балансировки.

¶Ограничения и особенности

• Региональность: Azure Load Balancer работает только в пределах одного региона Azure. Для балансировки трафика между регионами требуется Azure Traffic Manager или Azure Front Door.
• Отсутствие анализа уровня 7: Балансировщик не может маршрутизировать трафик на основе URL, заголовков HTTP или других данных прикладного уровня. Для этого используется Azure Application Gateway.
• Отсутствие шифрования: Трафик между балансировщиком и бэкендами не шифруется. Для шифрования на транспортном уровне необходимо настроить TLS/SSL на бэкенд-серверах или использовать Azure Application Gateway.
• Зависимость от зон доступности: Если балансировщик настроен как зонный, а зона выходит из строя, балансировщик становится недоступным. Рекомендуется использовать зонно-избыточную конфигурацию для критически важных приложений.

¶Сравнение с другими балансировщиками Azure

Azure Load Balancer — не единственный балансировщик в экосистеме Azure. Основные альтернативы:

• Azure Application Gateway: Балансировщик уровня 7 (HTTP/HTTPS). Поддерживает URL-маршрутизацию, SSL-терминацию, веб-защиту (WAF), кэширование и другие функции прикладного уровня.
• Azure Traffic Manager: Балансировщик трафика на уровне DNS. Работает на уровне доменных имён, направляя пользователей к ближайшему или наиболее доступному региональному развёртыванию. Не обрабатывает сами пакеты.
• Azure Front Door: Глобальный балансировщик уровня 7, объединяющий функции Azure Application Gateway и Azure Traffic Manager. Обеспечивает ускорение веб-приложений, защиту от DDoS-атак и глобальную балансировку.

¶Критика

Основные претензии пользователей к Azure Load Balancer связаны с ограничениями Basic SKU (отсутствие зон доступности, малый размер пула, негибкие проверки работоспособности) и необходимостью перехода на платный Standard SKU для большинства современных сценариев. Также отмечается, что настройка исходящих правил в Standard SKU может быть неинтуитивной для новичков. Некоторые администраторы критикуют отсутствие встроенной поддержки протокола QUIC (UDP-балансировка возможна, но без специальной оптимизации).

¶Источники

• Microsoft Learn: Azure Load Balancer documentation
• Microsoft Azure Architecture Center: Load balancing options in Azure
• Azure Updates blog: History of Azure Load Balancer SKUs
• TechNet Wiki: Comparing Azure Load Balancer Basic vs Standard