В этом режиме NSX Edge при отправке запроса на один из бэкендов использует свой IP-адрес в качестве адреса источника. Таким образом, балансировщик выполняет одновременно функции Source и Destination NAT. Бэкенд видит весь трафик как отправленный с балансировщика и отвечает ему напрямую. В такой схеме балансировщик должен быть в одном сетевом сегменте с внутренними серверами. При этом происходит следующее:
Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
Edge выполняет source NAT, заменяя адрес отправившего запрос пользователя на свой собственный.
Пакет отправляется к выбранному бэкенду.
Бэкенд отвечает не напрямую пользователю, а Edge, так как изначальный адрес пользователя был изменен на адрес балансировщика.
В этом сценарии балансировщик имеет интерфейсы во внутренней и внешней сети. При этом ко внутренней сети нет прямого доступа из внешней. Встроенный балансировщик нагрузки действует как шлюз NAT для виртуальных машин во внутренней сети. Механизм работы следующий:
Пользователь отправляет запрос на VIP-адрес (адрес балансировщика), который сконфигурирован на Edge.
Edge выбирает один из бэкендов и выполняет destination NAT, заменяя VIP-адрес на адрес выбранного бэкенда.
Пакет отправляется к выбранному бэкенду.
Бэкенд получает запрос с изначальным адресом пользователя (source NAT не выполнялся) и отвечает ему напрямую.
Трафик снова принимается балансировщиком нагрузки, так как в inline схеме он обычно выступает в качестве шлюза по умолчанию для фермы серверов.
Edge выполняет source NAT для отправки трафика пользователю, используя свой VIP в качестве source IP-адреса.
Application profiles предоставляют более полный контроль над сетевым трафиком. С их помощью можно определять поведение конкретных типов трафика.
На вкладке Edge выберите нужный edge.
Нажмите кнопку Configure services.
Перейдите на вкладку Load Balancer.
В поле Enable активируйте переключатель, чтобы включить балансировщик. Активация опции Acceleration enabled позволяет балансировщику использовать более быструю L4-балансировку вместо L7.
Перейдите на вкладку Application profile, чтобы задать профиль приложения. Нажмите кнопку +.
Задайте название профиля и выберите тип трафика, для которого профиль будет применен:
Persistence — сохраняет и отслеживает данные сеанса, например: какой конкретный сервер из пула обслуживает пользовательский запрос. Это позволяет гарантировать, что запросы пользователя направляются одному и тому же члену пула в течение всей жизни сеанса или последующих сеансов;
Enable SSL passthrough — при выборе этой опции NSX Edge перестает терминировать SSL. Вместо этого терминация происходит непосредственно на серверах, для которых выполняется балансировка;
Insert X-Forwarded-For HTTP header — позволяет определять исходный IP-адрес клиента, подключающегося к веб-серверу через балансировщик;
Enable Pool Side SSL — позволяет указать, что выбранный пул состоит из HTTPS-серверов.
Для балансировки HTTPS-трафика включите Pool Side SSL и выберите сгенерированный ранее сертификат на вкладке Virtual Server Certificates → Service Certificate.
Аналогично для Pool Certificates → Service Certificate.
¶ Создание пула серверов, трафик к которым будет балансироваться Pools
Перейдите на вкладку Pools и нажмите +.
В открывшемся окне задайте имя пула, выберите алгоритм и тип мониторинга для 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 всегда отправлялся на один и тот же сервер, до тех пор, пока все серверы остаются доступными.
Для добавления серверов в пул в блоке Members нажмите +.
В открывшемся окне укажите:
имя сервера;
IP-адрес сервера;
порт, на который сервер будет получать трафик;
порт для health check (Monitor healthcheck);
вес (Weight) — с помощью этого параметра можно регулировать пропорциональное количество получаемого трафика для конкретного члена пула;
Max Connections — максимальное количество соединений к серверу;
Min Connections — минимальное количество соединений, которое должен обработать сервер, прежде чем трафик будет перенаправлен следующему члену пула.
Активируйте виртуальный сервер с помощью Enable Virtual Server. В открывшемся окне задайте название, выберите созданные ранее Application Profile, Pool и укажите IP-адрес, на который Virtual Server будет принимать запросы извне.
Укажите протокол и порт.
Дополнительно можно задать следующие параметры:
Connection Limit — максимальное количество одновременных соединений, которые может обработать виртуальный сервер;
Connection Rate Limit (CPS) — максимальное количество новых входящих запросов в секунду.
На этом конфигурация балансировщика завершена, можно проверить его работоспособность. Серверы имеют простейшую конфигурацию, позволяющую понять, каким именно сервером из пула был обработан запрос. Во время настройки был выбран алгоритм балансировки Round Robin, а параметр Weight для каждого сервера равен единице, поэтому каждый следующий запрос будет обрабатываться следующим сервером из пула.
Проверка статуса:
show service loadbalancer pool.
Проверка статуса балансировщика из консоли Edge gateway
¶ Настройка Service Monitor для проверки состояния серверов в пуле
С помощью Service Monitor можно отслеживать состояние серверов в бэкенд-пуле. Если ответ на запрос не соответствует ожидаемому, сервер можно вывести из пула, чтобы он не получал никаких новых запросов.
По умолчанию сконфигурировано три метода проверки:
TCP-monitor;
HTTP-monitor;
HTTPS-monitor.
Для создания нового Service Monitor:
В настройках edge перейдите на вкладку Service Monitoring и нажмите +.
В открывшемся окне укажите:
имя для нового метода;
интервал, с которым будут отправляться запросы;
тайм-аут ожидания ответа;
тип мониторинга — HTTPS request с использованием метода GET, ожидаемый status code — 200(OK) и URL запроса.
Настройка нового Service Monitor закончена, далее его можно использовать при создании пула.
Application Rules — способ управления трафиком, основанный на определенных запросах. Можно создать расширенные правила балансировки нагрузки, настройка которых может быть невозможна через Application profiles или с помощью других сервисов, доступных на Edge Gateway. Для создания правила:
Перейдите на вкладку Application Rules балансировщика.
В открывшемся окне укажите имя, скрипт, который будет использовать правило, и нажмите Keep.
После того как правило создано, отредактируйте уже настроенный сервер на вкладке Virtual Server.
С помощью этого скрипта можно перенаправить трафик в другой пул балансировки, если основной пул не работает. Чтобы правило сработало, на балансировщике должно быть сконфигурировано несколько пулов и все члены основного пула должны быть в состоянии down. Указывать нужно именно имя пула, а не его ID:
acl pool_down nbsrv(PRIMARY_POOL_NAME) eq 0 use_backend SECONDARY_POOL_NAME if PRIMARY_POOL_NAME