Резервирование проксируемых серверов и групп#

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

В Angie ADC доступно два механизма резервирования:

Запасные серверы (spare-серверы).
Запасные серверы (spare-серверы) включаются в работу при выходе из строя основных серверов в рамках одной группы. Это позволяет плавно подхватывать трафик без переключения на другую группу серверов. Запасные серверы можно использовать для поддержания производительности системы, например при выводе отдельных серверов на техническое обслуживание.
Резервные группы серверов (backup-группы).
Резервные группы (backup-группы) серверов включаются в работу при отказе всех серверов активной группы и поддерживают отказоустойчивость системы при выходе из строя групп серверов целиком. С помощью backup-групп можно реализовать многоуровневое резервирование большой инфраструктуры.

Можно использовать оба механизма одновременно для обеспечения максимальной надежности.

Примечание

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

Запасные серверы (spare-серверы)#

При настройке апстрим-групп часть серверов в группе можно выделить как запасные, назначив им параметр spare в блоке server. Также можно объявить серверы запасными динамически с помощью API-интерфейса.

Пример:

http {

    upstream u {
        zone z 1m;
        server 127.0.0.1:8081 max_fails=1 fail_timeout=2s weight=2;
        server 127.0.0.1:8082 spare;
        server 127.0.0.1:8083 spare;
    }

По умолчанию запасные (spare) серверы находятся в режиме ожидания и имеют статус idle. В случае выхода из строя одного или нескольких основных серверов группы они включаются в балансировку и переходят в статус up. При восстановлении основных серверов замещающие spare-серверы снова переводятся в режим ожидания. При этом поддерживаются sticky-сессии: запасные серверы, выведенные из активного пула, будут по-прежнему использоваться для таких сессий. Если на запасном сервере настроены активные проверки работоспособности, то сервер не будет включаться в работу, пока проверки не будут пройдены. Неработоспособные запасные серверы будут иметь такие же статусы, как неработоспособные основные.

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

В режиме отладки через REST API доступны значения счетчиков main_weight и active_weight. Для upstream-сервера отображается поле spare со значением idle (сервер не используется) или running (сервер активен). Поле spare_num отображает количество серверов, считающихся запасными.

Резервные группы серверов (backup-группы)#

Резервные группы серверов (backup-группы), в отличие от spare-серверов, представляют собой отдельные группы серверов, выделенные только для резервирования. Upstream-сервер может входить только в одну резервную группу.

Если балансировщик не может найти ни один рабочий сервер в основной группе, то он переходит к серверам backup-группы. Можно добавить одну или несколько backup-групп серверов с разным уровнем резервирования. Тогда балансировщик будет сначала переходить к backup-группе с наименьшим уровнем. Если групп много, можно указать для них произвольные уровни, например для удобства сортировки.

Уровень резервирования backup-группы можно задать с помощью директивы backup=n:

backup=1 (или просто backup) — группа резервных серверов первого уровня (в API отображается как true);
backup=2 — группа резервных серверов второго уровня (в API отображается как соответствующее число);
backup=3 — группа резервных серверов третьего уровня.

Пример:

upstream my_backend {
    server primary1.example.com;
    server primary2.example.com;

    server backend.example.com service=http resolve backup=prio;

    server backup1a.example.com backup;
    server backup1b.example.com backup;

    server backup2a.example.com backup=2;
    server backup2b.example.com backup=2;

    backup_switch permanent=2m;
}

Если upstream-сервер настраивался с помощью SRV-записи, то уровень backup-группы можно определить динамически через поле приоритета (priority). Для этого используется:

Абсолютное значение приоритета (директива backup=prio).
В этом случае значение приоритета priority=n из SRV-записи будет использовано в качестве уровня резервной группы backup=n.
Относительное значение приоритета priority=n из SRV-записи.
В этом случае директива backup=n задает базовый уровень отсчета (например backup=3), а относительные уровни резервирования отсчитываются от этого уровня. Сервер с наименьшим значением priority получит уровень backup=3, следующий за ним — backup=4, и так далее. Если уровень отсчета backup=n не задан, отсчет будет идти от нуля: сервер с наименьшим значением priority получит backup=0 и станет основным, за ним — backup=1, резервный, и так далее.

По умолчанию балансировщик всегда начинает поиск подходящего сервера с основной группы, даже если в данный момент активна резервная. Чтобы этого избежать, можно использовать директиву backup_switch permanent, задав для нее значение, например permanent=2m. В этом случае балансировщик нагрузки будет пытаться вернуться на основную группу не чаще, чем раз в две минуты, что позволит избежать избыточных переключений группы.

Если указать параметр permanent без значения, то выбранная backup-группа будет сохраняться в качестве активной даже после того, как серверы из основной группы снова станут доступными. В случае отказа текущей backup-группы балансировщик будет переключаться на следующую по уровню backup-группу, и, только дойдя до максимального уровня, вернется на основную группу.