NSX Advanced Load Balancer – умный автомасштабируемый балансировщик нагрузки. Часть 1: архитектура и особенности29.10.2020 11:17

В этом посте я хочу рассказать о системе балансировки нагрузки VMware NSX Advanced Load Balancer (by Avi Networks), или NSX ALB. Чуть больше года назад компания VMware купила компанию Avi Networks, и тогда же система балансировки сменила название с Avi Vantage на NSX ALB, но старое название Avi также сохранилось. С тех пор происходит интеграция балансировщика с продуктами VMware, в первую очередь, NSX. Но при этом остается возможность его автономного использования.

В сети почти нет систематизированной информации про NSX ALB на русском языке, только документация от вендора на английском. Поэтому в первой части я обобщил разрозненные источники и сделал обзор продукта: рассказал про особенности, архитектуру и логику работы, в том числе для географически разнесенных площадок. Во второй части опишу, как развернуть и настроить систему. Надеюсь, обе статьи будут полезны тем, кто ищет балансировщик для работы в облачных средах и хочет быстро оценить возможности 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) облачными сервисами и on-premise инсталляциями:
Встроенная аналитика приложений (Application Intelligence). Система мониторит производительность приложений и собирает данные: время на каждый этап обработки соединения, оценку состояния приложений и журналы трафика в реальном времени. Если возникает какая-то проблема, по мониторингу можно быстро понять, где ее искать.
В реальном времени собираются данные об одновременно открытых соединениях, времени цикла приема-передачи (RTT), пропускной способности, ошибках, задержках ответа, задержках установления связи SSL, типах ответов и т.д. Вся информация в одном месте:
В блоке Log Analytics справа собирается статистика по основным параметрам соединения. Можно навести мышь на нужный раздел и быстро ознакомиться.

Кроме того, в NSX ALB есть:

Поддержка мультитенантности для разграничения доступа к ресурсам.
Health Monitor для проверки доступности серверов в пуле и перенаправления клиентских запросов только на рабочие серверы.
Встроенный Web Application Firewall (WAF).
Внутренние службы IPAM и DNS.
Анализ и фильтрация адресов, с которых поступают клиентские запросы. Можно разрешить или запретить трафик с конкретных адресов. Перечень или диапазон для фильтрации задается вручную или выбирается из базы данных репутаций IP-адресов, замеченных в атаках. Можно выбрать категорию: Botnet, DoS, Mobile threats, Phishing, Proxy, Scanner, Spam source, Web attacks, Windows exploit и т.д., — или все сразу.
Разбор HTTP-заголовков проходящих пакетов. Можно использовать скрипты (DataScript) на основе языка Lua и определять действия Avi в зависимости от значений в этих заголовках: перенаправление запроса, закрытие или сброс соединения, подмена URI или значений в HTTP-заголовке, выбор определенного пула серверов для обработки запроса, работа с cookie и т.д.
Выполнение роли Ingress-контроллера для Kubernetes.

Управлять NSX ALB можно через GUI, CLI и REST API.

Архитектура и схема работы NSX ALB

Схема работы NSX ALB построена на стандартных принципах для большинства SDLB. Серверы, предоставляющие сервис для балансировки, объединяются в пулы (pools). Над пулами администратор системы создает виртуальные сервисы (Virtual Services, VS). Они содержат параметры балансируемого сервиса, например: тип приложения, алгоритм балансировки, настройки подключения. Также VS предоставляют клиентам внешний виртуальный IP-адрес (Virtual IP, VIP) для доступа к балансируемому сервису.

Посмотрим подробнее, как выглядит архитектура:

Ключевой элемент системы — контроллер (Avi Controller). Он отвечает за автоматическое наращивание мощности и централизованно управляет VS. Можно развернуть в инфраструктуре одиночный контроллер или отказоустойчивый кластер контроллеров.

В отказоустойчивом варианте кластер контроллеров состоит из 3 узлов. Один из узлов становится ведущим (leader), остальные ведомыми (follower). Все 3 узла активны и распределяют нагрузку между собой. Основные сценарии работы кластера контроллеров:

если один узел выходит из строя, это не оказывает влияния на работу кластера;
если выходит из строя ведущий узел, эта роль переходит к одному из оставшихся;
если из строя выходит 2 узла, сервис контроллера на оставшемся узле переходит в режим «только для чтения» во избежание сплит-брейна и ожидает возвращения доступности еще одного узла.

После разворачивания контроллера инженер создает VS и пул серверов для каждого VS. Для серверов внутри пула можно выбрать алгоритм балансировки:

Round Robin — новое подключение пойдет на следующий сервер в пуле.
Least Connections — новое подключение пойдет на сервер с наименьшим числом одновременных соединений.
Least Load — новое подключение пойдет на сервер с наименьшей нагрузкой независимо от числа соединений.
Consistent Hash — новые подключения распределяются по серверам на основе вычисленного хэша. Ключ для вычисления хэша указывается в специальном поле или в настраиваемой строке. Для каждого запроса вычисляется хэш с помощью этого ключа. Подключение отправляется на сервер, соответствующий вычисленному хэшу.
Fastest Response — новое подключение пойдет на сервер с наиболее высокой скоростью ответа на клиентский запрос.
Fewest Tasks — нагрузка адаптивно балансируется на основе ответов серверов (этот алгоритм настраивается только через Avi CLI и REST API.
Fewest Servers — подключения распределяются так, чтобы задействовать наименьшее количество серверов для текущей нагрузки.

После создания VS и пула серверов контроллер сам разворачивает служебные виртуальные машины, Service Engine (SE), на которых размещается балансируемый сервис. Каждый сервис (VS) распределяется по нескольким SE, которые параллельно обрабатывают запросы клиентов. Это обеспечивает отказоустойчивость сервиса на случай отказов виртуальных машин.

Контроллер может оценивать нагрузку и добавлять новые SE или удалять не загруженные. За счет такой архитектуры NSX ALB может масштабироваться как горизонтально — увеличивая число SE, так и вертикально — наращивая мощности каждой SE.

Чем больше сервисов балансирует SE, тем больше сетевых интерфейсов задействуется. На подробной схеме ниже мы видим 2 типа сетей:

сеть для управления и передачи служебной информации образует плоскость управления (Control Plane),
сети для передачи данных образуют плоскость данных (Data Plane).

Каждая SE отдельным сетевым интерфейсом находится в сети управления для связи с контроллером. Остальные интерфейсы подключены во внешнюю сеть и сеть, где находится пул серверов для балансировки. Такое разделение сетевой инфраструктуры повышает безопасность.

Для каждого VS нужно определить параметры SE, на которых будет размещаться сервис. Эти параметры задаются в группе SE (SE Group). При создании VS мы выбираем группу SE: можно указать группу по умолчанию (Default Group) или создать новую группу, если для VS нужны особые настройки виртуальной машины.

От выбранной группы будет зависеть, как будут размещаться новые VS. Например, если в системе уже развернуты SE дефолтной группы и на этих SE еще есть ресурсы, то новый VS с указанной дефолтной группой разместится на них. Если же мы укажем для VS новую группу, под него будут развернуты новые SE c другими параметрами.

На уровне группы SE задаем следующие настройки размещения VS:

максимальное число SE в группе,
максимальное число VS на одну SE,
способ размещения VS по SE: Compact, когда мы сначала максимально плотно набиваем первую SE и переходим к следующей, или Distributed с равномерным распределением:
параметры виртуальной машины SE: число vCPU, объем памяти и диска,
Пропускная способность в расчете на 1 vCPU составляет примерно 40 тысяч подключений/с и в среднем — 4 ГБ/с. Этот показатель отличается для разных уровней балансировки и используемого протокола: на L4 он больше, на L7 меньше, из-за необходимости анализа трафика, при SSL — значительно меньше, из-за необходимости шифрования.
время жизни неиспользуемой SE, после которого ее нужно удалить,
ресурсы для размещения SE. В среде VMware можно указать или исключить для использования конкретный кластер или хосты и датастор.

Перейдем к архитектуре и схеме работы сервиса глобальной балансировки GSLB.

Архитектура и схема работы для географически разнесенных серверов

В обычном виртуальном сервисе мы можем добавлять серверы в пул только из одного облака. Даже если мы добавим на контроллере несколько облаков одновременно, мы не сможем совместить серверы из разных облаков в рамках одного VS. Эту задачу решает сервис глобальной балансировки GSLB. Он позволяет балансировать географически разнесенные серверы, находящиеся в разных облаках.

В рамках одного глобального сервиса можно одновременно использовать и приватные, и публичные облака. Вот случаи, когда может понадобиться GSLB:

высокая доступность сервиса, если окажутся недоступны все серверы в одном из облаков,
катастрофоустойчивость, если окажется полностью недоступно одно облако,
создание гибридного облака, когда серверы находятся как в частном, так и в публичном облаках. В случае исчерпания ресурсов в частном облаке избыточная нагрузка уходит в публичное облако.

Посмотрим на архитектуру GSLB:

Схема работы вкратце: балансировку производит локальный сервис DNS, развернутый внутри NSX ALB. Клиент отправляет запрос подключения к сервису по FQDN-имени. DNS отдает клиенту виртуальный IP локального VS в наиболее оптимальном облаке. Наиболее оптимальное облако сервис выбирает на основе алгоритма балансировки, данных о доступности локальных VS на Health Monitor и географического положения клиента. Можно задавать разные алгоритмы балансировки — как на уровне глобального сервиса, так и на уровне GSLB.

Как видно из схемы GSLB, в ее основе лежат элементы предыдущей схемы: пулы серверов, над ними локальные виртуальные сервисы (VS) с локальными виртуальными IP (VIP) и служебные виртуальные машины (SE). При построении GSLB появляются новые элементы.

Глобальный сервис (global VS) — сервис, балансируемый между географически разнесенными серверами или приватными и публичными облаками.

GSLB-сайт (GSLB Site) включает контроллер и управляемые им SE, расположенные в одном облаке. Для каждого сайта можно задать геолокацию по широте и долготе. Так GSLB сможет выбирать пул серверов по удаленности от клиента.

Сайты GSLB на основе системы NSX ALB делятся на ведущие (leader) и ведомые (follower). Как и в случае с контроллерами, такая схема обеспечивает отказоустойчивость сервиса GSLB.

Ведущий сайт принимает решения по балансировке, обрабатывает подключения и осуществляет мониторинг. Изменить конфигурацию GSLB можно только с контроллера ведущего сайта.

Ведомые сайты могут быть активными и пассивными.

Пассивный ведомый сайт только обрабатывает поступающие подключения клиентов, если ведущий сайт выбирает его локальные VS.
Активный ведомый сайт получает конфигурацию от ведущего сайта и, в случае его падения, может принять ведущую роль.

Сайтами GSLB могут быть и внешние сайты (External site), построенные на балансировщиках сторонних производителей.

Глобальный пул (global pool) отличается от локального пула, который содержит локальные серверы. В глобальном пуле можно объединить географически разнесенные виртуальные сервисы с разных сайтов. Другими словами, глобальный пул содержит локальные VS, которые заведены на уровне GSLB-сайтов.

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

по алгоритму Round Robin,
по геолокации серверов,
на основе топологии, которая заранее настраивается в политиках глобального сервиса
на основе Consistent Hash.

Для одного глобального сервиса можно создать несколько глобальных пулов и включить в каждый локальные VS одного или нескольких сайтов. В этом случае новые подключения будут распределяться по геолокации или по заданным приоритетам. Чтобы настроить приоритеты для серверов пула, можно установить для каждого свой вес.

Пример балансировки между глобальными пулами. Вот как глобальный VS будет распределять подключения в этой схеме:

Пул GslbPool_3 имеет приоритет 10 и будет предпочтительнее для клиентских подключений. Из этих подключений 40% нагрузки будет поступать на VS-B3 и 60% на VS-B4. Если GslbPool_3 станет недоступен, все клиентские подключения полностью перейдут на GslbPool_2, а нагрузка между VS-B3 и VS-B4 распределится равномерно.

Локальные DNS содержат записи с FQDN-именами балансируемых через него сервисов.

GSLB DNS — режим работы локального DNS VS, который используется для балансировки подключений между GSLB-сайтами.

Локальный DNS VS начинает выполнять роль GSLB DNS, когда мы выбираем его в качестве DNS-сервиса для поднятого GSLB. Такой DNS VS должен быть развернут на всех сайтах, включенных в глобальные пулы.

GSLB добавляет записи с FQDN-именами глобальных сервисов в каждый из локальных DNS. NSX ALB вносит в эту запись виртуальные IP локальных VS со всех сайтов, включенных в пул глобального VS. Эти дополнительные VIP добавляются автоматически с добавлением в пул новых локальных VS. Данные в записях обновляются по мере накопления информации о загрузке сервиса, доступности серверов и удаленности клиентов от сайтов. Когда новый клиент подключается по FQDN, один из локальных DNS выдает VIP-адрес локального VS, учитывая эти накопленные актуальные данные.

Как развернуть и настроить систему NSX ALB, а также поднять в ней сервис GSLB, я опишу во второй части этой статьи.