Проверки работоспособности серверов#

Angie ADC включает пассивные и активные проверки работоспособности серверов (health probes). Если сервер начинает отвечать с ошибками, Angie ADC временно исключает его из пула доступных серверов.

Пассивные проверки#

Пассивные проверки работают автоматически на основе реальных клиентских запросов.

Пример:

upstream myapp1 {

   server srv1.example.com max_fails=2 fail_timeout=10s;
   server srv2.example.com;
   server srv3.example.com;
}

В этой конфигурации сервер помечается как недоступный после двух неудачных запросов подряд (max_fails=2). Через десять секунд сервер снова проверяется на доступность (fail_timeout=10s). Если он восстановился, запросы снова начинают отправляться на этот сервер.

Активные проверки#

Активные проверки позволяют оценить доступность сервера без участия клиентов. Поддерживаются активные проверки для HTTP и TCP / UDP. Проверки задаются с помощью директивы upstream_probe. Для одного апстрима можно определить несколько проверок. Можно гибко настраивать поведение проверок. Поддерживается отправка ICMP echo-запросов (ping). Подробнее см. справочные материалы по активным проверкам HTTP и stream.

Пример для HTTP#

upstream backend {
    zone backend 1m;

    server backend1.example.com;
    server backend2.example.com;
}

map $upstream_status $good {
    200     "1";
}

server {
    listen ...;

    location /backend {
        ...
        proxy_pass http://backend;

        upstream_probe backend_probe
            uri=/probe
            port=10004
            interval=5s
            test=$good
            essential
            persistent
            fails=3
            passes=3
            max_body=10m
            mode=idle;
    }
}

Детали работы:

Изначально сервер не получает клиентские запросы, пока не пройдет все заданные для него проверки с параметром essential (пропуская помеченные как persistent, если конфигурация перезагружена и до этого сервер считался работающим). Если таких проверок нет, сервер считается работающим.
Сервер считается неработающим и не получает клиентские запросы, если какая-либо заданная для него проверка достигает своего порога fails или сам сервер достигает порога max_fails.
Чтобы неработающий сервер снова мог считаться работающим, все заданные для него проверки должны достичь своего порога passes; после этого учитывается порог max_fails.

Пример для TCP/UDP#

upstream backend {
    zone backend 1m;

    server a.example.com;
    server b.example.com;
}

map $upstream_probe_response $good {
    ~200    "1";
    default  "";
}

server {
    listen ...;

    # ...
    proxy_pass backend;
    upstream_probe_timeout 1s;

    upstream_probe backend_probe
        port=12345
        interval=5s
        test=$good
        essential
        persistent
        fails=3
        passes=3
        max_response=512k
        mode=onfail
        "send=data:GET / HTTP/1.0\r\n\r\n";
}

Примечание

Согласно спецификации RFC 2616 (HTTP/1.1) и RFC 9110 (HTTP Semantics), заголовки HTTP должны разделяться последовательностью CRLF (rn), а не просто n.

Детали работы:

Изначально сервер не получает клиентские запросы, пока не пройдет все заданные для него проверки с параметром essential (пропуская помеченные как persistent, если конфигурация перезагружена и до этого сервер считался работающим). Если таких проверок нет, сервер считается работающим.
Сервер считается неработающим и не получает клиентские запросы, если какая-либо заданная для него проверка достигает своего порога fails или сам сервер достигает порога max_fails.
Чтобы неработающий сервер снова мог считаться работающим, все заданные для него проверки должны достичь своего порога passes; после этого учитывается порог max_fails.

Пример ICMP echo-запроса для HTTP#

http {
    upstream u {
        zone z 1k;

        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
    }

    server {
        listen ...;

        location / {
            proxy_pass http://u/;

            upstream_probe simple1
                 interval=3s
                 ping;

            upstream_probe simple2
                 interval=3s
                 ping ping_timeout=3s;
        }
    }
}

Детали работы:

Используется проверка методом ICMP Echo вместо HTTP-запроса.
ICMP-проверка проверяет доступность IP-адреса 127.0.0.1. Порты upstream игнорируются.
Сервер считается неработающим и не получает клиентские запросы, если не отвечает на запрос ICMP Echo в течение заданного таймаута. Первая проверка использует таймаут ожидания по умолчанию (1 секунда). Вторая проверка задает таймаут ожидания ответа явно (3 секунды).
Единственным критерием прохождения проверки является успешное получение ICMP-ответа в пределах таймаута.