Когда мы говорим балансировщик нагрузки, обычно имеем в виду устройство для распределения трафика между серверами, чтобы избежать их перегрузки. Но в реальной инфраструктуре не менее важна и другая задача — обеспечение отказоустойчивости.
В этой статье, опираясь на наш практический опыт внедрений и эксплуатации, разберём, как с помощью балансировщика выстраивается отказоустойчивая инфраструктура — от проверки состояния отдельных серверов до геораспределённых сценариев.
Отказоустойчивость на уровне группы серверов
Начнём с самого простого сценария — когда заказчик предоставляет только один сервис. Чтобы справляться с нагрузкой, сервис разворачивается на нескольких серверах, и здесь появляется необходимость в балансировщике, который распределяет входящий трафик между ними.
Однако просто направить запрос на любой из серверов недостаточно. Перед этим балансировщик должен убедиться, что конкретный сервер действительно готов его обработать. Причём важно не только то, что сервер «доступен» по сети, но и то, что сам сервис на нём работает корректно.
Для этого используются health checks — проверки состояния узлов, которые могут выполняться на разных уровнях модели OSI.
На уровне L3 проверяется базовая сетевая доступность: балансировщик отправляет ICMP-запрос (ping) и по ответу понимает, достижим ли сервер.
На уровне L4 проверяется транспортная доступность — например, возможность установить TCP-соединение на нужный порт. Это позволяет выявить ситуации, когда сервер работает, но сервисный порт недоступен или не принимает соединения.
На уровне L7 проверяется уже сам сервис. Например, для веб-приложений балансировщик может выполнить HTTP(S) GET-запрос и проанализировать код ответа. Это позволяет обнаружить ситуации, когда сеть и порт доступны, но приложение работает некорректно.
Важно, что эти уровни дополняют друг друга. Сервер может успешно отвечать на ping (L3) и принимать TCP-соединения (L4), но при этом само приложение уже не обрабатывает запросы. Именно такие «скрытые» сбои чаще всего и приводят к деградации сервиса, если ограничиться проверками только на одном из уровней.
Дополнительно в реальных сценариях часто требуется более гибкая логика принятия решения о доступности. Для этого отдельные проверки могут объединяться между собой с помощью логических операций — «И», «ИЛИ», «НЕ». Такой подход позволяет точнее учитывать реальные условия работы сервиса и избегать как ложных срабатываний, так и ситуаций, когда проблемный узел продолжает получать трафик.
Балансировщик постоянно отслеживает состояние всех серверов в группе и автоматически исключает из работы те, которые не проходят проверки. При восстановлении узла он так же автоматически возвращается в пул.
Таким образом, уже на уровне одной группы серверов закладывается базовый слой отказоустойчивости, без которого невозможно обеспечить стабильную работу сервиса в целом.
Отказоустойчивость на уровне сервисов
В инфраструктуре более крупных заказчиков одновременно работают десятки сервисов. Балансировщик выступает здесь как точка принятия решений на уровне сервиса: он непрерывно отслеживает состояние всех узлов внутри группы и оценивает её работоспособность по заданным критериям. Например, если количество доступных серверов в группе становится меньше порогового значения N, такая группа может считаться деградировавшей или полностью недоступной. Важно, что в таких сценариях отдельные серверы могут продолжать работать, но сервис в целом уже не способен обрабатывать необходимый объём трафика.
Причины деградации сервиса в пределах одного ЦОД могут быть разными: от проблем с сетью и электропитанием до ошибок конфигурации. Балансировщик должен своевременно зафиксировать деградацию и изменить поведение — например, переключить трафик на резервную группу в этом же ЦОД.
Отдельный практический аспект — масштаб мониторинга. В реальных инфраструктурах балансировщик может одновременно отслеживать десятки сервисов и сотни серверов, и от эффективности системы мониторинга напрямую зависит скорость реакции на сбои.
Отказоустойчивость на уровне ЦОД
На уровне крупных инфраструктур следующий шаг — обеспечение отказоустойчивости уже не внутри одного дата-центра, а между несколькими площадками.
Для этого используются геораспределённые схемы с резервным ЦОД, который способен взять на себя обработку трафика в случае сбоя. В зависимости от требований это может быть как «холодный» резерв, так и полностью активный дата-центр, работающий параллельно с основным.
Задача балансировщика на этом уровне — определить, что сервис в основном ЦОД больше не способен обслуживать запросы, и своевременно перенаправить трафик в резервный. На практике мы сталкивались со сценариями, где один и тот же сервис одновременно резервировался в трёх независимых ЦОД. В критической инфраструктуре это позволяет минимизировать риски даже при отказе нескольких площадок одновременно.
Таким образом, балансировщик на этом уровне становится инструментом управления доступностью уже не отдельных сервисов, а всей распределённой инфраструктуры.
Роль автоматизации в отказоустойчивости
Как мы видим, сценарии отказоустойчивости могут быть достаточно сложными. Балансировщик должен не просто фиксировать сбои, а в реальном времени менять сценарий распределения трафика в зависимости от текущего состояния инфраструктуры. Именно здесь ключевую роль играет автоматизация.
Рассмотрим, как это работает на примере геораспределённой схемы с двумя ЦОД.
Каждый сервис развернут и работает в обоих ЦОД (основном и резервном), то есть полностью зарезервирован. Для него используется одинаковый IP-префикс, который анонсируется во внешнюю сеть (интернет) через граничный маршрутизатор.
В штатном режиме для основного ЦОД задан более высокий приоритет, поэтому основной объём трафика из интернета направляется именно туда, а резервный ЦОД используется как запасной путь.
Теперь предположим, что в основном ЦОД сервис 1 становится недоступен. В этом случае балансировщик фиксирует проблему и инициирует изменение маршрутизации — механизм, известный как route health injection. По сути, он сообщает маршрутизатору, что сервис 1 в основном ЦОД больше недоступен.
После этого маршрутизатор пересчитывает приоритеты маршрутов: путь через основной ЦОД перестаёт быть приоритетным, и весь трафик сервиса 1 автоматически направляется в резервный ЦОД.
Отказоустойчивость самого балансировщика
При всей важности отказоустойчивости на уровне серверов, сервисов и ЦОД, нельзя забывать и о самом балансировщике. Если он становится единой точкой отказа, все описанное выше теряет смысл.
Поэтому на практике балансировщики разворачиваются в паре — с возможностью автоматического переключения при сбое. В зависимости от схемы подключения это может быть L3-вариант с использованием VRRP или L2-сценарий с применением MC-LAG. В обоих случаях задача одна — обеспечить быстрое и прозрачное переключение трафика на резервный узел. При этом виртуальный IP-адрес сервиса (VIP), на который приходит клиентский трафик, переносится на резервный балансировщик, и для внешних систем это переключение остаётся незаметным.
Ключевой момент здесь — не только само переключение, но и сохранение уже установленных соединений. Для этого балансировщики в паре синхронизируют состояние сессий между собой. В результате при отказе активного узла и переходе на резервный пользователи не сталкиваются с обрывами соединений, а сервис продолжает работать без заметных прерываний.
Отдельное внимание стоит уделить сетевой связности балансировщиков с остальной инфраструктурой. Как и в других частях сети, здесь используются протоколы динамической маршрутизации — такие как BGP или OSPF. Однако их стандартное время сходимости может быть недостаточным для сценариев, где критична минимальная задержка при отказе.
В таких случаях применяется BFD (Bidirectional Forwarding Detection) — механизм, позволяющий значительно быстрее обнаруживать потерю связности между устройствами. Он работает в связке с BGP и OSPF, ускоряя реакцию на сбои и обеспечивая более быстрое переключение трафика.
Таким образом, отказоустойчивость самого балансировщика — это сочетание резервирования на уровне устройств, синхронизации состояния сессий и быстрого обнаружения сетевых проблем. Без этого даже самая продуманная схема балансировки не сможет обеспечить требуемый уровень доступности сервисов.
Вместо заключения
Обеспечение отказоустойчивости в реальной инфраструктуре — это цепочка взаимосвязанных механизмов: от проверки состояния отдельных серверов до переключения между ЦОД. И на каждом из этих уровней балансировщик выступает как точка принятия решений — куда направить трафик, если что-то пошло не так.
Поэтому при выборе балансировщика важно смотреть не только на поддерживаемые алгоритмы распределения трафика, но и на то, насколько полно он покрывает задачи обеспечения отказоустойчивости на всех уровнях инфраструктуры.
Если перед вами стоит задача построения отказоустойчивой инфраструктуры, в которой может помочь балансировщик нагрузки — будем рады обсудить её в нашем Telegram-канале.
А если вы встречались с другими случаями применения балансировщиков для обеспечения отказоустойчивости — делитесь в комментариях, будет интересно обсудить.