Multi-master

Multi-master представляет собой несколько Salt-мастеров, управляющих одним парком миньонов. Основная цель — исключение единой точки отказа: обновление, падение или обслуживание одного мастера не должны лишать вас управления инфраструктурой. Дополнительный бонус — распределение нагрузки: запросы файлов и pillar перераспределяются между несколькими серверами. Ключевой момент: миньон доверяет мастеру по его RSA-ключу, поэтому все мастера должны использовать одну и ту же ключевую пару. Без этого миньон, принявший ключ первого мастера, отвергнет второй. Salt поддерживает два режима работы миньонов с несколькими мастерами: активные соединения со всеми сразу (по умолчанию) и failover — работа с одним мастером и переключение при его недоступности.

Как это работает

Настройка начинается с копирования пары ключей /etc/salt/pki/master/master.pem и master.pub с первого мастера на все остальные мастера безопасным способом, поскольку это самый чувствительный секрет системы. Миньонам мастера перечисляются в конфигурационном файле:

master:
  - master1.example.com
  - master2.example.com

По умолчанию миньон поддерживает соединения со всеми мастерами, и любой из них может публиковать задания — это активно-активная схема. В режиме master_type: failover миньон подключается только к одному мастеру, проверяет его доступность с интервалом master_alive_interval и при отказе переходит к следующему из списка. Ключ каждого миньона должен быть принят на каждом мастере командой salt-key -a, поскольку списки принятых ключей не реплицируются автоматически. Не реплицируются и данные: file_roots, pillar и конфигурация мастера — их синхронизация лежит на вас. Практический стандарт — GitFS и pillar из git: оба мастера читают одни и те же ветки, и рассинхронизация исключена по построению. Job cache у каждого мастера свой: результаты задания видит только тот мастер, который его опубликовал.

Когда применять

Главный критерий — требование отказоустойчивости управления: если «мастер лежит, ничего не можем сделать» — неприемлемый сценарий, нужен второй мастер. Активно-активный режим по умолчанию хорош для пары мастеров в одной сети: оба всегда готовы, операторы могут работать с любым. Failover-режим выбирают для геораспределённых схем: миньоны площадки работают с локальным мастером и переходят на резервный только при аварии, не создавая постоянного меж-площадочного трафика. Multi-master не заменяет syndic: он не строит иерархию и не уменьшает число миньонов на мастере — если проблема в масштабе, а не в отказоустойчивости, смотрите в сторону syndic или тюнинга. Обе схемы можно совмещать: syndic-узлы сами могут быть multi-master.

Типичные ошибки

Самая частая ошибка — разные ключи мастеров: миньоны логируют ошибки верификации и не подключаются ко второму мастеру; ключи должны быть побайтово одинаковыми. Вторая — забытая синхронизация принятых ключей миньонов: после failover миньон приходит на резервный мастер, а тот держит его в списке непринятых. Третья — расхождение состояний: правки SLS вносятся на одном мастере руками, второй остаётся со старой версией, и state.apply даёт разные результаты в зависимости от мастера — переходите на GitFS, локальные правки на мастерах запретите. Четвёртая — считать, что multi-master удваивает пропускную способность publish-канала: рассылка и так широковещательная, выигрыш от второго мастера — в основном на request-канале (файлы, pillar, возвраты) и в отказоустойчивости, а не в скорости команд.

Связанные понятия

• Масштабирование и HA
• Syndic
• Ключи и salt-key
• GitFS
• Конфигурация minion