Перейти к основному содержимому
Балансировщики нагрузки
Последнее изменение:

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

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

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

Трафик распределяется между серверами по правилам — настраивается порт и протокол балансировщика и серверов, алгоритм распределения запросов, проверки доступности и параметры соединений. Количество правил не ограничено.

Как работает балансировщик

В балансировщике нагрузки используется модель OpenStack Octavia, которая включает в себя:

  • Amphorae (амфора) — выполняет балансировку нагрузки. Запускается на облачном сервере и использует HAProxy (High-Availability Proxy) — программное обеспечение для проксирования трафика. В балансировщиках с резервированием (типов Базовый с резервированием и Продвинутый с резервированием) создается две амфоры, без резервирования — одна.
  • Listener (слушатель) — прослушивает поступающий на балансировщик нагрузки поток трафика, используя указанные в правиле порты и протоколы. Затем маршрутизирует трафик к необходимой группе серверов.
  • Pool (пул) — группа серверов, к которой направляет запросы слушатель.
  • Members (серверы) — серверы, которые обслуживают трафик в пуле. Доступны по указанному в правиле IP-адресу и порту.
  • Health Monitor — процесс проверки работоспособности всех серверов внутри пула.

Порты балансировщика

Амфоры балансировщика нагрузки используют несколько портов:

  • Входящий порт (uplink). Это виртуальный порт, на котором размещается VIP — виртуальный IP-адрес. На нем слушатель прослушивает входящий трафик. Выделяется при создании балансировщика нагрузки и находится в его подсети. У балансировщиков с резервированием (типов Базовый с резервированием и Продвинутый с резервированием) VIP резервируется по протоколу VRRP.
  • Служебные VRRP-порты. При создании базового балансировщика нагрузки в его подсети выделяется один служебный порт. При создании балансировщика с резервированием выделяется два служебных порта для основной и резервной амфоры, между ними настраивается VRRP.
  • Служебные порты (downlinks). Если серверы находятся не в подсети балансировщика, то при его создании в подсетях с серверами выделяются порты для амфор: для базового балансировщика один порт, для балансировщиков с резервированием — два порта (основной и резервный).

При неполадках в работе балансировщика нагрузки он автоматически создает новую амфору (и только потом удаляет старую) — для этого нужен свободный порт. Если свободного порта не будет, балансировщик перейдет в статус ERROR.

Если при создании балансировщика нагрузки вы выбрали в качестве подсети балансировщика публичную подсеть и будете размещать в ней серверы, то убедитесь, что в ней есть дополнительный порт, или используйте публичную сеть размером от /28.

Мы рекомендуем выбирать приватную сеть с публичным IP-адресом (адрес нужен для доступа в интернет) — в таком случае для пересоздания амфоры всегда будет доступен свободный порт. Балансировка трафика будет производиться внутри приватной сети.

Типы балансировщиков

Базовый без резервированияБазовый с резервированиемПродвинутый с резервированием
Отказоустойчивость и резервированиеТолько 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)

Вы можете заказать кастомную конфигурацию балансировщика — создайте тикет.

Посмотреть список типов

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

  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 флейвора, зависит от пула. Флейвор — это конфигурация балансировщика нагрузки в терминологии OpenStaсk;
    • name — тип балансировщика нагрузки:
      • AMPH1.SNGL.2-1024 — тип Базовый без резервирования;
      • AMPH1.ACT_STNDB.2-1024 — тип Базовый с резервированием;
      • AMPH1.ACT_STNDB.4-2048 — тип Продвинутый с резервированием.

Правила балансировщика

Правило — это настройки балансировщика, которые обслуживают поток трафика с конкретным портом и протоколом и распределяют этот трафик на нужную группу серверов.

В правиле можно настроить:

Количество правил в балансировщике не ограничено.

Протоколы

Доступны комбинации протоколов:

  • 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-адрес клиента хешируется и делится на вес каждого сервера в правиле — так определяется сервер, который будет обрабатывать запросы.

Проверки доступности

Для балансировщика можно включить проверку доступности. Балансировщик будет отслеживать состояние серверов — если какой-либо сервер окажется неработоспособным, балансировщик перенаправит соединение на другой.

Параметры проверки:

  • тип проверки: HTTP, HTTPS, PING, TCP, TLS-HELLO, UDP-CONNECT;
  • интервал в секундах, с которым балансировщик отправляет проверяющие запросы серверам;
  • таймаут соединения — время ожидания ответа;
  • для протоколов проверки HTTP и HTTPS можно настроить обращение к URL и ожидаемые коды ответа;
  • порог успеха — количество успешных обращений подряд, после которых сервер переводится в рабочее состояние;
  • порог неуспеха — количество неуспешных обращений подряд, после которых работа сервера приостанавливается.

Настройки соединений

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

Настройки соединений:

  • таймаут соединения — время ожидания ответа;
  • количество соединений — ограничено или нет;
  • таймаут неактивности — время, в течение которого подключение считается активным, даже если данные не передаются;
  • таймаут ожидания TCP-пакетов — время, в течение которого балансировщик ждет передачи данных для инспекции по уже установленному соединению.

Заголовки HTTP-запросов

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

Включите необходимые типы дополнительных заголовков в запрос, чтобы серверы получали эту информацию для корректной работы или анализа:

  • X-Forwarded-For,
  • 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,
  • X-SSL-Client-Not-Before,
  • X-SSL-Client-Not-After.

Стоимость

Стоимость балансировщика нагрузки указана на selectel.ru.

Средства списываются с баланса Облачной платформы каждый час — подробнее о модели оплаты облачной платформы.