Балансировщики нагрузки

Последнее изменение: 17 декабря 2024

Балансировщики нагрузки

Облачный балансировщик нагрузки распределяет входящий сетевой трафик между облачными серверами в одном пуле. Балансировщик нагрузки можно использовать для повышения доступности сервисов — он оптимально распределит запросы между серверами и снизит нагрузку. Если один сервер выйдет из строя, балансировщик перенаправит трафик на другой подходящий сервер.

Балансировщик работает на уровнях L3-L4 (network load balancer) и L7 (application load balancer). Для балансировки HTTPS-трафика используются TLS(SSL)-сертификаты из менеджера секретов, подробнее в инструкции TLS(SSL)-сертификаты балансировщика нагрузки.

Работать с балансировщиком нагрузки можно в панели управления, через OpenStack CLI или Terraform.

Для отслеживания метрик балансировщика вы можете настроить мониторинг с использованием Prometheus, подробнее о доступных метриках и настройке мониторинга в инструкции Мониторинг облачного балансировщика нагрузки.

Типы балансировщика нагрузки⁠

	Базовый без резервирования	Базовый с резервированием	Продвинутый с резервированием
Количество инстансов	Один	Два	Два
Конфигурация инстанса	2 vCPU, 1 ГБ RAM	2 vCPU, 1 ГБ RAM	4 vCPU, 2 ГБ RAM
Отказоустойчивость и резервирование	Только Single-режим	Аварийное переключение (Active-Standby Failover) на резервный инстанс в одном пуле	Аварийное переключение (Active-Standby Failover) на резервный инстанс в одном пуле
Для чего подойдет	Для тестовых окружений или проектов, для которых не нужна доступность сервиса 24 / 7	Для небольших и средних проектов, для которых критична доступность сервиса	Для проектов с высокой нагрузкой и требованием к постоянной доступности сервиса
Пропускная способность	До 3 Гбит/с. Можно увеличить до 5 Гбит/с — создайте тикет	До 3 Гбит/с. Можно увеличить до 5 Гбит/с — создайте тикет	До 3 Гбит/с. Можно увеличить до 5 Гбит/с — создайте тикет
Количество HTTP-запросов в секунду (RPS)	~19 500	~19 500	~34 000
Количество HTTPS-запросов с терминацией на балансировщике в секунду (RPS)	~3 000 keep-alive подключений (при 10 000 одновременных подключений по TCP)	~3 000 keep-alive подключений (при 10 000 одновременных подключений по TCP)	~9 000 keep-alive подключений (при 10 000 одновременных подключений по TCP)

Если типы не подходят, вы можете заказать кастомный тип балансировщика — создайте тикет.

Список флейворов балансировщика нагрузки⁠

Флейворы соответствуют типам балансировщика нагрузки и определяют количество vCPU, RAM и количество инстансов балансировщика.

Для создания балансировщиков нагрузки через OpenStack CLI и Terraform используются ID или имена флейворов. ID различаются в пулах.

примечание

Например, ac18763b-1fc5-457d-9fa7-b0d339ffb336 — ID, а AMPH1.ACT_STNDB.4-2048 — имя флейвора, который соответствует типу Продвинутый с резервированием в пуле ru-9.

Можно посмотреть список флейворов балансировщика нагрузки во всех пулах в таблице или посмотреть список флейворов балансировщика нагрузки в определенном пуле через OpenStack CLI.

Список флейворов балансировщика нагрузки во всех пулах⁠

Санкт-Петербург

ru-3

ID	Имя
d4490352-a58a-44b7-b226-717cd7607c0e	AMPH1.SNGL.2-1024
dbf2523f-39a5-4f34-be74-07eb3f111171	AMPH1.ACT_STNDB.2-1024
ea49b7dd-c126-4b22-8a2c-2eb65cbda662	AMPH1.ACT_STNDB.4-2048

ru-1

ID	Имя
10a221ac-f483-41c7-b9a8-79893317f5c6	AMPH1.SNGL.2-1024
06731413-f866-4497-a804-2feba12455be	AMPH1.ACT_STNDB.2-1024
f6538882-a867-4156-9cfd-d2e629b005c4	AMPH1.ACT_STNDB.4-2048

ru-9

ID	Имя
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

Москва

ru-2

ID	Имя
e1613cc2-62b9-4cc8-b0fb-a30cf0cca3f3	AMPH1.SNGL.2-1024
ac29a80a-c694-4861-a061-3a78cae0ccf9	AMPH1.ACT_STNDB.2-1024
1d25f453-41e8-48bb-9fc6-ffa235f03444	AMPH1.ACT_STNDB.4-2048

ru-7

ID	Имя
78dbe17b-0358-47db-a933-7f06e58307e4	AMPH1.SNGL.2-1024
b93feeb9-6522-4dfa-9e08-38d03ac2448f	AMPH1.ACT_STNDB.2-1024
226d5473-2aa6-42da-b74e-529c6da7a12f	AMPH1.ACT_STNDB.4-2048

gis-1

ID	Имя
07ef9ddf-aac9-4d9a-9c9d-42a6997568a7	AMPH1.SNGL.2-1024
fe77536d-9266-49fd-a207-ef50ab716c64	AMPH1.ACT_STNDB.2-1024
01342570-05e9-46fa-9456-666c360ff166	AMPH1.ACT_STNDB.4-2048

Новосибирск

ru-8

ID	Имя
15be309a-62c8-4b1c-8896-345d5eb21b00	AMPH1.SNGL.2-1024
c979a0d1-5558-4820-aed1-9990b66648f9	AMPH1.ACT_STNDB.2-1024
eed81b82-707b-488c-8142-47a9c1fb71e8	AMPH1.ACT_STNDB.4-2048

Ташкент

uz-1

ID	Имя
7d56905c-92ce-49e8-986e-f656f7b44cda	AMPH1.SNGL.2-1024
ca85e2b6-456e-4118-a2db-0f4aa4f51528	AMPH1.ACT_STNDB.2-1024
5f8741d4-d6c6-438d-bf11-2ab0fbd926c5	AMPH1.ACT_STNDB.4-2048

uz-2

ID	Имя
74cb3ac7-5984-4612-b0f6-e43ee95bb495	AMPH1.SNGL.2-1024
c20efedb-3ae0-4bd7-a80d-6d36f5120efd	AMPH1.ACT_STNDB.2-1024
64dcea94-32e7-4248-aa43-7ac56952c5ba	AMPH1.ACT_STNDB.4-2048

Алматы

kz-1

ID	Имя
a082beed-caca-4722-b4cf-c261781224cf	AMPH1.SNGL.2-1024
abe8a65d-371b-4157-8402-aa39611ebf9a	AMPH1.ACT_STNDB.2-1024
ad73fce9-8d22-40bc-8708-d5ddd7bf4067	AMPH1.ACT_STNDB.4-2048

Найроби

ke-1

ID	Имя
c48873e3-06ef-4aa8-9537-b3050578cfdb	AMPH1.SNGL.2-1024
458d379b-d6c3-4667-baf5-53fe05b33156	AMPH1.ACT_STNDB.2-1024
d95b0f5e-f727-45a0-9dd0-bbd014f64fbe	AMPH1.ACT_STNDB.4-2048

Здесь:

• ID — ID флейвора балансировщика нагрузки;
• Имя — имя флейвора, которое соответствует типу балансировщика нагрузки:
  • AMPH1.SNGL.2-1024 — тип Базовый без резервирования;
  • AMPH1.ACT_STNDB.2-1024 — тип Базовый с резервированием;
  • AMPH1.ACT_STNDB.4-2048 — тип Продвинутый с резервированием.

Посмотреть список флейворов балансировщика нагрузки в определенном пуле⁠

1. Откройте OpenStack CLI.

2. Посмотрите список флейворов:

   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 — окончание действия сертификата.

Стоимость⁠

Балансировщики оплачиваются по модели оплаты облачной платформы.

Стоимость балансировщиков можно посмотреть на selectel.ru.