Начиная с версии 2.6, в ECCM реализована поддержка отказоустойчивой кластерной конфигурации. Кластер строится на основе двух механизмов: обеспечения отказоустойчивости базы данных и обеспечения отказоустойчивости сервисов системы. Каждый из них использует собственный принцип переключения ролей (failover)

Переключение мастерства базы данных

ЕССМ включает в себя две основные базы данных: PostgreSQL и Redis. Для переключения мастерства в PostgreSQL используется механизм Repmgr (Replication Manager), для Redis — Redis Sentinel. Для переключения мастерства в базе данных должны участвовать три узла (ноды) системы:

1. Мастер-нода (Master-node) — основной мастер при запуске кластера до падения БД на нем;
2. Слейв-нода (Slave-node) — резервный мастер, к которому переходит мастерство;
3. Витнесс-нода (Witness-node) — узел-наблюдатель, на котором расположены только сервисы Redis Sentinel и Repmgr. Витнесс-нод может быть более одной.

Узел-наблюдатель выполняет постоянный мониторинг состояния основного и резервных мастеров (проверка работоспособности). В случае, если наблюдатель замечает отсутствие ответов от текущего мастера, то наблюдатель начинает процедуру кворума (голосование).

Кворум Repmgr

Состав голосующей группы

На первом этапе определяется группа участников голосования. Кворум рассчитывается на основе всех узлов, зарегистрированных в кластере со статусом активного. Это включает в себя Master, все Slave и Witness-узлы.

Неактивные или исключённые узлы в расчете кворума не участвуют.

Проведение голосования

При потере связи с мастером кандидат (один из Slave) инициирует процедуру выборов:

1. Опрос — узел опрашивает всех участников кластера;

2. Подсчет голосов —  учитываются ответившие узлы и голос самого кандидата.

Решение о смене мастерства (failover)

После выполнения процедуры принимается решение о переключении мастерства в кластере:

• Если Slave получил более 50% голосов, то он становится новым мастером;
• Если было получено ровно 50% голосов или менее, то Slave записывает в лог ошибку «unable to reach a quorum of nodes» и переходит в режим ожидания, не пытаясь стать мастером. Это предотвращает создание нескольких мастеров в кластере.

Кворум Sentinel

Состав голосующей группы

В Redis Sentinel кворум рассчитывается на основе количества Sentinel-процессов, следящих за кластером. В отказоустойчивой системе ЕССМ Sentinel-процесс находится на Witness-node.

Только те Sentinel-ы, которые настроены на мониторинг данного мастера и находятся в состоянии «активного мониторинга» (субъективно считают мастер доступным или недоступным), участвуют в голосовании. Sentinel-ы, которые вышли из строя, потеряли связь или были исключены, в расчете кворума на момент выборов не участвуют.

Проведение голосования

При обнаружении недоступности мастера Sentinel инициирует процедуру выборов лидера среди Sentinel-ов:

1. Опрос — Sentinel отправляет другим Sentinel-ам запрос на голосование за себя. Каждый Sentinel может отдать свой голос только одному кандидату в текущем раунде голосования по принципу «первый запрос — первый голос»;
2. Подсчет голосов — учитываются ответившие узлы и голос самого кандидата.

Решение о смене мастерства (failover)

После завершения выборов лидера принимается решение о запуске процедуры переключения:

• Если Sentinel набрал более 50% голосов от общего числа Sentinel-ов в кластере, он объявляется лидером и имеет право инициировать failover;

• Если было получено ровно 50% голосов или менее, то failover не инициируется и ожидается новый раунд голосования.

Поведение ролей при смене мастера

В Redis Sentinel и Repmgr после смены мастерства автоматически роль мастера не назначается изначальному узлу мастера. Повторная смена мастерства будет проходить по ранее описанным кворумам и мастер будет назначаться тому узлу, который будет иметь наименьший разрыв по количеству данных с последним мастером кластера.

Переключение мастерства сервисов системы

Для обеспечения отказоустойчивой системы в ЕССМ предусмотрено использование механизма Keepalived. Его использование позволяет на одном виртуальном IP-адресе (VIP) продолжать работу даже при ошибках на одном из узлов. Для переключения мастерства в кластере должно быть два узла:

1. Мастер-нода (Master-node) — основной мастер при запуске кластера;
2. Слейв-нода (Slave-node) — резервный мастер, к которому переходит мастерство.

На каждом из узлов должен быть установлен механизм Keepalived.

Принцип выбора мастера

Если мастер перестал отвечать или несколько сервисов на нем перестали функционировать, то происходит переключение VIP с мастера на резервный узел. Мастером становится узел с наибольшим приоритетом.

Поведение ролей при смене мастера

В Keepalived после смены мастерства новый мастер забирает VIP на свою систему.

Поведение ролей изменяется в зависимости от настроек конфигурации Keepalived. За характер изменения поведения отвечает выставленный приоритет на узле в конфигурационном файле:

• Если на узлах выставлен одинаковый приоритет, то при смене мастерства новый мастер будет оставаться мастер-узлом до тех пор, пока на нем не произойдут ошибки;
• Если на узлах выставлен различный приоритет, то при смене мастерства новый мастер станет резервным, если изначальный будет восстановлен.