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

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

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

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

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

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

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

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

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

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

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

Протоколы

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

  • TCP–TCP — классическая L4-балансировка;
  • TCP–PROXY — информация о клиенте не теряется и передается в отдельном заголовке соединения;
  • UDP–UDP — UDP-протокол быстрее, чем TCP, но менее надежен;
  • HTTP–HTTP — L7-балансировка;
  • HTTPS–HTTP — L7-балансировка с шифрованием и терминацией SSL-сертификата на балансировщике.

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

Тип Отказоустойчивость и
резервирование		 Для чего подойдет Пропускная способность Количество HTTP-запросов Количество HTTPS-запросов
Базовый с резервированием Да, аварийное переключение (Active-Standby Failover) на резервную амфору в одном пуле Для небольших и средних проектов, для которых критична доступность сервиса Максимум 5 Гбит/с ~19500 ~3000 keep-alive подключений
Базовый без резервирования Нет, только Single режим Для тестовых окружений или проектов, для которых не нужна доступность сервиса 24 / 7 Максимум 5 Гбит/с ~19500 ~3000 keep-alive подключений
Продвинутый с резервированием Да, аварийное переключение (Active-Standby Failover) на резервную амфору в одном пуле Для проектов с высокой нагрузкой и требованием к постоянной доступности сервиса Максимум 5 Гбит/с ~34000 ~9000 keep-alive подключений

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

Алгоритмы распределения запросов

Listener распределяет запросы по выбранному алгоритму. Доступно два алгоритма:

  • 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.

Стоимость

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

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