- PVSM.RU - https://www.pvsm.ru -
Часть первая. Вводная [1]
Часть вторая. Настройка правил Firewall и NAT [2]
Часть третья. Настройка DHCP [3]
Часть четвертая. Настройка маршрутизации [4]
В прошлый раз мы говорили о возможностях NSX Edge в разрезе статической и динамической маршрутизации, а сегодня будем разбираться с балансировщиком.
Прежде чем приступить к настройке, я хотел бы совсем кратко напомнить об основных видах балансировки.
Все сегодняшние решения по балансировке полезной нагрузки чаще всего делят на две категории: балансировка на четвертом (транспортном) и седьмом (прикладном) уровнях модели OSI [5]. Модель OSI не самая лучшая референтная точка при описании методов балансировки. Например, если L4-балансировщик также поддерживает терминирование TLS, становится ли он в таком случае L7-балансировщиком? Но что есть, то есть.
Независимо от типа балансировщик может поддерживать следующие функции:
NSX Edge предлагает поддержку двух режимов развертывания балансировщика:
Режим прокси, или one-arm. В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами.
Вот как это происходит:
Схема ниже.
Прозрачный, или inline, режим. В этом сценарии балансировщик имеет интерфейсы во внутренней и внешней сети. При этом ко внутренней сети нет прямого доступа из внешней. Встроенный балансировщик нагрузки действует как шлюз NAT для виртуальных машин во внутренней сети.
Механизм следующий:
Схема ниже.
На моем тестовом стенде настроены 3 сервера с Apache, который сконфигурирован для работы по HTTPS. Edge будет выполнять балансировку HTTPS-запросов по методу round robin, проксируя каждый новый запрос на новый сервер.
Приступим.
Вы можете импортировать валидный CA-сертификат или использовать самоподписанный. В этом тесте я воспользуюсь самоподписанным.
Application profiles дают более полный контроль над сетевым трафиком и делают управление им простым и эффективным. С их помощью можно определять поведение для конкретных типов трафика.
Persistence – сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов.
Enable SSL passthrough – при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка.
Insert X-Forwarded-For HTTP header – позволяет определять исходный IP-адрес клиента, подключающегося к веб-серверу через балансировщик.
Enable Pool Side SSL – позволяет указать, что выбранный пул состоит из HTTPS-серверов.
NSX поддерживает следующие алгоритмы балансировки:
Здесь нужно указать:
Вот так выглядит итоговый пул из трех серверов.
Задаем ему имя, выбираем созданные ранее 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 мы можем отслеживать состояние серверов в бэкенд пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.
По умолчанию сконфигурировано три метода проверки:
Создадим новый.
Application Rules – способ манипулирования трафиком, основанный на определенных триггерах. С помощью этого инструмента мы можем создавать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway.
В примере выше мы включили поддержку 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
Еще больше примеров тут [6].
На этом про балансировщик у меня все. Если остались вопросы, спрашивайте, я готов ответить.
Автор: dataline
Источник [7]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/virtualizatsiya/315006
Ссылки в тексте:
[1] Часть первая. Вводная: https://habr.com/ru/company/dataline/blog/432980/
[2] Часть вторая. Настройка правил Firewall и NAT: https://habr.com/ru/company/dataline/blog/441026/
[3] Часть третья. Настройка DHCP: https://habr.com/ru/company/dataline/blog/441882/
[4] Часть четвертая. Настройка маршрутизации: https://habr.com/ru/company/dataline/blog/444644/
[5] OSI: https://ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI
[6] тут: https://docs.vmware.com/en/VMware-NSX-Data-Center-for-vSphere/6.3/com.vmware.nsx.admin.doc/GUID-A5779D43-AC0F-4407-AF4A-0C1622394452.html
[7] Источник: https://habr.com/ru/post/448540/?utm_source=habrahabr&utm_medium=rss&utm_campaign=448540
Нажмите здесь для печати.