Балансировщик нагрузки и отказоустойчивость: что проверить до запуска ИТ-сервиса

Корпоративный портал может работать на трех серверах и все равно оказаться недоступным из-за сбоя одного компонента. Например, если весь трафик проходит через единственный балансировщик, отказ этого узла отрежет пользователей от исправных серверов приложения. Поэтому при проектировании отказоустойчивости важно проверить не только число серверов, но и весь путь запроса: от точки входа до базы данных.

Один из инструментов для такой архитектуры, российский балансировщик для отказоустойчивых ИТ-сервисов Termidesk Connect, поддерживает распределение трафика на уровнях L4 и L7, проверки доступности серверов и резервирование узлов самого балансировщика. На этом примере удобно разобрать, какие задачи решает балансировка и что нужно предусмотреть в самом приложении.

Что происходит, когда один из серверов перестает отвечать

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

Проверку доступности стоит подбирать по тому, что действительно важно пользователю. Открытый TCP-порт показывает, что соединение можно установить, но не доказывает, что портал способен обработать запрос. Для веб-приложения информативнее HTTP-проверка специального адреса, на котором приложение сообщает о готовности принимать трафик. Важно определить, какие зависимости действительно необходимы для работы сервиса, чтобы сбой второстепенного компонента не выводил из работы сразу все серверы.

Чем отличаются уровни L4 и L7

• L4. Балансировщик распределяет соединения на транспортном уровне. Такой вариант подходит, когда сервис работает по TCP и для выбора сервера не нужно анализировать содержимое HTTP-запроса.
• L7. Балансировщик принимает решение на прикладном уровне. Например, запросы к разделу /api/ можно отправить на одну группу серверов, а запросы к веб-интерфейсу на другую, сохранив для пользователей один домен.

Отдельно выбирают алгоритм распределения. Round Robin направляет трафик на доступные серверы по очереди. Least Connections ориентируется на количество активных соединений. Второй вариант имеет смысл проверить, если часть соединений держится заметно дольше других. При этом число соединений не показывает напрямую, насколько загружен процессор или сколько памяти осталось у сервера.

Что балансировщик не исправит сам

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

Как проверить схему перед вводом в эксплуатацию

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

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