Балансировщики нагрузки
Облачный балансировщик нагрузки распределяет входящий сетевой трафик между облачными серверами в одном пуле. Балансировщик нагрузки можно использовать для повышения доступности сервисов — он оптимально распределит запросы между серверам и и снизит нагрузку. Если один сервер выйдет из строя, балансировщик перенаправит трафик на другой подходящий сервер.
Балансировщик работает на уровнях L3-L4 (network load balancer) и L7 (application load balancer). Для балансировки HTTPS-трафика используются TLS(SSL)-сертификаты из менеджера секретов, подробнее в инструкции TLS(SSL)-сертификаты балансировщика нагрузки.
Работать с балансировщиком нагрузки можно в панели управления, через OpenStack CLI или Terraform.
В облачных балансировщиках поддерживаются типы и роли пользователей.
Записи об операциях с облачным балансировщиком сохраняются в аудит-логах.
Если балансировщик нужен для работы с кластером Managed Kubernetes, для создания и настройки балансировщика используйте только kubectl. Подробнее в инструкции Настроить балансировщик нагрузки в разделе Managed Kubernetes.
Для отслеживания метрик балансировщика вы можете настроить мониторинг с использованием Prometheus, подробнее о доступных метриках и настройке мониторинга в инструкции Мониторинг облачного балансировщика нагрузки. Вы также можете собирать логи балансировщика.
Типы балансировщика нагрузки
Если типы не подходят, вы можете заказать кастомный тип балансировщика — создайте тикет.
Список флейворов балансировщика нагрузки
Флейворы соответствуют типам балансировщика нагрузки и определяют количество vCPU, RAM и количество инстансов балансировщика.
Для создания балансировщиков нагрузки через OpenStack CLI и Terraform используются ID или имена флейворов. ID различаются в пулах.
Например, ac18763b-1fc5-457d-9fa7-b0d339ffb336 — ID, а AMPH1.ACT_STNDB.4-2048 — имя флейвора, который соответствует типу Продвинутый с резервированием в пуле ru-9.
Можно посмотреть список флейворов балансировщика нагрузки во всех пулах в таблице или посмотреть список флейворов балансировщика нагруз ки в определенном пуле через OpenStack CLI.
Список флейворов балансировщика нагрузки во всех пулах
- Санкт-Петербург
- Москва
- Новосибирск
- Ташкент
- Алматы
- Найроби
- ru-3
- ru-1
- ru-9
- ru-2
- ru-7
- ru-8
- uz-1
- uz-2
- kz-1
- ke-1
Здесь:
ID— ID флейвора балансировщика нагрузки;Имя— имя флейвора, которое соответствует типу балансировщика нагрузки:AMPH1.SNGL.2-1024— тип Базовый без резервирования;AMPH1.ACT_STNDB.2-1024— тип Базовый с резервированием;AMPH1.ACT_STNDB.4-2048— тип Продвинутый с резервированием.
Посмотреть список флейворов балансировщика нагрузки в определенном пуле
-
Посмотрите список флейворов:
openstack loadbalancer flavor list -c id -c nameПример ответа для пула ru-9:
+--------------------------------------+------------------------+
| id | name |
+--------------------------------------+------------------------+
| 3265f75f-01eb-456d-9088-44b813d29a60 | AMPH1.SNGL.2-1024 |
| d3b8898c-af94-47f8-9996-65b9c6aa95e2 | AMPH1.ACT_STNDB.2-1024 |
| ac18763b-1fc5-457d-9fa7-b0d339ffb336 | AMPH1.ACT_STNDB.4-2048 |
+--------------------------------------+------------------------+Здесь:
id— ID флейвора балансировщика нагрузки;name— имя флейвора, которое соответствует типу балансировщика нагрузки:AMPH1.SNGL.2-1024— тип Базовый без резервирования;AMPH1.ACT_STNDB.2-1024— тип Базовый с резервированием;AMPH1.ACT_STNDB.4-2048— тип Продвинутый с резервированием.
Как работает балансировщик нагрузки
В балансировщике нагрузки используется модель OpenStack Octavia, которая включает в себя:
- инстанс (amphora) — выполняет балансировку нагрузки. Запускается на облачном сервере и использует HAProxy (High-Availability Proxy) — программное обеспечение для проксирования трафика. В балансировщиках с резервированием (типов Базовый с резервированием и Продвинутый с резервированием) создается два инстанса, без резервирования — один;
- целевая группа (pool) — группа серверов, к которой правило перенаправляет запросы по указанному для группы протоколу;
- серверы (members) — серверы, которые обслуживают трафик в пуле. Доступны по IP-адресу и порту, которые указаны для сервера в рамках целевой группы;
- проверки доступности (health monitor) — процесс провер ки работоспособности всех серверов в целевой группе;
- правило (listener) — прослушивает поступающий на балансировщик нагрузки поток трафика, используя указанные в правиле протоколы и порты. Затем маршрутизирует трафик к необходимой группе серверов;
- HTTP-политика (L7 Policy) — дополнительные условия в правиле для маршрутизации HTTP-трафика с определенными параметрами.
Целевые группы
Целевая группа — группа серверов, на которые распределяется трафик с балансировщика нагрузки. Сервер может входить в несколько целевых групп одного балансировщика, если в этих группах для сервера указаны разные порты.
Для целевой группы можно настроить:
- протоколы и порты для приема трафика от балансировщика нагрузки;
- алгоритмы, по которым распределяются запросы;
- проверки доступности для отслеживания состояния серверов.
Проверки доступности
Для целевой группы можно включить проверку доступности. Балансировщик будет отслеживать состояние серверов — если какой-либо сервер окажется неработоспособным, балансировщик перенаправит соединение на другой.
Параметры проверки:
-
тип проверки. В зависимости от протокола целевой группы доступны типы:
- группа TCP — TCP, PING;
- группа PROXY — TLS-HELLO, HTTP, TCP, PING;
- группа UDP — UDP-CONNECT, PING;
- группа HTTP — HTTP, TCP, PING;
-
для протокола проверки HTTP можно настроить обращение к URL и ожидаемые коды ответа;
-
интервал между проверками — интервал в секундах, с которым балансировщик отправляет проверяющие запросы серверам;
-
таймаут соединения — время ожидания ответа;
-
порог успеха — количество успешных обращений подряд, после которых сервер переводится в рабочее состояние;
-
порог неуспеха — количество неуспешных обращений подряд, после которых работа сервера приостанавливается.
Правила
Правило — настройки балансировщика, которые обслуживают поток трафика с конкретным портом и протоколом и распределяют этот трафик на нужную группу серверов.
В правиле можно настроить:
- протоколы и порты входящего трафика балансировщика нагрузки;
- HTTP-политики для дополнительной маршрутизации HTTP-трафика;
- соединения, проходящие через балансировщик;
- выбрать целевую группу серверов.
Количество правил в балансировщике не ограничено.
HTTP-политики
HTTP-политика — дополнение в правиле, которое позволяет маршрутизировать определенный HTTP- и HTTPS-трафик отдельно от остального трафика:
- направлять на другую целевую группу (REDIRECT_TO_POOL);
- направлять на URL — полностью заменять URL запроса, включая протокол, доменное имя, путь и параметры запроса (REDIRECT_TO_URL);
- направлять на префикс URL — заменять протокол и доменное имя в URL запроса (REDIRECT_PREFIX);
- отклонять (REJECT).
Запрос перенаправляется по первой подходящей политике. Порядок применения политик зависит от действия политики: сначала применяются политики REJECT, затем REDIRECT_TO_URL и REDIRECT_PREFIX, затем REDIRECT_TO_POOL. Если в правиле несколько политик с одинаковым действием, они применяются согласно позиции политики в правиле. Вы можете изменить порядок применения политик.
HTTP-политика состоит из набора условий, количество условий в политике не ограничено. Чтобы запрос попал под политику, он должен соответствовать всем условиям политики. В условии указываются:
- параметр запроса для проверки:
HOST_NAMEилиPATH. При настройке политики через OpenStack CLI также можно создать условие по параметрамCOOKIE,FILE_TYPEиHEADER; - контрольное значение для проверки — точное значение или регулярное выражение;
- тип совпадения с контрольным значением:
EQUAL TO,STARTS WITH,ENDS WITH,CONTAINS,REGEX.
Количество HTTP-политик в правиле не ограничено.
Порты балансировщика нагрузки
Инстансы балансировщика нагрузки используют несколько портов:
- входящий порт (uplink). Это виртуальный порт, на котором размещается VIP — виртуальный IP-адрес. На нем правило прослушивает входящий трафик. Выделяется при создании балансировщика нагрузки и находится в его подсети. У балансировщиков с резервированием (типов Базовый с резервированием и Продвинутый с резервированием) VIP резервируется по протоколу VRRP;
- служебные VRRP-порты. При создании базового балансировщика нагрузки в его подсети выделяется один служебный порт. При создании балансировщика с резервированием выделяется два служебных порта для основного и резервного инстанса, между ними настраивается VRRP;
- служебные порты (downlinks). Если серверы находятся не в подсети балансировщика, то при его создании в подсетях с серверами выделяются порты для инстансов: для базового балансировщика один порт, для балансировщиков с резервированием — два порта (основной и резервный).
При неполадках в работе балансировщика нагрузки он автоматически создает новый инстанс и только потом удаляет старый — для этого нужен свободный порт. Если свободного порта не будет, балансировщик перейдет в статус ERROR.
Если при создании балансировщика нагрузки вы выбрали в качестве подсети балансировщика публичную подсеть и будете размещать в ней серверы, то убедитесь, что в ней есть дополнительный IP-адрес, или используйте публичную сеть размером от /28.
Мы рекомендуем выбирать приватную сеть с публичным IP-адресом (адрес нужен для доступа в интернет) — в таком случае для пересоздания инстанса всегда будет доступен свободный IP-адрес. Балан сировка трафика будет производиться внутри приватной сети.
Протоколы
Доступны комбинации протоколов:
- TCP–TCP — классическая L4-балансировка;
- TCP–PROXY — информация о клиенте не теряется и передается в отдельном заголовке соединения;
- UDP–UDP — UDP-протокол быстрее, чем TCP, но менее надежен;
- HTTP–HTTP — L7-балансировка;
- HTTPS–HTTP — L7-балансировка с шифрованием и терминацией SSL-сертификата на балансировщике.
Алгоритмы распределения запросов
Правило распределяет запросы по выбранному алгоритму. Доступно два алгоритма:
- Round Robin — алгоритм кругового обслуживания. Первый запрос передается одному серверу, следующий запрос — другому и так далее до достижения последнего сервера. Затем цикл начинается сначала. Запросы распределяются на серверы в соответствии с заданным весом.
- Least connections — алгоритм учитывает количество подключений к серверам. Новый запрос п ередается серверу с наименьшим количеством активных подключений, вес сервера не учитывается.
Sticky Sessions
Дополнительно можно включить Sticky Sessions. Метод необходим, когда конечное приложение держит длительное соединение с каждым клиентом и сохраняет внутреннее состояние данных, которое не синхронизируется между серверами в правиле.
Новые запросы будут распределяться по выбранному алгоритму, а затем сессия закрепится за сервером, который начал обрабатывать запросы. Все последующие запросы этой сессии будут распределяться на сервер, не учитывая выбранный алгоритм. Если сервер недоступен, запрос перенаправится на другой.
Параметры определения сессии можно настроить — балансировать сессии или балансировать одного клиента на один сервер. Можно идентифицировать сессию:
- по APP-cookie — уже существующая cookie, которая задана в коде приложения;
- по HTTP-cookie — cookie, которую создает и прикрепляет к сессии балансировщик;
- по Source IP — IP-адрес клиента хешируется и делится на вес каждого сервера в целевой группе — так определяется сервер, который будет обрабатывать запросы.
Настройки соединений
Можно задать настройки соединений, проходящих через балансировщик, — между входящими запросами и балансировщиком, балансировщиком и серверами.
Настройки соединений:
- таймаут соединения — время ожидания ответа;
- максимум соединений — максимальное количество активных соединений;
- таймаут неактивности — время, в течение которого подключение считается активным, даже если данные не передаются;
- таймаут ожидания TCP-пакетов — время, в течение которого балансировщик ждет передачи данных для инспекции по уже установленному соединению.
Заголовки HTTP-запросов
В обычном режиме работы балансировщик передает серверу только исходное тело HTTP-запроса, заменяя IP-адрес клиента на свой.
Включите необходимые типы дополнительных заголовков в запрос, чтобы серверы получали эту информацию для корректной работы или анализа:
X-Forwarded-For— IP-адрес, с которого пришел запрос;X-Forwarded-Port— порт балансировщика, на который пришел запрос;X-Forwarded-Proto— исходный протокол соединения;X-SSL-Client-Verify— использовал ли клиент защищенное соединение;X-SSL-Client-Has-Cert— наличие сертификата у клиента;X-SSL-Client-DN— идентификационная информация владельца;X-SSL-Client-CN— имя хоста, для которого выпущен сертификат;X-SSL-Issuer— центр сертифика ции, в котором был выпущен сертификат;X-SSL-Client-SHA1— SHA1-отпечаток клиентского сертификата;X-SSL-Client-Not-Before— начало действия сертификата;X-SSL-Client-Not-After— окончание действия сертификата.
Стоимость
Балансировщики оплачиваются по модели оплаты облачной платформы.
Стоимость балансировщиков можно посмотреть на servercore.com.