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