Методы балансировки

Какие методы используем, как они работают, как настроен healthcheck, как настроить балансировку для вашего ресурса.

Сравнение доступных методов балансировки

Балансировка — это распределение трафика между серверами. Нужна, когда у вас больше одного источника, чтобы нагрузка делилась равномерно и серверы не перегружались.

Можем настроить метод round robin, sticky session или IP-hash. По умолчанию работает round robin.

	Round robin	Sticky session	IP-hash
Особенность балансировки	Каждый запрос распределяется отдельно	Все запросы в рамках одной сессии будут попадать на один и тот же сервер	Все запросы с одного IP будут попадать на один и тот же сервер
Механизм	Запросы распределяются по очереди пропорционально весам серверов: больше вес — больше запросов получает сервер	Сначала round robin выбирает, на какой сервер направить первый запрос клиента. Затем все остальные запросы клиента в текущей сессии отправляются на тот же сервер.	Балансировщик берёт IP клиента, прогоняет его через хэш-функцию и вычисляет результат. Получившееся число — это номер сервера, на который будут уходить запросы с этого IP.
Плюсы	Нагрузка распределена между серверами ровно так, как вы настроили	Лучше пользовательский опыт: во время сессии состояние сохраняется — например, собранная в интернет-магазине корзина не «слетит», потому что пользователь остаётся подключен к одному и тому же серверу (который хранит данные о добавленных товарах)	Снижена нагрузка на переключения: клиент стабильно попадает на один и тот же сервер, пока у него не меняется IP
Минусы	Нет «памяти» о клиентах: в рамках одной сессии запросы могут уходить на разные серверы. Если приложение не хранит данные централизованно, пользовательский опыт может пострадать: «слетевшие» корзины, выход из аккаунтов и т.д.	Если слишком много клиентов закрепилось за одним сервером, он может перегрузиться	При смене IP (наприме, если включить VPN) клиент может попасть на другой сервер. Сессия обрывается, пользователь может потерять несохранённые данные или выйти из аккаунта.
Пассивный healthcheck	✅	✅	✅
Можно ли подключить активный healthcheck	✅	❌	❌
Как подключить и настроить	Работает по умолчанию Источники и веса вы можете настроить в личном кабинете	Подключается по запросу в техподдержку После подключения источники настраиваются через поддержку, а не в личном кабинете	Подключается по запросу в техподдержку Источники и веса вы можете настроить в личном кабинете

Round robin

Sticky session

IP-hash

Особенность балансировки

Каждый запрос распределяется отдельно

Все запросы в рамках одной сессии будут попадать на один и тот же сервер

Все запросы с одного IP будут попадать на один и тот же сервер

Механизм

Запросы распределяются по очереди пропорционально весам серверов: больше вес — больше запросов получает сервер

Сначала round robin выбирает, на какой сервер направить первый запрос клиента. Затем все остальные запросы клиента в текущей сессии отправляются на тот же сервер.

Балансировщик берёт IP клиента, прогоняет его через хэш-функцию и вычисляет результат. Получившееся число — это номер сервера, на который будут уходить запросы с этого IP.

Плюсы

Нагрузка распределена между серверами ровно так, как вы настроили

Лучше пользовательский опыт: во время сессии состояние сохраняется — например, собранная в интернет-магазине корзина не «слетит», потому что пользователь остаётся подключен к одному и тому же серверу (который хранит данные о добавленных товарах)

Снижена нагрузка на переключения: клиент стабильно попадает на один и тот же сервер, пока у него не меняется IP

Минусы

Нет «памяти» о клиентах: в рамках одной сессии запросы могут уходить на разные серверы. Если приложение не хранит данные централизованно, пользовательский опыт может пострадать: «слетевшие» корзины, выход из аккаунтов и т.д.

Если слишком много клиентов закрепилось за одним сервером, он может перегрузиться

При смене IP (наприме, если включить VPN) клиент может попасть на другой сервер. Сессия обрывается, пользователь может потерять несохранённые данные или выйти из аккаунта.

Пассивный healthcheck

✅

Можно ли подключить активный healthcheck

✅

❌

Как подключить и настроить

Работает по умолчанию

Источники и веса вы можете настроить в личном кабинете

Подключается по запросу в техподдержку

После подключения источники настраиваются через поддержку, а не в личном кабинете

Подключается по запросу в техподдержку

Источники и веса вы можете настроить в личном кабинете

Round robin

Как работает

Запросы распределяются по серверам по очереди пропорционально их весам. Вес — цифра, которую вы указываете сами при добавлении источника. Чем больше вес, тем больше запросов сервер получит. А если все веса одинаковые, запросы поделятся поровну.

Вес ≠ количество запросов. Если у двух серверов веса 5 и 10, это не значит, что второй будет простаивать, пока первый не примет 5 запросов. Балансировщик распределит трафик равномерно с учётом весов: так как 5 в два раза меньше 10, то и запросы будут уходить в соотношении 1 к 2: один запрос первому, два второму, затем снова один первому, два второму и так далее.

Каждый сервер имеет роль: primary или backup. По умолчанию трафик направляется только на primary. Backup включается, если все primary недоступны.

Пример

У вас три сервера: A, B и C. Вот как распределятся первые восемь запросов при разных настройках:

Настройка	Распределение запросов
A: primary, вес 1 B: primary, вес 1 C: primary, вес 1	A→B→C→A→B→C→A→B
A: primary, вес 1 B: primary, вес 3 C: primary, вес 4	A→B→C→B→C→B→C→C
A: primary, вес 1 B: primary, вес 2 C: backup, вес 1	Когда A и B работают: A→B→B→A→B→B→A→B Когда A недоступен: B→B→B→B→B→B→B→B Когда A и B недоступны: C→C→C→C→C→C→C→C

Настройка

Распределение запросов

A: primary, вес 1

B: primary, вес 1

C: primary, вес 1

A→B→C→A→B→C→A→B

A: primary, вес 1

B: primary, вес 3

C: primary, вес 4

A→B→C→B→C→B→C→C

A: primary, вес 1

B: primary, вес 2

C: backup, вес 1

Когда A и B работают:

A→B→B→A→B→B→A→B

Когда A недоступен:

B→B→B→B→B→B→B→B

Когда A и B недоступны:

C→C→C→C→C→C→C→C

Как система понимает, доступен ли сервер

Работает пассивный healthcheck: если ваш сервер возвращает 50 ошибок вида 50x подряд, то считается недоступным и выводится из балансировки на 3 секунды. После 3 секунд снова начинает получать запросы.

Для round robin можем включить активный healthcheck — напишите в техподдержку cybert@servicepipe.ru, мы всё настроим.

Как подключить и настроить

Round robin не нужно включать вручную, он работает по умолчанию. Вы можете менять веса для серверов-источников в личном кабинете.

IP-hash

Как работает

Коротко: система выбирает, какому серверу передать запрос, на основании цифр IP-адреса клиента. Запросы с одного IP будут уходить одному и тому же серверу. Если он «упадёт», запросы на время будут переданы другим.

Подробно: при отправке запроса система берёт IP-адрес клиента и обрабатывает его функцией хэширования — то есть прогоняет через сложную формулу, содержащую вычисления и перестановки значений, и в результате получает ответ в виде числа. Это число делится на количество доступных серверов с учётом их весов — остаток от деления означает номер сервера, которому уйдёт запрос.

Пример

У вас три сервера-источника:
- A, вес 1
- B, вес 2
- C, вес 3
  
  Каждый получает свой порядковый номер, нумерация начинается с нуля. Если веса отличаются, то за серверами с бо́льшим весом будет закреплено сразу несколько номеров — чтобы они получали больше запросов. В нашем примере номера такие:
- 0 – A
- 1 – B
- 2 – B
- 3 – C
- 4 – C
- 5 – C
Два клиента отправляют запросы:
- Первый с IP 85.249.32.114
- Второй с IP 91.108.56.203
Система обрабатывает IP функцией хэширования. Для примера представим, что наша функция — сложение всех чисел в IP-адресе (в реальности хэш-функции намного сложнее):
- Для первого клиента: 85+249+32+114=480
- Для второго клиента: 91+108+56+203=458
Система находит остаток от деления получившихся чисел на количество порядковых номеров (у нас номера от 0 до 5, всего 6 номеров).
- Для первого клиента: 480/6=48. Числа делятся без остатка, остаток равен 0.
- Для второго клиента: 458/6=76.3. Остаток от деления равен 458-76*6=2.
Система сопоставляет остатки от деления с порядковыми номерами серверов.
- Запрос от первого клиента (остаток 0) уходит на сервер A (его номер 0)
- Запрос от второго клиента (остаток 2) уходит на сервер B (его номер 2).
Запросы от первого клиента всегда уходят на сервер A, а от второго — на сервер B.
Если сервер A недоступен, запросы первого клиента уйдут на другой работающий — B либо C. Когда A восстановится, первый клиент снова будет взаимодействовать только с ним.

Клиент с одним IP всегда попадает на один и тот же сервер. Если IP изменится (например, пользователь включил VPN), формула может выдать другое число, и новый запрос уйдёт на другой сервер.

Как система понимает, доступен ли сервер

Работает пассивный healthcheck: если ваш сервер возвращает 50 ошибок вида 50x подряд, то выводится из балансировки на 3 секунды. После 3 секунд возвращается в балансировку и снова начинает получать запросы.

Как подключить и настроить

Напишите персональному менеджеру или в техническую поддержку (имейл cybert@servicepipe.ru) – мы настроим IP-hash-балансировку для вашего ресурса.

Важно: IP-hash не поддерживает деление источников на primary и backup. Все серверы участвуют в балансировке как primary.

Sticky session

Как работает

Первые запросы клиентов распределяются по round robin. Затем система «приклеивает» клиента к серверу на время сессии — куда ушёл первый запрос, туда уйдут остальные, пока сессия не завершится. Даже если у клиента изменится IP-адрес, запросы всё равно будут идти к тому же серверу.

Другими словами, sticky session — это распределение сессий клиентов между серверами по round robin.

Пример

У вас три сервера-источника: A, B и C.
Клиент открывает сессию, и первый запрос попадает на сервер B (выбор сделан по round robin с учётом весов). Все следующие запросы этого клиента в рамках одной сессии уходят только на сервер B.
Клиент закрывает сессию.
Клиент открывает новую сессию. Round robin направляет его первый запрос на сервер A. Остальные запросы в рамках сессии тоже попадут на сервер А.
Если у клиента открыта сессия с A и тот неожиданно упал, то клиента перебросит на работающий сервер, выбранный по round robin — например, на C. С этого момента все запросы будут уходить на C, пока сессия не закрыта.

Как система понимает, доступен ли сервер

Работает пассивный healthcheck: если ваш сервер возвращает 50 ошибок вида 50x подряд, то выводится из балансировки на 3 секунды. Клиенты с активными сессиями на таком сервере будут автоматически переброшены на доступный сервер.

Как подключить и настроить

Напишите персональному менеджеру или в техническую поддержку support@servicepipe.ru — мы настроим sticky session-балансировку для вашего ресурса.

Важно:

Sticky session доступна для всех конфигураций защиты, кроме TCP-stream. Конфигурация TCP-stream — это когда вы не раскрываете SSL/TLS-сертификат, а мы очищаем трафик на L3-L4 и проксируем корректные TCP-сессии на ваши серверы.
После включения sticky session вы не сможете добавлять и удалять источники через личный кабинет — но это можно будет сделать через техподдержку. Напишите нам, мы всё настроим.

Healthcheck

Что такое healthcheck

Healthcheck — это автопроверка, какие из ваших серверов сейчас работают. Если часть «упала», с помощью healthcheck мы узнаем об этом и будем направлять запросы пользователей только на работающие серверы.

Разница: пассивный и активный healthcheck

Пассивный healthcheck работает по умолчанию. Он опирается на реальные ответы пользователям: если сервер возвращает 50 ошибок 5xx подряд, то исключается из балансировки на 3 секунды. Недостаток — часть запросов всё же уйдёт на недоступный сервер, что приведёт к задержкам.

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

Как работает активный healthcheck

Поддерживаем три варианта проверки:

HTTP — система отправляет HTTP-запросы на сервер и проверяет, есть ли корректный ответ
TCP — система проверяет возможность установить соединение без передачи данных
SSL Hello — система проверяет, может ли сервер завершить SSL Handshake

Если сервер не отвечает или возвращает ошибку, он временно исключается из балансировки. Когда снова проходит проверки, возвращается в пул.

Мы настроим параметры под ваши пожелания:

Сколько неудачных проверок допускается, чтобы исключить сервер
Сколько успешных проверок нужно, чтобы вернуть сервер в балансировку
Таймаут ожидания ответа

Пример

У вас три сервера-источника: A, B и C.

Настроено: HTTP-запросы, исключать сервер после 2 неудачных проверок и возвращать после 3 успешных. Интервал проверок — 10 секунд.

12:00:00 — система отправляет запросы. Сервер B не отвечает.
12:00:10 — повторная проверка. Сервер B снова не отвечает, он исключается из балансировки. Трафик распределяется только между A и C.
12:00:10-12:29:50 — сервер B не ответил ни на одну проверку, трафик распределяется между A и C.
12:30:00 — сервер B снова отвечает. Система фиксирует первый успешный ответ.
12:30:10 — второй успешный ответ.
12:30:20 — третий успешный ответ. Сервер B возвращается в пул, трафик распределяется между A, B и C.

Как настроить

Активный healthcheck доступен только для балансировки round robin. Чтобы включить его, напишите персональному менеджеру или в техническую поддержку cybert@servicepipe.ru — мы всё настроим.