В этом посте я хочу рассказать о системе балансировки нагрузки VMware NSX Advanced Load Balancer (от Avi Networks), или NSX ALB. Чуть больше года назад VMware купил компания Avi Networks, при этом система балансировки сменила название с Avi Vantage на NSX ALB, но старое название Avi также было сохранено.
С тех пор балансировщик интегрировался с продуктами VMware, в первую очередь с NSX. Но при этом сохраняется возможность его автономного использования.
В сети систематической информации о NSX ALB на русском языке почти нет, только документация от производителя на английском языке.
Поэтому в первой части я обобщил разрозненные источники и сделал обзор продукта: рассказал об особенностях, архитектуре и логике работы, в том числе для географически разнесенных сайтов.
В вторая часть Я описал, как развернуть и настроить систему.
Надеюсь, обе статьи будут полезны тем, кто ищет балансировщик для работы в облачных средах и хочет быстро оценить возможности NSX ALB. 
Особенности и возможности
НСХ АЛБ – программно-определяемый балансировщик нагрузки (Software Defined Load Balancer, SDLB) уровня Enterprise. Это не характерно для систем балансировки такого уровня, где обычно используются аппаратные балансировщики.Такой подход к построению системы обеспечивает NSX ALB простоту управления, а также горизонтальную и вертикальную масштабируемость.
Какие возможности предоставляет NSX ALB:
- Автоматическая регулировка мощности балансира.
При увеличении нагрузки со стороны клиентов мощность автоматически увеличивается, при уменьшении нагрузки – снижается.
- Балансировка нагрузки на географически распределенных серверах.
За это отвечает отдельный механизм глобальной балансировки нагрузки серверов (Global Server Load Balancing, GSLB).
- Балансировка на одном из уровней: L4 (по протоколам TCP/UDP) и L7 (по протоколам HTTP/HTTPS).
- Поддерживает различные облачные среды и автономное использование.
NSX ALB можно использовать с внешними (не VMware) облачными службами и локальными установками:
- Встроенная аналитика приложений (Application Intelligence).
Система отслеживает работу приложений и собирает данные: время каждого этапа обработки подключения, оценку статуса приложения и логи трафика в режиме реального времени.
Если возникнет проблема, мониторинг поможет быстро понять, где ее искать.
В режиме реального времени собираются данные об одновременно открытых соединениях, времени приема-передачи (RTT), пропускной способности, ошибках, задержках ответа, задержках подтверждения SSL, типах ответов и многом другом.
Вся информация в одном месте:
Блок Log Analytics справа собирает статистику по основным параметрам соединения.Вы можете навести курсор мыши на нужный раздел и быстро ознакомиться.
- Поддержка мультитенантности для разграничения доступа к ресурсам.
- Health Monitor для проверки доступности серверов в пуле и перенаправления клиентских запросов только на рабочие серверы.
- Встроенный брандмауэр веб-приложений (WAF).
- Внутренние службы IPAM и DNS.
- Анализ и фильтрация адресов, с которых приходят клиентские запросы.
Вы можете разрешить или запретить трафик с определенных адресов.
Список или диапазон для фильтрации задается вручную или выбирается из базы данных репутации IP-адресов, замеченных в атаках.
Вы можете выбрать категорию: Ботнет, DoS, Мобильные угрозы, Фишинг, Прокси, Сканер, Источник спама, Веб-атаки, Эксплойт для Windows и т. д. или все сразу.
- Разбор HTTP-заголовков проходящих пакетов.
Вы можете использовать скрипты (DataScript) на основе языка Lua и определять действия Avi в зависимости от значений в этих заголовках: перенаправление запроса, закрытие или сброс соединения, подмена URI или значений в HTTP-заголовке, выбор конкретный пул серверов для обработки запроса, работы с файлами cookie и т. д.
- Выполнение функций Ingress-контроллера для Kubernetes.
Архитектура и работа NSX ALB
Схема работы NSX ALB построена на стандартных для большинства SDLB принципах.Серверы, предоставляющие услуги балансировки, объединены в бассейны .
Над пулами системный администратор создает виртуальные сервисы (Virtual Services, VS) .
Они содержат параметры балансируемой услуги, например: тип приложения, алгоритм балансировки, настройки подключения.
VS также предоставляет клиентам внешние виртуальный IP-адрес (Виртуальный IP, VIP) для доступа к сбалансированному сервису.
Давайте подробнее рассмотрим, как выглядит архитектура: 
Ключевым элементом системы является контроллер (Ави-контроллер) .
Он отвечает за автоматическое расширение мощности и централизованно управляет VS. Вы можете развернуть в своей инфраструктуре один контроллер или отказоустойчивый кластер контроллеров.
В отказоустойчивом варианте кластер контроллеров состоит из 3 узлов.
Один из узлов становится ведущим, остальные — ведомыми.
Все 3 узла активны и распределяют нагрузку между собой.
Основные сценарии работы кластера контроллеров:
- если один узел выйдет из строя, это не повлияет на работу кластера;
- при выходе из строя ведущего узла эта роль переходит к одному из оставшихся;
- Если два узла выходят из строя, служба контроллера на оставшемся узле переходит в режим только для чтения, чтобы избежать разделения мозга, и ждет, пока другой узел снова станет доступным.
- Round Robin — новое соединение перейдет к следующему серверу в пуле.
- Least Connections – новое соединение будет поступать к серверу с наименьшим количеством одновременных подключений.
- Least Load – новое соединение пойдет на сервер с наименьшей нагрузкой, независимо от количества подключений.
- Согласованный хэш – новые соединения распределяются по серверам на основе рассчитанного хеша.
Ключ для расчета хеша указывается в специальном поле или в произвольной строке.
Для каждого запроса с помощью этого ключа рассчитывается хэш.
Соединение отправляется на сервер, соответствующий вычисленному хешу.
- Самый быстрый ответ – новое соединение пойдет на сервер с самой высокой скоростью ответа на запрос клиента.
- Наименьшее количество задач — нагрузка адаптивно балансируется на основе ответов сервера (данный алгоритм можно настроить только через Avi CLI и REST API.
- Наименьшее количество серверов – соединения распределяются таким образом, чтобы использовать наименьшее количество серверов для текущей нагрузки.
Каждый сервис (ВС) распределен по нескольким SE, которые параллельно обрабатывают клиентские запросы.
Это обеспечивает отказоустойчивость сервиса в случае сбоев виртуальной машины.
Контроллер может оценить нагрузку и добавить новые SE или удалить незагруженные.
Благодаря такой архитектуре NSX ALB может масштабироваться как горизонтально — увеличивая количество SE, так и вертикально — увеличивая емкость каждого SE. Чем больше сервисов балансирует SE, тем больше сетевых интерфейсов используется.
На подробной схеме ниже мы видим 2 типа сетей:
- сеть управления и передачи служебной информации образует плоскость управления ( Плоскость управления ),
- Сети передачи данных образуют плоскость данных ( Плоскость данных ).
Остальные интерфейсы подключены к внешней сети и к сети, где находится пул серверов для балансировки.
Такое разделение сетевой инфраструктуры повышает безопасность.
Для каждой VS необходимо определить параметры SE, на котором будет размещаться сервис.
Эти параметры задаются в Группа С? .
При создании VS выбираем группу SE: можно указать группу по умолчанию (Default Group) или создать новую группу, если VS требует особых настроек виртуальной машины.
Выбранная группа будет определять, как будет размещена новая VS. Например, если в системе уже развернуты SE группы по умолчанию и у этих SE еще есть ресурсы, то на них будет размещена новая ВС с указанной группой по умолчанию.
Если мы укажем новую группу для VS, для нее будут развернуты новые SE с другими параметрами.
На уровне группы SE мы установили следующие настройки размещения VS:
- максимальное количество SE в группе,
- максимальное количество ВС на одну SE,
- способ размещения ВС на SE: Компактный, когда сначала максимально плотно набиваем первый SE и переходим к следующему, или Распределенный с равномерным распределением:
- Параметры виртуальной машины SE: количество виртуальных ЦП, объем памяти и диска,
Пропускная способность на 1 виртуальный ЦП составляет примерно 40 тысяч подключений/с и в среднем 4 ГБ/с.
Этот показатель различается для разных уровней балансировки и используемого протокола: на L4 он больше, на L7 меньше из-за необходимости анализа трафика, при SSL существенно меньше из-за необходимости шифрования.
- время жизни неиспользуемого SE, по истечении которого его необходимо удалить,
- ресурсы для размещения SE. В среде VMware вы можете указать или исключить для использования определенный кластер или хосты и хранилище данных.
Архитектура и схема работы территориально-распределенных серверов
В обычном виртуальном сервисе мы можем добавлять серверы в пул только из одного облака.Даже если мы добавим на контроллер одновременно несколько облаков, мы не сможем объединить серверы из разных облаков в рамках одной VS. Эту проблему решает сервис глобальной балансировки GSLB. Он позволяет сбалансировать географически разбросанные серверы, расположенные в разных облаках.
В рамках одного глобального сервиса вы можете одновременно использовать как частные, так и публичные облака.
Вот случаи, когда GSLB может понадобиться:
- высокая доступность сервиса, если все серверы в одном из облаков недоступны,
- катастрофоустойчивость, если одно облако окажется полностью недоступно,
- создание гибридного облака, когда серверы расположены как в частных, так и в публичных облаках.
Если ресурсы в частном облаке исчерпаны, избыточная нагрузка переходит в публичное облако.
Вот как это работает: балансировка выполняется локальной службой DNS, развернутой внутри NSX ALB. Клиент отправляет запрос на подключение службе, используя полное доменное имя.
DNS дает клиенту виртуальный IP локальной VS в самом оптимальном облаке.
Сервис выбирает наиболее оптимальное облако на основе алгоритма балансировки, данных о наличии локальной ВС на Health Monitor и географическом расположении клиента.
Вы можете задавать разные алгоритмы балансировки — как на глобальном уровне сервиса, так и на уровне GSLB. Как видно из диаграммы GSLB, она построена на основе элементов предыдущей схемы: пулов серверов, над ними локальных виртуальных сервисов (VS) с локальными виртуальными IP-адресами (VIP) и сервисных виртуальных машин (SE).
По мере построения GSLB появляются новые элементы.
Глобальное обслуживание (глобальный VS) – услуга, сбалансированная между географически распределенными серверами или частными и публичными облаками.
Сайт ГСЛБ включает в себя контроллер и управляемые им SE, расположенные в одном облаке.
Для каждого сайта можно задать геолокацию по широте и долготе.
Таким образом, GSLB сможет выбирать пул серверов в зависимости от удаленности от клиента.
Сайты GSLB на базе системы NSX ALB делятся на сайты-лидеры и ведомые.
Как и в случае с контроллерами, данная схема обеспечивает отказоустойчивость службы GSLB. Хост-сайт принимает решения по балансировке, обрабатывает соединения и осуществляет мониторинг.
Изменить конфигурацию GSLB можно только с контроллера хост-сайта.
Подчиненные сайты могут быть активными или пассивными.
- Пассивный подчиненный сайт обрабатывает входящие клиентские соединения только в том случае, если главный сайт выбирает свою локальную VS.
- Активный подчиненный сайт получает конфигурацию от главного сайта и в случае сбоя может взять на себя ведущую роль.
Глобальный пул отличается от локального пула, который содержит локальные серверы.
В глобальный пул можно объединить географически разнесенные виртуальные сервисы с разных площадок.
Другими словами, глобальный пул содержит локальные VS, которые установлены на уровне сайтов GSLB. Балансировка соединений между серверами глобального пула выполняется:
- по алгоритму Round Robin,
- по геолокации сервера,
- на основе топологии, предварительно настроенной в глобальных политиках обслуживания.
- на основе последовательного хеша.
В этом случае новые подключения будут распределяться по геолокации или по заданным приоритетам.
Чтобы установить приоритеты для серверов пула, вы можете установить для каждого разный вес.
Пример балансировки между глобальными пулами .
Вот как глобальный VS будет распределять соединения на этой диаграмме: 
Пул GslbPool_3 имеет приоритет 10 и будет предпочтительным для клиентских подключений.
Из этих подключений 40% нагрузки пойдет на VS-B3 и 60% на VS-B4. Если GslbPool_3 станет недоступен, все клиентские подключения полностью перейдут на GslbPool_2, а нагрузка будет равномерно распределена между VS-B3 и VS-B4. Локальный DNS содержат записи с полными доменными именами балансируемых через него сервисов.
ГСЛБ DNS – режим работы локального DNS VS, который используется для балансировки соединений между сайтами GSLB. VS Local DNS начинает действовать как GSLB DNS, когда мы выбираем его в качестве службы DNS для поднятого GSLB. Эту DNS VS необходимо развернуть на всех сайтах, включенных в глобальные пулы.
GSLB добавляет записи полного доменного имени глобальной службы в каждый локальный DNS. NSX ALB заполняет эту запись виртуальными IP-адресами локальных VS со всех сайтов, включенных в глобальный пул VS. Эти дополнительные VIP добавляются автоматически при добавлении в пул новых локальных VS. Данные в записях обновляются по мере накопления информации о загруженности сервиса, доступности серверов и удаленности клиентов от сайтов.
Когда новый клиент подключается через полное доменное имя, один из локальных DNS выдает локальный VIP-адрес VS на основе этих накопленных актуальных данных.
Я описал, как развернуть и настроить систему NSX ALB, а также поднять в ней сервис GSLB. во второй части Эта статья.
Теги: #Виртуализация #ИТ-инфраструктура #облачные сервисы #балансировка нагрузки #балансировщик нагрузки #balancer #avi #nsx alb #nsx Advanced Load Balancer #avi vantage
-
Равессон-Мольен, Жан Гаспар Феликс
19 Oct, 24 -
Асн.1 Простыми Словами (Кодировка Типа Real)
19 Oct, 24 -
Мониторинг Фриланс-Платформ В Slack
19 Oct, 24 -
Вышла В Свет Книга «Увеличьте Свой Сайт».
19 Oct, 24 -
Ethercalc: Электронные Таблицы С Node.js
19 Oct, 24
