Вопросы, связанные с отказоустойчивостью

Вопрос: В разделе Отказоустойчивая конфигурация указано, что для минимальной схемы необходимо 3 узла. Считается ли набор узлов с ролями DB + Leader + Manager нечетным количеством узлов?

Ответ: Нет. В подсчете не учитывается количество узлов БД/Шлюза. Учитываются только узлы с ролями Leader и Manager.

Вопрос: Будет ли кластер диспетчера при четном количестве узлов отказоустойчивым?

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

Вопрос: Какое минимальное количество узлов для обеспечения отказоустойчивости диспетчера и БД.

Ответ: 5 (DB + DB (с настроенной репликацией между БД), Leader, Manager, Manager).

Вопрос: Можно ли расширять свою инфраструктуру с шагом расширения 1? В таком случае будет четное количество узлов.

Ответ: Можно, однако, это не даст эффекта отказоуйстойчивости. Последует только общее увеличение производительности.

Увеличение производительности достигается только пока в кластере не более 7 менеджеров.

Вопрос: Что произойдет, если в кластере из двух узлов (Leader + Manager) откажет узел с ролью Manager?

Ответ: Leader продолжит работать.
Подключения, которые были установлены через Leader, продолжат работать.
Подключения, которые осуществлялись через Manager, прервутся. В таком случае будет необходимо повторно войти в систему, указав адрес Leader.

Приложение Space Client умеет самостоятельно выбирать следующий адрес подключения в случае отказа одного из адресов Space Disp.

Вопрос: Что произойдет, если в кластере из двух узлов (Leader + Manager) откажет узел с ролью Leader?

Ответ: Кластер остановит работу. Manager будет доступен, однако, полноценная работа со Space Disp будет недоступна. В таком случае автоматического переключения Manager до Leader не произойдет. Необходимо самостоятельно пересобрать кластер с явным назначением нового Leader.

1. На доступном менеджере выполнить команду:

   docker swarm init --force-new-cluster
   

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

3. После восстановления отказавшего узла необходимо на новом Leader/Manager выполнить повышение отказавшего узла до роли Manager командой:

   docker node promote {ID-узла}
   

4. Если шаг 3 выполнить не удается, необходимо заново пересобрать кластер, удалив отказавшие узлы командой:

   docker node rm
   

Вопрос: Нужно ли предпринимать дополнительные шаги, если отказавший узел с ролью Manager становится снова доступен?

Ответ: Нет. Все действия произойдут автоматически. Однако, стоит убедиться, что состояние всех узлов соответствует действительности. Для этого необходимо выполнить команду:

docker node ls

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

Ответ: Использование четного количества узлов возможно, но не рекомендуется. Четное количество узлов даст повышение производительности за счет распределения нагрузки на приложение, но исключает автоматическую логику переключения в случае отказа и увеличивает время, необходимое для восстановления работы кластера.

Вопрос: Что в сервисе понимается под отказоустойчивостью?

Ответ: При отключении N-узлов гарантируется, что сервис автоматически восстановится либо продолжит работу без перерыва сервиса (в зависимости от того, какие узлы выйдут "из строя"). Подключения пользователей, которые выполнялись через отказавшие узлы прервутся, но будут иметь возможность автоматического восстановления соединения или восстановления соединения после повторного входа в систему. Потери данных пользовательских сессий не произойдет.

Вопрос: Что будет, если один из узлов кластера выйдет "из строя" без возможности восстановления?

Ответ: На узлах кластера нет информации, которая требует постоянного хранения. В худшем сценарии потеря данных приведет к сбою некоторых задач по расписанию до выполнения восстановления/переключения остальных узлов. Пользовательские данные, информация о ВМ и другие сущности хранятся в БД, не состоящей в swarm-кластере.

Вопрос: Является ли четный узел “обособленным” от остального кластера?

Ответ: Нет, не является. Главное отличие четного узла — это его способность нарушить механизм кворума при голосовании. В остальном, четный узел — это точно такой же узел кластера.

Вопрос: Какую инфраструктуру лучше выбрать: 6 узлов (четное) или 5 узлов (нечетное)?

Ответ: Предпочтительнее выбирать 5 узлов. Мощности, которые могут обеспечить работу шестого узла, лучше отдать на резервирование БД. Потеря БД создаст существенно больше проблем, чем выход "из строя" даже всего кластера.

Вопрос: Важен ли порядковый номер узлов в подсчетах отказоустойчивости?

Ответ: Нет. Номера приводятся для удобства восприятия.

Вопрос: Как посмотреть текущий состав кластера?

Ответ: Воспользоваться командой:

sudo docker node ls

Вопрос: Что будет, если в кластере из 5 узлов выйдет "из строя" сначала первый узел, затем второй, а потом третий?

Ответ:

• Когда откажет первый узел в течение нескольких минут полностью выполнится восстановление функциональности Space Disp. Перерыв возможен, если отказавший узел - Leader. При отказе Manager - перерыв будет только для клиентов, подключенных к отказавшему узлу (потребуется переподключиться по другому адресу). На этом шаге в кластере остался 1 узел, который может отказать.

• После отказа второго узла логика работы кластера будет такой же, как в предыдущем случае. Если отказавший узел снова был Leader, произойдет перерыв до нескольких минут. После отказа этого узла снова остается 1 узел, который может отказать (т.к. лимит кворума еще не достигнут).

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

• Пример вывода команды docker node ls в разном состоянии кластера:

  Пример 1

  
  Пример 2

  
  Пример 3