Возможности Load Balancer в NSX (vCloud Director 10)

NSX Edge Load Balancer – балансировщик нагрузки, который предназначен для распределения сетевого трафика с публичного IP-адреса на виртуальные серверы, расположенные в облачной инфраструктуре.

Балансировка нагрузки помогает добиться оптимального использования ресурсов, максимизировать пропускную способность, минимизировать время отклика и избежать перегрузок серверов. Load Balancer принимает запросы TCP, UDP, HTTP или HTTPs на публичный IP-адрес и, с помощью выбранного алгоритма, решает, какой сервер использовать.

Global Configuration

• Переходим во вкладку Load Balancer -> Global Configuration.
• Для включения сервиса Load Balancer нужно перевести значение элемента Status в Enabled и сохранить.
• Load Balancer поддерживает механизмы балансировки нагрузки на 4 и 7 уровнях модели OSI.
• Когда выключен параметр Acceleration Enabled, то все виртуальные IP-адреса (VIPs) используют механизм L7 LB.
• Когда включен параметр Acceleration Enabled и нет настроек L7, таких как cookie persistence у используемого Application Profile и SSL-Offload, то виртуальные IP-адреса будут применять более быстрый механизм L4.
  • L4 VIP обрабатывается до Edge Firewall и для достижения VIP не требуется Firewall-правило. Однако, если VIP использует пул не в режиме Transparent, то Edge Firewall должен быть включен (чтобы разрешить автоматически созданное SNAT-правило).
  • L7 VIP обрабатывается после Edge Firewall, и требует разрешающего Firewall-правила, чтобы достигнуть VIP.
  • Рекомендуем не использовать LB L4 (выключить Acceleration Enabled), так как могут возникнуть проблемы с SSL и могут обрабатываться не все созданные правила.
• Также у балансировщика нагрузки есть возможность собирать логи трафика.

Service Monitor

Определяет параметры проверки работоспособности серверов для определенного типа сетевого трафика.

По умолчанию доступно 3 вида мониторинга:

• tcp
• http
• https

Также поддерживаются протоколы ICMP, UDP, DNS, MSSQL и LDAP. Если необходимо добавить мониторинг для одного из этих протоколов, то нужно создать новый Service Monitor, нажав на кнопку «+».

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

Application Profile

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

• Type – тип трафика для балансировки. Доступны: TCP, HTTP, HTTPS, UDP.
• Enable SSL Passtrough - передача HTTPS-трафика на внутренний сервер без расшифровки трафика на балансировщике нагрузки. Данные хранятся в зашифрованном виде при прохождении через балансировщик нагрузки.
• HTTP Redirect URL – создание редиректа на другую страницу. Может использоваться для редиректа на HTTPS.
  • Persistence позволяет отслеживать данные сеанса по файлам cookie или IP-адресу источника.
  • Если в Persistence вы выбрали отслеживание сеансов по файлам cookie, то в Cookie Name введите имя необходимого файла cookie и в Mode выберите подходящий режим.
• Доступные режимы (Mode):
  • Insert - NSX Edge отправляет файл cookie. Если сервер отправляет один или несколько файлов cookie, то клиент дополнительно получает их.
  • Prefix - выберите этот режим, если ваш клиент не поддерживает более одного файла cookie. Все браузеры принимают несколько файлов cookie. Если у вас есть собственное приложение, использующее собственный клиент, который поддерживает только один файл cookie, веб-сервер отправляет свой файл cookie в обычном режиме. NSX Edge добавляет информацию о своих файлах cookie в качестве префикса в значение cookie сервера. Добавленная информация удаляется при отправке на сервер.
  • App Session - В этом режиме приложение не поддерживает новый файл cookie, добавляемый виртуальным сервером (insert), и не поддерживает измененный файл cookie (prefix). Виртуальный сервер запоминает файл cookie, введенный внутренним сервером. Когда клиент отправляет этот файл cookie, виртуальный сервер перенаправляет запрос клиента на тот же внутренний сервер.
• Expires In (Seconds) - введите срок действия Persistence в секундах. Значение по умолчанию — 60 секунд.
• Insert X-Forwarded-For HTTP header сохраняет исходный IP-адрес клиента, подключающегося через балансировщик нагрузки.
• Enable Pool Side SSL — включить связь HTTPS между балансировщиком нагрузки и внутренними серверами. Для этого весь пул должен состоять из HTTPS-серверов.

Pools

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

• Переходим во вкладку Pools, нажимаем на кнопку «+».
• У создаваемого пула указываем имя, алгоритм балансировки трафика, добавляем монитор, который подойдет под задачи балансировщика.
• Доступные алгоритмы:
  • ROUND_ROBIN использует каждый сервер по очереди в соответствии с назначенным ему весом.
  • IP-HASH выбирает сервер на основе хеша исходного IP-адреса и общего веса всех работающих серверов.
  • LEASTCONN распределяет клиентские запросы на одинаковые сервера в зависимости от количества текущих подключений. Новые запросы отправляются на сервер с меньшим количеством подключений.
  • URI хэширует левую часть URI и делит на общий вес работающих серверов. Полученный результат определяет, какой сервер получит запрос. Это гарантирует, что URI всегда будет направлен на один и тот же сервер, если ни один сервер не сменит состояние на UP/DOWN.
  • HTTPHEADER ищет HTTP-заголовок в каждом HTTP-запросе. Header заголовка в круглых скобках не чувствителен к регистру, аналогично функции ACL «hdr()». Если заголовок отсутствует или не содержит никакого значения, применяется алгоритм циклического перебора.
  • URL ищет параметр URL, указанный в аргументе в строке каждого HTTP GET-запроса.
• Параметр Transparent необходим, чтобы сделать IP-адреса клиентов видимыми для серверов из пула.
• В разделе Members поочередно добавьте серверы в пул, нажав на «+».

• Можно создавать несколько пулов, используя одни и те же серверы.

• Чтобы просмотреть состояния серверов из пула, нажмите “Show pool statistics”. Если у сервера состояние UP, то значит Service Monitor успешно проверил его работоспособность. Если возникла проблема с тем, что у пула состояние DOWN, но при проверке выбранный тип трафика проходит, то можно попробовать использовать другой Service Monitor.

Application Rules

Во вкладке Application Rules вы можете создавать правила для управления трафиком на стороне виртуального сервера, используя синтаксис HAProxy.

К примеру, это может понадобиться для маршрутизации запросов в определенный пул в соответствии с доменным именем. Следующее правило направляет запросы к foo.com в pool_1, а запросы к bar.com в pool_2.

Создаем политику определения запроса к сайту. hdr_dom(host) содержит адрес сайта, и если он совпадает с написанным (-i foo), то подходит под политику is_foo: acl is_foo hdr_dom(host) -i foo
Используем имя политики acl в условии use_backend pool_1 if is_foo для прямой маршрутизации запроса к нужному пулу.

Другие популярные примеры правил вы можете найти здесь: Application Rule Examples.

Virtual Server

Виртуальный сервер - это внутренний или uplink интерфейс NSX Edge, используемый для перенаправления трафика. Клиент будет подключаться к виртуальному серверу по указанному порту и его трафик будет поступать в пул, после чего перенаправляться по выделенным серверам.

• Enable Virtual Server – включить виртуальный сервер
• Enable Acceleration – включить режим Acceleration. Указывайте так же, как во вкладке Global Configuration.
• Application Profile – выбрать ранее созданный Application Profile.
• Name и Description – имя и описание создаваемого виртуального сервера соответственно.
• IP Address – выберите ваш внешний (публичный) IP-адрес.
• Protocol - протокол, который обрабатывает виртуальный сервер.
• Default Pool – пул, с которым будет работать виртуальный сервер.
• Connection Limit - максимальное количество одновременных подключений, которые может обрабатывать виртуальный сервер.
• Connection Rate Limit (CPS) - максимальное количество входящих новых запросов на подключение в секунду.
• Во вкладке Advanced можно добавить ранее созданные Application Rules.

Применение изменений

Для применения всех изменений у балансировщика нагрузки, необходимо вернуться на вкладку Global Configuration, у параметра Status перевести значение на Disabled, затем переключить обратно на Enabled и сделать сохранение изменений.

Обратите внимание, что иногда изменения не сразу вступают в силу, потребуется немного времени.

Создание Firewall-правил

Для того, чтобы балансировщик нагрузки был доступен вне вашей сети, не забудьте перейти в NSX Edge и создать Firewall-правила, открывающие порты, которые указали ранее в Virtual Servers.

В Source вы можете ограничить доступ для всех IP-адресов, кроме необходимых, а в Service -> Destination Port указать выбранный порт.

Процесс создания Firewall-правила также отображен в нашей инструкции: Настройка NSX Firewall в vCloud Director 10.

Пример использования Load Balancer

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

Какие настройки были произведены:

• Pools - было создано 2 пула, состоящих из 3 одинаковых серверов: для HTTP и HTTPS запросов. Соответственно, у серверов, в зависимости от пула, выставляем 80 или 443 порты и указываем для мониторинга default_http_monitor, либо default_https_monitor.
  • В качестве алгоритма был выбран LEASTCONN. Первый запрос поступает на случайно выбранный сервер, второй запрос отправляется на один из двух оставшихся, а третий на последний оставшийся в пуле сервер.

• Virtual Servers – Так как создано 2 пула, то по аналогии создаем 2 виртуальных сервера. У каждого выбираем протокол HTTP, либо HTTPS исходя из пула.

• Application Profiles, Application Rules и Service Monitoring – Без изменений.

Проверка

Для начала проверим работу для HTTPS-запросов.
Первый запрос пришел на первый сервер. Оставляем сессию открытой:

Второй запрос был направлен на третий сервер. Также оставляем активную сессию:

Третий запрос поступил на оставшийся, второй сервер:

Теперь проверим работу для HTTP-запросов. Несмотря на то, что в Virtual Server для HTTP-запросов мы указали порт 42679, подключение происходит по HTTPS по портам 14903, 23985 и 38911. Это связано с тем, что на серверах в конфигурации nginx для 80 порта настроены соответствующие редиректы:

Обратите внимание, что при таком сценарии нужно использовать return 302, а не 301, так как иначе в браузере будет сохраняться SSL-кеш и у пользователя редирект всегда будет на один и тот же порт, то есть использование балансировщика будет бессмысленным. Также необходимо в Firewall открыть порты, на которые настроены редиректы.

Первый запрос поступил на второй сервер:

Второй запрос отправился на первый сервер:

Третий запрос, как и ожидалось, пришел на третий сервер.

Другие сценарии использования балансировщика нагрузки вы можете найти здесь:
Scenarios for NSX Load Balancer Configuration (vmware.com)