VMware NSX для самых маленьких. Часть 5. Настройка балансировщика нагрузки

Часть первая. Вводная
Часть вторая. Настройка правил Firewall и NAT
Часть третья. Настройка DHCP
Часть четвертая. Настройка маршрутизации

В прошлый раз мы говорили о возможностях NSX Edge в разрезе статической и динамической маршрутизации, а сегодня будем разбираться с балансировщиком.
Прежде чем приступить к настройке, я хотел бы совсем кратко напомнить об основных видах балансировки.

Теория

Все сегодняшние решения по балансировке полезной нагрузки чаще всего делят на две категории: балансировка на четвертом (транспортном) и седьмом (прикладном) уровнях модели OSI. Модель OSI не самая лучшая референтная точка при описании методов балансировки. Например, если L4-балансировщик также поддерживает терминирование TLS, становится ли он в таком случае L7-балансировщиком? Но что есть, то есть.

• Балансировщик L4 чаще всего представляет собой стоящий между клиентом и набором доступных бэкендов middle proxy, который терминирует TCP-соединения (то есть самостоятельно отвечает на SYN), выбирает бэкенд и инициирует в его сторону новую TCP-сессию, самостоятельно отправляя SYN. Этот тип – один из базовых, возможны и другие варианты.
• Балансировщик L7 распределяет трафик по доступным бэкендам «изощреннее», чем это делает L4-балансировщик. Он может принимать решение о выборе бэкенда на основе, например, содержимого сообщения HTTP (URL-адрес, файл cookie и т.д.).

Независимо от типа балансировщик может поддерживать следующие функции:

• Обнаружение сервисов – процесс определения набора доступных бэкендов (Static, DNS, Consul, Etcd и т.д).
• Проверка работоспособности обнаруженных бэкендов (активный «пинг» бэкенда с помощью HTTP-запроса, пассивное обнаружение проблем в TCP-соединениях, наличие в ответах нескольких подряд 503 HTTP-code и т.д.).
• Сама балансировка (round robin, random selection, source IP hash, URI).
• Терминирование TLS и верификация сертификатов.
• Опции, связанные с обеспечением безопасности (аутентификация, предотвращение DoS-атак, ограничение скорости) и многое другое.

NSX Edge предлагает поддержку двух режимов развертывания балансировщика:

Режим прокси, или one-arm. В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами.

Вот как это происходит:
1.       Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
2.       Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
3.       Edge выполняет source NAT, заменяя адрес отправившего запрос пользователя на свой собственный.
4.       Пакет отправляется к выбранному бэкенду.
5.       Бэкенд отвечает не напрямую пользователю, а Edge, так как изначальный адрес пользователя был изменен на адрес балансировщика.
6.       Edge передает ответ сервера пользователю.
Схема ниже.


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

Механизм следующий:
1.       Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
2.       Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
3.       Пакет отправляется к выбранному бэкенду.
4.       Бэкенд получает запрос с изначальным адресом пользователя (source NAT не выполнялся) и отвечает ему напрямую.
5.       Трафик снова принимается балансировщиком нагрузки, так как в inline схеме он обычно выступает в качестве шлюза по умолчанию для фермы серверов.
6.       Edge выполняет source NAT для отправки трафика пользователю, используя свой VIP в качестве source IP-адреса.
Схема ниже.

Практика

На моем тестовом стенде настроены 3 сервера с Apache, который сконфигурирован для работы по HTTPS. Edge будет выполнять балансировку HTTPS-запросов по методу round robin, проксируя каждый новый запрос на новый сервер.
Приступим.

Генерируем SSL-сертификат, который будет использовать NSX Edge
Вы можете импортировать валидный CA-сертификат или использовать самоподписанный. В этом тесте я воспользуюсь самоподписанным.

1. В интерфейсе vCloud Director переходим в настройки сервисов Edge.
   
2. Переходим во вкладку Certificates. Из списка действий выбираем добавление нового CSR.
   
3. Заполняем необходимые поля и нажимаем Keep.
   
4. Выделяем только что созданный CSR и выбираем опцию self-sign CSR.
   
5. Выбираем срок валидности сертификата и нажимаем Keep
   
6. Самоподписанный сертификат появился в списке доступных.
   

Настраиваем Application Profile
Application profiles дают более полный контроль над сетевым трафиком и делают управление им простым и эффективным. С их помощью можно определять поведение для конкретных типов трафика.

1. Переходим во вкладку Load Balancer и включаем балансировщик. Опция Acceleration enabled здесь позволяет балансировщику использовать более быструю L4 балансировку вместо L7.
   
2. Переходим во вкладку Application profile, чтобы задать профиль приложения. Нажмите +.
   
3. Задаем название профиля и выбираем тип трафика, для которого профиль будет применен. Поясню некоторые параметры.
   Persistence – сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов.
   Enable SSL passthrough – при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка.
   Insert X-Forwarded-For HTTP header – позволяет определять исходный IP-адрес клиента, подключающегося к веб-серверу через балансировщик.
   Enable Pool Side SSL – позволяет указать, что выбранный пул состоит из HTTPS-серверов.
   
4. Так как я буду балансировать HTTPS-трафик, нужно включить Pool Side SSL и выбрать сгенерированный ранее сертификат во вкладке Virtual Server Certificates —> Service Certificate.
   
5. Аналогично для Pool Certificates —> Service Certificate.
   

Создаем пул серверов, трафик к которым будет балансироваться Pools

1. Переходим во вкладку Pools. Нажимаем +.
   
2. Задаем имя пула, выбираем алгоритм (я буду использовать round robin) и тип мониторинга для health check бэкенда.Опция Transparent указывает, видны ли изначальные source IP клиентов внутренним серверам.
   • Если опция выключена, трафик для внутренних серверов идет с source IP балансировщика.
   • Если опция включена, внутренние сервера видят source IP клиентов. В такой конфигурации NSX Edge должен выступать в качестве шлюза по умолчанию, чтобы гарантировать, что возвращаемые пакеты проходят через NSX Edge.

   NSX поддерживает следующие алгоритмы балансировки:

   • IP_HASH – выбор сервера на основе результатов выполнения хеш-функции для source и destination IP каждого пакета.
   • LEASTCONN – балансировка входящих соединений, в зависимости от количества уже имеющихся на конкретном сервере. Новые соединения будут направлены на сервер с наименьшим количеством соединений.
   • ROUND_ROBIN – новые соединения отправляются на каждый сервер по очереди, в соответствии с заданным ему весом.
   • URI – левая часть URI (до вопросительного знака) хешируется и делится на общий вес серверов в пуле. Результат указывает, какой сервер получает запрос, гарантируя, что запрос всегда направляется на один и тот же сервер, до тех пор, пока все серверы остаются доступными.
   • HTTPHEADER – балансировка на основе определенного заголовка HTTP, который можно указать в качестве параметра. Если заголовок отсутствует или не имеет какого-либо значения, применяется алгоритм ROUND_ROBIN.
   • URL – в каждом запросе HTTP GET выполняется поиск по параметру URL, указанному в качестве аргумента. Если за параметром следует знак равенства и значение, то значение хешируется и делится на общий вес запущенных серверов. Результат указывает, какой сервер получает запрос. Этот процесс используется для отслеживания идентификаторов пользователей в запросах и обеспечения того, чтобы один и тот же user id всегда отправлялся на один и тот же сервер, до тех пор, пока все серверы остаются доступными.

   

3. В блоке Members нажимаем +, чтобы добавить в пул серверы.
   
   
   Здесь нужно указать:
   • имя сервера;
   • IP-адрес сервера;
   • порт, на который сервер будет получать трафик;
   • порт для health check (Monitor healthcheck);
   • вес (Weight)  – с помощью этого параметра можно регулировать пропорциональное количество получаемого трафика для конкретного члена пула;
   • Max Connections – максимальное количество соединений к серверу;
   • Min Connections – минимальное количество соединений, которое должен обработать сервер, прежде чем трафик будет перенаправлен следующему члену пула.

   
   
   Вот так выглядит итоговый пул из трех серверов.
   

Добавляем Virtual Server

1. Переходим во вкладку Virtual Servers. Нажимаем +.
   
2. Активируем виртуальный сервер с помощью Enable Virtual Server.
   Задаем ему имя, выбираем созданные ранее Application Profile, Pool и указываем IP-адрес, на который Virtual Server будет принимать запросы извне. Указываем протокол HTTPS и порт 443.
   Опциональные параметры здесь:
   Connection Limit – максимальное количество одновременных соединений, которые может обработать виртуальный сервер;
   Connection Rate Limit (CPS) – максимальное количество новых входящих запросов в секунду.
   

На этом конфигурация балансировщика завершена, можно проверить его работоспособность. Сервера имеют простейшую конфигурацию, позволяющую понять, каким именно сервером из пула был обработан запрос. Во время настройки мы выбрали алгоритм балансировки Round Robin, а параметр Weight для каждого сервера равен единице, поэтому каждый следующий запрос будет обрабатываться следующим сервером из пула.
Вводим в браузере внешний адрес балансировщика и видим:


После обновления страницы запрос будет обработан следующим сервером:


И еще раз – чтобы проверить и третий сервер из пула:


При проверке можно видеть, что сертификат, который отправляет нам Edge, тот самый, что мы генерировали в самом начале.

Проверка статуса балансировщика из консоли Edge gateway. Для этого введите show service loadbalancer pool.


Настраиваем Service Monitor для проверки состояния серверов в пуле
С помощью Service Monitor мы можем отслеживать состояние серверов в бэкенд пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.
По умолчанию сконфигурировано три метода проверки:

• TCP-monitor,
• HTTP-monitor,
• HTTPS-monitor.

Создадим новый.

1. Переходим во вкладку Service Monitoring, нажимаем +.
   
2. Выбираем:
   • имя для нового метода;
   • интервал, с которым будут отправляться запросы,
   • тайм-аут ожидания ответа,
   • тип мониторинга – HTTPS request с использованием метода GET, ожидаемый status code – 200(OK) и URL запроса.
3. На этом настройка нового Service Monitor закончена, теперь мы можем использовать его при создании пула.
   

Настраиваем Application Rules

Application Rules – способ манипулирования трафиком, основанный на определенных триггерах. С помощью этого инструмента мы можем создавать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway.

1. Для создания правила переходим во вкладку Application Rules балансировщика.
   
2. Выбираем имя, скрипт, который будет использовать правило, и нажимаем Keep.
   
3. После того как правило создано, нам нужно отредактировать уже настроенный Virtual Server.
   
4. Во вкладке Advanced добавляем созданное нами правило.
   

В примере выше мы включили поддержку tlsv1.

Еще пара примеров:

Редирект трафика в другой пул.
С помощью этого скрипта мы можем перенаправить трафик в другой пул балансировки, если основной пул не работает. Чтобы правило сработало, на балансировщике должно быть сконфигурировано несколько пулов и все члены основного пула должны быть в состоянии down. Указывать нужно именно имя пула, а не его ID.

acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0
use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME


Редирект трафика на внешний ресурс.
Здесь мы перенаправляем трафик на внешний веб-сайт, если все участники основного пула в состоянии down.

acl pool_down nbsrv(NAME_OF_POOL) eq 0
redirect location http://www.example.com if pool_down

Еще больше примеров тут.

На этом про балансировщик у меня все. Если остались вопросы, спрашивайте, я готов ответить.

Источник: habr.com