Проверка работоспособности upstream-узлов

В системе контроль доступности backend-узлов выполняется с использованием механизмов Проверки здоровья. Поддерживаются два режима проверки: активный и пассивный. Они могут использоваться совместно.

balancer health check 1

Активная проверка

Активная проверка реализуется за счёт периодической отправки служебных запросов на каждый узел upstream-группы. По результатам ответа определяется текущее состояние узла.

balancer health check 2

Ключевые параметры конфигурации активной проверки:

  • Тип — протокол активной проверки: HTTP, HTTPS или TCP

  • Таймаут — время ожидания ответа от узла

  • Параллельность — количество узлов, проверяемых одновременно

  • Хост — имя хоста или IP-адрес, используемый при проверке

  • Порт — порт узла, на который отправляется проверочный запрос

  • HTTP путь — путь, на который отправляются проверочные HTTP-запросы

  • Проверка HTTPS сертификата — включает проверку сертификата при HTTPS-проверке

    • Healthy → Интервал — интервал проверки доступных узлов

    • Healthy → Успешные — количество успешных проверок подряд для признания узла работоспособным

    • Unhealthy → Интервал — интервал проверки недоступных узлов

    • Unhealthy → HTTP ошибки — количество HTTP-ошибок подряд для признания узла недоступным

    • Unhealthy → TCP ошибки — количество TCP-ошибок подряд для признания узла недоступным

    • Unhealthy → Таймауты — количество таймаутов подряд для признания узла недоступным

Пассивная проверка

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

balancer health check 3

Ключевые параметры пассивной проверки:

  • Тип — протокол пассивной проверки: HTTP, HTTPS или TCP

  • Healthy → Успешные — количество успешных ответов подряд для признания узла работоспособным

  • Unhealthy → HTTP ошибки — количество HTTP-ошибок подряд для признания узла недоступным

  • Unhealthy → TCP ошибки — количество TCP-ошибок подряд для признания узла недоступным

  • Unhealthy → Таймауты — количество таймаутов подряд для признания узла недоступным

Пассивная проверка не позволяет вернуть узел в рабочее состояние. После пометки как неработоспособного трафик на узел не направляется, новые ответы не поступают, состояние не пересчитывается. Для восстановления используется активная проверка, которая выполняет запросы независимо от пользовательского трафика. Рекомендуется совместное использование активной и пассивной проверок.

Особенности проверок

  • Проверки выполняются только при наличии входящего трафика. До поступления первого запроса механизм Проверки здоровья не запускается.

  • Если все узлы upstream-группы признаны недоступными, система игнорирует результаты проверок и продолжает направлять трафик на все узлы. Это позволяет избежать полного отказа сервиса.

  • При конфигурации upstream с одним узлом проверки не выполняются, так как отсутствует возможность перераспределения трафика. Весь трафик направляется на единственный доступный узел.