Настройка восстановления после отказа в режиме stateful с etcd¶

Схема переключения лидер-узлов¶

За смену экземпляров с ролью лидера в кластере отвечает узел-координатор. Переключение выполняется так:

1. Один узел-координатор с ролью failover-coordinator захватывает на время блокировку в etcd. Так он становится активным, а остальные узлы с этой ролью – резервными.

2. Координатор читает карту лидеров из etcd – информацию о том, какой узел является лидером в каждом из наборов реплик. При необходимости координатор меняет карту и обнуляет vclockkeeper (информацию о предыдущем лидере) для выбранных наборов реплик.

3. Экземпляры хранилищ получают изменения в карте из etcd c помощью методов длинных опросов (запрос long‑poll на /leaders) и при наличии изменений выполняют переключение режима read_only.

Параметры, влияющие на скорость переключения лидера¶

Возможные задержки при переключении¶

Когда координатор выполняет смену лидера, задержки при переключении могут возникать в следующих случаях:

• при работе координатора;

• при переключении узла с ролью лидера вручную;

• на экземплярах Tarantool.

Задержка измеряется в величине RTT. Здесь время приема-передачи (RTT, round‑trip time) – это время, за которое HTTP‑запрос проходит полный цикл из Tarantool в etcd и обратно. Время приема-передачи включает: отправку HTTP‑запроса из Tarantool в etcd, обработку запроса в etcd, сетевую задержку и получение ответа из etcd.

4 RTT + ROLES_APPLY_TIME

Допустимое время обнаружения отказа лидера¶

В общем случае при настройках по умолчанию доступность кластера гарантированно составляет 99,99% времени (четыре девятки). При более строгих требованиях SLA можно придерживаться методики ниже.

Чтобы определить приемлемое время обнаружения отказа лидер-узла, сначала нужно опираться на требования к доступности системы: SLA (Service Level Agreement) и связанные показатели RTO (Recovery Time Objective).

SLA определяет допустимое время простоя за определенный период – например, процент доступности в виде количества «девяток». Чем строже требования SLA (больше «девяток» доступности), тем меньше суммарный простой системы в месяц или год:

В свою очередь, RTO – это максимальное время восстановления системы после сбоя, приемлемое для бизнеса. RTO определяет, сколько времени сервис может быть недоступен при отказе, прежде чем это нарушит SLA или требования бизнеса.

Принято, что время обнаружения отказа лидера (failover_timeout) и время переключения на резервный узел вместе должны укладываться в заданный RTO. Если ваш SLA определяет, что при сбое сервис должен восстановиться, например, не более чем за 1 минуту (RTO = 60 секунд), то время на обнаружение сбоя лидера должно быть существенно меньше этого значения, чтобы осталось время на сам процесс переключения. Формально это можно выразить так:

(failover_timeout + T_failover) ≤ RTO,

где T_failover – время, необходимое для фактического выполнения переключения на резервный экземпляр, в том числе перевод реплики в статус лидера, перенаправление запросов и запуск сервисов на новом лидере.

Таким образом, допустимое время обнаружения отказа failover_timeout можно оценить так:

failover_timeout ≈ RTO – T_failover.

Например, если RTO составляет 60 с, а переключение на реплику занимает около 30 с, то значение failover_timeout должно быть около 30 с или меньше. Если же бизнес требует RTO в считанные секунды, то и обнаружение отказа должно происходить за секунды – что на практике очень сложно и дорого обеспечить.

Таким образом, расчёт времени обнаружения отказа лидера проводится так:

1. Определите требования к максимуму простоя (SLA). Узнайте, какой процент доступности или максимальный простой допускаются.

2. Установите RTO на основе бизнес-требований. RTO обычно формулируется как допустимое время восстановления при единичном инциденте. Он должен соответствовать SLA, например, для 99.99% может потребоваться RTO около 1–2 минут или меньше. Если SLA выражен только в процентах, можно перевести его в допустимый простой и распределить на ожидаемое число отказов. Например, если максимум простоя в месяц составляет 4 минуты, и вы хотите покрыть 2 сбоя в месяц, то цель – не более 2 минут на восстановление каждого, включая обнаружение.

3. Рассчитайте необходимое время обнаружения отказа лидера (failover_timeout). Рекомендованная нижняя граница для этого времени – 1 секунда. Tarantool работает в среде без строгих гарантий реального времени – задержки могут вносить событийный цикл (event loop) и планировщик файберов Tarantool, а также сетевые стеки ОС. Например, минимальное время ожидания повторной отправки TCP SYN по умолчанию составляет ~1 с, что уже задаёт нижнюю границу обнаружения падения узла. Даже при очень маленьких настройках восстановления после отказа фундаментальные задержки сети и ОС обойти нельзя.

Рекомендованные значения настроек¶

• fencing_pause ≈ 1–2 с;

• fencing_timeout ≈ 5–6 × fencing_pause. Пример: 5–10 с при значении fencing_pause в 1–2 c;

• failover_timeout ≈ 2.5–4 × fencing_timeout. Пример: 25–40 с при значении fencing_timeout в 10 с.

Такие рекомендованные значения:

• дают рабочему лидеру около 10 секунд, чтобы уйти в состояние read_only, если он действительно отрезан;

• откладывают переключение лидера примерно до 30 секунд, снижая риск ложного срабатывания failover;

• увеличивают RTO на запись, но остаются в разумных пределах для большинства OLTP‑нагрузок.

Если максимальная сетевая задержка приближается к значению failover_timeout, возможны ложноположительные переключения. Координатор может принять такую задержку за «смерть» узла лидера. Механизм fencing переводит узел в состояние read_only и этим частично снижает риск ложноположительного переключения, однако окно гонки остаётся и при высокой RPS возможны конфликты репликации. Конфликт репликации гораздо хуже краткой недоступности в read_only. При таком конфликте одновременно теряется часть записей и отсутствует возможность писать данные, а восстановление занимает существенно больше времени и почти всегда требует привлечения дежурной команды DBA/SRE.