Режимы распределения для Azure Load Balancer

Azure Load Balancer поддерживает следующие режимы распределения для маршрутизации подключений к экземплярам в серверном пуле:

Режим распределения	На основе хэша	Сохранение сеанса: IP-адрес клиента	Сохранение сеанса: IP-адрес клиента и протокол
Обзор	Трафик с одного IP-адреса клиента направляется на любой работоспособный экземпляр в серверном пуле	Трафик с одного IP-адреса клиента направляется в один серверный экземпляр	Трафик с одного сочетания IP-адреса клиента и протокола направляется в один серверный экземпляр
Кортежи	пять кортежей	двух кортежей	три кортежа
Настройка портала Azure	Сохранение сеанса: Нет.	Сохранение сеанса: IP-адрес клиента	Сохранение сеанса: IP-адрес клиента и протокол
REST API	"loadDistribution":"Default"	"loadDistribution":SourceIP	"loadDistribution":SourceIPProtocol

При переключении с одного режима распределения на другой в подсистеме балансировки нагрузки отсутствует простой.

На основе хэша

Azure Load Balancer использует по умолчанию режим распространения на основе хэша с пятью кортежами.

В кортеж входят такие элементы:

• IP-адрес источника
• Исходный порт
• IP-адрес назначения
• Порт назначения
• Тип протокола

Этот хэш используется для направления трафика на работоспособные серверные экземпляры в серверном пуле. Алгоритм позволяет закреплять IP-адреса только в рамках сеанса транспортировки. Когда клиент начинает новый сеанс с того же исходного IP-адреса, порт источника изменяется и перенаправляет трафик на другой серверный экземпляр. Чтобы настроить распределение на основе хэша, на портале Azure необходимо выбрать для сохранения сеанса значение Нет. Это указывает, что последовательные запросы от одного клиента могут обрабатываться любой виртуальной машиной.

Рисунок: распределение хэша на основе пяти кортежей по умолчанию

Сохранение сеанса

Сохранение сеанса также может называться сходством сеансов, сходством IP-адреса источника или сходством IP-адреса клиента. Этот режим распределения использует хэш 2-кортеж (IP-адрес источника и IP-адрес назначения) или хэш 3-кортеж (IP-адрес источника, IP-адрес назначения и тип протокола) для направления трафика на серверные экземпляры. При использовании сохраняемости сеансов подключения от того же клиента переходят к тому же экземпляру серверной части в серверной пуле.

У режима сохраняемости сеанса есть два типа конфигурации:

• IP-адрес клиента (2-кортеж) — указывает, что последовательные запросы с одного и того же IP-адреса клиента обрабатываются тем же серверным экземпляром.
• IP-адрес клиента и протокол (3-кортеж) — указывает, что последовательные запросы из одного и того же IP-адреса клиента и сочетания протоколов обрабатываются тем же серверным экземпляром.

Конфигурация двухкортежного распределения представлена на следующем рисунке. Обратите внимание, как двухкортежное распределение передается через подсистему балансировки нагрузки на виртуальную машину 1 (VM1). Виртуальная машина1 выполняет резервное копирование с помощью VM2 и VM3.

Случаи использования

Сопоставление IP-адресов источника с IP-адресом клиента и протоколом (сопоставление исходных IP-адресов трех кортежей) решает несовместимость между Azure Load Balancer и шлюзом удаленных рабочих столов (шлюз удаленных рабочих столов).

Другой сценарий использования — передача мультимедиа. В этом случае передача данных осуществляется по протоколу UDP, а управление — по протоколу TCP.

• Сначала клиент запускает сеанс TCP для общедоступного IP-адреса с балансировкой нагрузки, который затем направляется по конкретному DIP. Сам канал остается активным, чтобы контролировать состояние подключения.
• С того же клиентского компьютера для той же общедоступной конечной точки с балансировкой нагрузки запускается новый сеанс UDP. Подключение направляется на ту же конечную точку DIP, что и предыдущее TCP-подключение. Таким образом можно передавать мультимедиа с более высокой пропускной способностью, поддерживая при этом канал управления по TCP.

Примечание.

Если участники серверного пула Load Balancer изменяются путем удаления или добавления виртуальной машины, распределение клиентских запросов пересчитывается. Нельзя полагаться на то, что новые подключения от существующих клиентов будут направлены на один сервер. Кроме того, использование режима распределения соответствия исходному IP-адресу может привести к неравномерному распределению трафика. Клиенты, работающие на прокси-серверах, могут рассматриваться как одно уникальное клиентское приложение.

Следующие шаги

Дополнительные сведения о настройке режима распределения для Azure Load Balancer см. в статье Настройка режима распределения для Azure Load Balancer.