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

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#

Директива upstream_probe задает активную проверку работоспособности серверов тех u_upstream, которые указаны в директивах proxy_pass, uwsgi_pass и т. д. в том же контексте location, где находится директива upstream_probe. При этом Angie ADC регулярно выполняет запросы согласно указанным параметрам к каждому серверу в составе апстрима.

Сервер проходит проверку, если запрос к нему успешно выполняется с учетом всех параметров самой директивы upstream_probe и всех параметров, влияющих на использование апстримов тем контекстом location, где она задана. Это касается в том числе директив proxy_next_upstream, uwsgi_next_upstream и пр., а также proxy_set_header и т. д.

Чтобы использовать проверки, в апстриме необходима зона разделяемой памяти (zone). Для одного апстрима можно определить несколько проверок.

Синтаксис

upstream_probe имя [uri=адрес] [port=число] [interval=время] [method=метод] [test=условие] [essential [persistent]] [fails=число] [passes=число] [max_body=размер] [mode=always | idle | onfail];

По умолчанию

—

Контекст

location

Пример#

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;
    }
}

Параметры#

имя

Обязательное имя проверки.

uri

URI запроса, который добавляется к аргументу proxy_pass, uwsgi_pass и т. д. По умолчанию — /.

port

Альтернативный порт для запроса.

interval

Интервал между проверками. По умолчанию — 5s.

method

HTTP-метод запроса проверки. По умолчанию — GET.

test

Проверяемое при запросе условие; задается строкой с переменными. Если результат подстановки переменных — "" или "0", проверка не пройдена.

essential

Если параметр задан, то изначально состояние сервера подлежит уточнению и клиентские запросы не передаются ему, пока проверка не будет пройдена.

persistent

Установка этого параметра требует сначала включить essential; серверы с persistent, работавшие до перезагрузки конфигурации, начинают получать запросы без необходимости сначала пройти эту проверку.

fails

Число последовательных неуспешных запросов, при котором проверка считает сервер неработающим. По умолчанию — 1.

passes

Число последовательных успешных запросов, при котором проверка считает сервер работающим. По умолчанию — 1.

max_body

Максимальный объем памяти для тела ответа. По умолчанию — 256k.

mode

Режим проверки в зависимости от работоспособности серверов:

  • always — серверы проверяются независимо от состояния;

  • idle — проверяются неработающие серверы, а также серверы, где с последнего клиентского запроса прошло время interval.

  • onfail — проверяются серверы только в неработающем состоянии.

По умолчанию — always.

Встроенные переменные#

Модуль http_upstream_probe поддерживает следующие встроенные переменные:

  • $upstream_probe: имя активной сейчас проверки upstream_probe.

  • $upstream_probe_body: тело ответа от сервера, полученного при проверке upstream_probe. Его размер ограничен параметром max_body.

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

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

  • Сервер считается неработающим и не получает клиентские запросы, если какая-либо заданная для него проверка достигает своего порога fails или сам сервер достигает порога max_fails.

  • Чтобы неработающий сервер снова мог считаться работающим, все заданные для него проверки должны достичь своего порога passes; после этого учитывается порог max_fails.

Активные проверки для TCP/UDP#

Директива upstream_probe задает активную проверку работоспособности серверов апстрима, указанного в директиве proxy_pass в том же контексте server, где находится директива upstream_probe.

Сервер проходит проверку, если запрос к нему успешно выполняется с учетом всех параметров самой директивы upstream_probe и всех параметров, влияющих на использование апстримов тем контекстом server, где она задана, в том числе директивы proxy_next_upstream.

Чтобы использовать проверки, в апстриме необходима зона разделяемой памяти. Для одного апстрима можно определить несколько проверок.

Синтаксис

upstream_probe имя [port=число] [interval=время] [test=условие] [essential [persistent]] [fails=число] [passes=число] [max_response=размер] [mode=always | idle | onfail] [udp] [send=строка];

По умолчанию

—

Контекст

server

Пример#

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\n\n";
}

Примечание

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

Параметры#

имя

Обязательное имя проверки.

port

Альтернативный порт для запроса.

interval

Интервал между проверками.
По умолчанию — 5s.

test

Проверяемое при запросе условие; задается строкой из переменных. Если результат подстановки всех переменных — "" или "0", проверка не пройдена.

essential

Если параметр задан, то изначально состояние сервера подлежит уточнению и клиентские запросы не передаются ему, пока проверка не будет пройдена.

persistent

Установка этого параметра требует сначала включить essential; серверы с persistent, работавшие до перезагрузки конфигурации, начинают получать запросы без необходимости сначала пройти эту проверку.

fails

Число последовательных неуспешных запросов, при котором проверка считает сервер неработающим.
По умолчанию — 1.

passes

Число последовательных успешных запросов, при котором проверка считает сервер работающим.
По умолчанию — 1.

max_response

Максимальный объем памяти для ответа. Если задано нулевое значение, ожидание ответа отключается.
По умолчанию — 256k.

mode

Режим проверки в зависимости от работоспособности серверов:

  • always — серверы проверяются независимо от состояния;

  • idle — проверяются неработающие серверы, а также серверы, где с последнего клиентского запроса прошло время interval.

  • onfail — проверяются серверы только в неработающем состоянии.

По умолчанию — always.

udp

Если параметр указан, используется протокол UDP. По умолчанию для проверок используется TCP.

send

Отправляемые для проверки данные; это может быть строка с префиксом data: или имя файла с данными (задается абсолютно или относительно каталога /usr/local/angie/).

Встроенные переменные#

Модуль stream_upstream поддерживает следующие встроенные переменные:

  • $upstream_probe: имя активной сейчас проверки upstream_probe.

  • $upstream_probe_response:содержимое ответа, полученного в ходе активной проверки upstream_probe.

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

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

  • Сервер считается неработающим и не получает клиентские запросы, если какая-либо заданная для него проверка достигает своего порога fails или сам сервер достигает порога max_fails.

  • Чтобы неработающий сервер снова мог считаться работающим, все заданные для него проверки должны достичь своего порога passes; после этого учитывается порог max_fails.