Что такое балансировщик нагрузки: как распределяются запросы и что происходит при отказе

Один адрес сайта — несколько серверов за ним

Представим корпоративный портал. Сотрудник вводит адрес, а балансировщик передаёт запрос одному из двух веб-узлов. Следующий запрос может получить другой узел, если это допускают настройки и архитектура приложения. Ответ возвращается сотруднику по предусмотренному сетевому пути; в распространённой прокси-схеме — через балансировщик.

Это возможности правильно построенной системы, а не обещание нулевого простоя. Незавершённый запрос на отказавшем узле может оборваться, а оставшимся серверам понадобится достаточная производительность.

Четыре понятия: вход, пул, узел и проверка

• Listener / frontend: адрес, порт и правила приёма обращений. Например, HTTPS на порту 443.
• Pool / backend: группа серверов, которым можно передать нужный трафик. Название backend может обозначать и всю группу, и серверную часть — смотрите терминологию продукта.
• Участник пула: конкретный адрес и порт приложения. Два процесса на одной ВМ — два получателя, но одна общая зависимость от этой ВМ.
• Health check: проверка, которая помогает решить, готов ли получатель принимать обращения.

Балансировщик бывает программой на Linux или ВМ, аппаратным устройством либо управляемой облачной услугой. Отдельная дорогая коробка для самого принципа не обязательна. Реалистичные изображения в статье показывают условное оборудование, а не стенд с измеренной производительностью.

L4 и L7: соединение или содержимое запроса

Это не рейтинг «L7 всегда лучше». Нужны подходящие протоколы, пропускная способность и функции. Для анализа HTTP внутри HTTPS трафик должен быть расшифрован в соответствующей точке. Поддержку UDP, HTTP/2, HTTP/3, gRPC и WebSocket уточняют для конкретного продукта и режима.

Выбор влияет на диагностику: при L4 смотрят соединения и сетевые ошибки; при L7 дополнительно видны HTTP-коды, маршруты и прикладные времена. Понятия listener и pool встречаются, например, в документации облачного балансировщика Selectel.

Как выбирается сервер: по очереди, по весу или по соединениям

• Round robin: обращения распределяются по очереди между доступными участниками с учётом реализации и настроек. Это удобная исходная модель для похожих узлов.
• Веса: более производительному узлу задают большую долю. Отношение 2:1 описывает целевое распределение выбранных обращений, а не гарантию одинаковой загрузки процессоров.
• Least connections: учитывается число активных соединений. Полезно при неодинаковой длительности работы, но число соединений не равно загрузке CPU или сложности запросов.
• Хеширование: получатель выбирается по определённому ключу, например адресу клиента. Добавление и удаление узлов может менять соответствия; детали зависят от алгоритма.

Алгоритмы и ограничения описаны у NGINX и в руководстве HAProxy по backend. Из названия least connections нельзя делать вывод, что продукт автоматически измеряет свободную память, быстродействие дисков и очередь СУБД.

Health checks: открытый порт ещё не означает работающее приложение

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

Активные проверки выполняются отдельно с заданным интервалом; пассивные используют наблюдаемые ошибки рабочего трафика. Доступность функций зависит от продукта и редакции. Так, в руководстве NGINX разграничиваются пассивные проверки и встроенные активные HTTP-проверки NGINX Plus.

• Определите смысл готовности: процесс жив, готов принимать запросы или способен выполнить нужную функцию.
• Согласуйте URL, метод, Host и ожидаемый статус; редирект на страницу входа не должен случайно считаться успешной проверкой нужной функции.
• Задайте интервалы, таймауты и пороги отключения/возврата; слишком чувствительная проверка создаёт постоянные переключения.
• Не выполняйте в каждой частой пробе тяжёлый отчёт и не публикуйте в ответе пароли, строки подключения или внутренние подробности.

В документации HAProxy показаны проверки разных уровней. Собственная страница readiness должна соответствовать вашему приложению: универсального URL /health для всех программ нет.

Узел отказал: что переключится, а что может оборваться

После обнаружения отказа балансировщик исключает получателя из обычного выбора. Новые подходящие обращения идут оставшимся. Между фактическим отказом и его обнаружением проходит время; часть пользователей может успеть получить ошибку.

Уже открытые соединения и работающая на отказавшем узле операция не «переезжают» автоматически. Повторная отправка зависит от протокола, клиента, приложения и настроек. Особенно опасно бездумно повторять изменение данных: неизвестно, успел ли сервер провести платёж или документ до обрыва ответа.

Изображение ниже — иллюстрация узлов, а не подтверждение переключения. Результат проверяют по запросам, журналам, состоянию пула и бизнес-операциям.

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

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

HAProxy описывает привязку по cookie и IP. Общий внешний адрес офиса способен «собрать» множество сотрудников на одном узле при IP-привязке. Поэтому выбор ключа влияет и на равномерность, и на поведение при изменении адреса.

Две копии сайта — это ещё не две копии базы

• База данных: кластеризация, репликация и выбор пишущего узла проектируются средствами СУБД и приложения.
• Загруженные файлы: нужны согласованные доступы и модель хранения. Файл на локальном диске первого веб-узла не возникает на втором.
• Фоновые задания: две одинаковые копии могут дважды отправить уведомление или выполнить регламентную работу. Нужны предусмотренные механизмы координации.
• Кэш и сессии: уточняют, что допускает локальное хранение, что должно быть общим и как переживается потеря узла.

Для 1С, корпоративной почты или портала схема зависит от поддерживаемой архитектуры конкретного продукта. Нельзя поставить два произвольных сервера за TCP-прокси и объявить их кластером. Особенно нельзя распределять запись в независимые базы без предусмотренной модели согласованности.

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

HTTPS: где заканчивается шифрование

Шифрование браузер → балансировщик не доказывает шифрование балансировщик → приложение. Для второго участка проверяют сертификат, доверие, имя сервера и правила обновления. Руководство HAProxy разделяет эти подключения.

После завершения TLS приложение должно правильно понимать исходную схему HTTPS и адрес клиента. Прокси-заголовкам доверяют только от назначенных посредников: внешний клиент способен прислать поддельный заголовок. Настройка касается журналов, ограничений по IP и формирования ссылок. PROXY protocol требует поддержки обеих сторон и не взаимозаменяем с HTTP-заголовком.

А если сломается сам балансировщик?

Один балансировщик перед двумя серверами остаётся общей точкой отказа. Для входного уровня тоже нужна предусмотренная архитектура: резерв экземпляров, переключение адреса либо управляемая услуга с подходящими условиями.

• Проверьте общие зависимости: физический хост, коммутатор, канал, питание и зону размещения.
• Согласуйте механизм выбора активного входа и защиту от конфликтующих состояний. Плавающий IP нельзя произвольно переносить между любыми сетями.
• Учитывайте синхронизацию конфигурации, сертификатов и необходимого состояния. Перенос адреса сам по себе не переносит активные TCP-соединения.
• Проверяйте отказ входа отдельно от отказа backend и отказа базы данных.

В облаке надо изучить именно выбранный вариант услуги: одиночный экземпляр и отказоустойчивая конфигурация могут иметь разные свойства. Вторая ВМ в том же общем домене отказа не обязательно даёт нужный результат.

Как обновить узел без грубого обрыва пользователей

1. Убедитесь, что другие узлы готовы принять нагрузку и совместимы с текущей версией приложения.
2. Ограничьте поступление новых обращений на обслуживаемый узел предусмотренным способом.
3. Проверьте активные соединения и сессии. Для долгих подключений задайте согласованный срок ожидания и порядок завершения.
4. Выполните обновление, локальную проверку и контроль готовности.
5. Верните узел в пул с наблюдением за ошибками, задержками и прикладными операциями.

Режим drain имеет конкретную семантику в продукте. Например, сохранённая привязка клиента может влиять на направление обращений даже после ограничения обычной балансировки. Не считайте нажатие одной кнопки гарантией отсутствия новых сессий: изучите состояния ready, drain и maintenance в HAProxy.

Обновления должны учитывать совместимость схемы базы и состояния. Две версии программы не всегда могут безопасно работать одновременно; порядок возврата определяют до начала работ.

Балансировщик, обратный прокси, DNS и защита — где разница

• Обратный прокси принимает обращения к серверной части и пересылает их дальше. Он может иметь одного получателя; балансировка добавляет выбор между участниками. Роли могут совмещаться в одной программе.
• DNS round robin возвращает адреса в DNS. Дальше влияют кэширование и поведение клиента; это не тот же контроль каждого обращения, что у HTTP-прокси.
• WAF анализирует прикладные атаки по своим правилам. Наличие балансировки не означает наличие WAF.
• Защита от DDoS требует подходящей ёмкости и фильтрации. Если входной канал уже забит, добавление backend не освободит его.

Маршрутизация по URL, фильтрация, кэширование и балансировка — разные функции. Уточняйте их состав и редакцию продукта. Базовая роль посредника описана в руководстве NGINX Reverse Proxy.

Какие решения бывают и как выбирать

Встречаются и специализированные аппаратные/виртуальные ADC, например семейства F5 BIG-IP. Само имя продукта не гарантирует нужную функцию в любой лицензии. Перед выбором собирают требования: протоколы, TLS, тип проверок, привязка, журналирование, автоматизация, лимиты, схема отказа и поддержка.

Сравнивайте полный эксплуатационный состав: ресурсы и труд сопровождения для собственного решения; лимиты, трафик, поддержку и модель отказоустойчивости для услуги. Бесплатная лицензия не делает обслуживание бесплатным, а платная услуга не заменяет проектирование приложения.

Как оценить нужную производительность

Начните с профиля: сколько одновременных пользователей, обращений в секунду, долгих соединений, загрузок файлов и TLS-подключений. Для одного сервиса критичны новые соединения, для другого — полоса сети, для третьего — тяжёлые ответы базы. Цифра «до миллиона запросов» без условий не позволяет выбрать конфигурацию.

Значения здесь вымышлены. Проверяют не только сумму: после отказа возрастает нагрузка на сеть, CPU и отдельные соединения с базой. Установленные лимиты и очередь способны изменить результат. Сравнивайте p95/p99 и долю ошибок при одинаковых запросах, данных и времени теста, затем повторите сценарий с выведенным узлом.

Резервируют и балансировщик: он обслуживает соединения, TLS, журналы и проверки. Его ресурсы, ограничения облачной услуги и доступность внешнего канала могут стать общим пределом даже при свободных backend.

Три ситуации из практики проектирования

Что мониторить и сохранять для расследования

• Трафик и очереди: обращения, активные соединения, отказы при приёме, ожидание свободного получателя.
• Задержки: отдельно подключение к backend и ответ приложения, если продукт это измеряет; p95/p99 вместе со средним.
• Ошибки: источник 4xx/5xx, таймауты, сбросы, изменения состояния участников.
• Ресурсы: CPU, память, сеть и лимиты соединений балансировщика и серверов.
• История: время изменения конфигурации, версии, сертификаты, действия оператора и события проверок.

Для расследования связывают события по времени и идентификатору запроса: когда начались жалобы, какой узел отвечал, что меняли и были ли ошибки у СУБД. Время на узлах должно быть согласовано. Не записывайте в журналы секреты, полные токены и чувствительные тела запросов без необходимости.

Один зелёный индикатор пула не заменяет проверку реальной операции пользователя. Важен путь снаружи через штатный адрес, а не только локальный ответ каждого сервера.

Как проверить результат: от HTTP до бизнес-операции

Сначала согласуйте тестовый контур, домен, ожидаемый ответ и безопасный сценарий. Ниже команды для Linux с установленным curl. portal.example.test и 192.0.2.20 — документальные подстановки; замените их адресами своего согласованного контура. Наличие /health заранее не предполагается.

1. Посмотреть заголовки ответа

curl --connect-timeout 3 --max-time 10 --silent --show-error --dump-header - --output /dev/null https://portal.example.test/

--connect-timeout ограничивает этап соединения, --max-time — всю операцию. --dump-header - выводит заголовки, --output /dev/null убирает тело. Смотрите код и ожидаемый редирект. Команда не доказывает распределение между узлами и не обходит проверку сертификата.

2. Проверить новый вход до изменения DNS

curl --resolve portal.example.test:443:192.0.2.20 --connect-timeout 3 --max-time 10 --silent --show-error --dump-header - --output /dev/null https://portal.example.test/

--resolve подставляет адрес для этой пары имени и порта, сохраняя имя в URL для HTTPS. Это позволяет проверить выбранный вход до общего переключения DNS. Нужен подходящий сертификат и доверие к нему; добавлять -k вместо исправления доверия не следует.

3. Зафиксировать время и HTTP-код одного обращения

curl --connect-timeout 3 --max-time 10 --silent --show-error --output /dev/null --write-out 'code=%{http_code} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' https://portal.example.test/

Получите код и времена в секундах. time_starttransfer включает предшествующие этапы обращения, а не только работу СУБД. Это одиночное измерение, не нагрузочный тест и не Apdex. Параметры описаны в руководстве curl.

1. Проверьте каждый узел и общий вход, затем подтвердите распределение по защищённым журналам или тестовым идентификаторам.
2. В тестовом контуре выведите один участник из работы согласованным способом и измерьте обнаружение отказа, ошибки и поведение оставшихся.
3. Проверьте вход пользователя, состояние сеанса, чтение/запись и долгую операцию; не повторяйте неидемпотентные операции без контроля.
4. Отдельно испытайте отказ входа, восстановление узла и возврат после обслуживания.

При подготовке статьи реального переключения приложения не выполнялось; команды показывают метод проверки, а не готовый протокол испытания вашей системы.

Две карточки для проекта и приёмки

Поможем распределить нагрузку и организовать сопровождение

Вопросы и ответы