Syndic

Syndic позволяет организовать мастера Salt в иерархию, где на вершине находится «мастер над мастерами» (master of masters), а под ним — промежуточные мастера со своими миньонами. Демон salt-syndic устанавливается рядом с промежуточным мастером и выступает в роли переводчика между уровнями: вверху он выглядит как обычный миньон, а внизу транслирует команды своего вышестоящего мастера собственным миньонам. Оператор на вершине выполняет одну команду и достигает всего парка, при этом каждый сегмент несёт свою нагрузку: файлы, pillar и возвраты обрабатываются локальным мастером. В отличие от multi-master, который добавляет отказоустойчивость на одном уровне, syndic решает задачи масштаба и сегментации — это разные инструменты, которые можно сочетать.

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

На вершине иерархии в конфиге мастера включается order_masters: True, без этого он не будет паковать публикации так, чтобы syndic мог их ретранслировать. На промежуточном узле работают два демона: обычный salt-master, обслуживающий локальных миньонов, и salt-syndic, в конфиге которого указан вышестоящий мастер (syndic_master: mom.example.com). Syndic подключается вверх как миньон — его ключ нужно принять на master of masters через salt-key. Механика такова: команда, опубликованная наверху, спускается через syndic на локальный мастер и раздаётся его миньонам; результаты собираются локальным мастером и пересылаются вверх, события локальной шины тоже пробрасываются на вышестоящую. Таргетинг работает сквозь иерархию: salt '*' test.ping наверху опросит миньонов всех сегментов. Поскольку возвраты идут через дополнительный уровень, агрегация занимает больше времени — тайминги ожидания (например, syndic_wait) подстраивают под задержки сети между уровнями.

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

Классический сценарий — географическая или организационная сегментация: региональные площадки, изолированные контуры, зоны с ограниченной связностью. В каждом сегменте живёт локальный мастер (быстрые файлы и pillar, работа при потере связи с центром), а сверху остаётся единая точка обзора и управления. Второй сценарий — чистый масштаб: когда миньонов больше, чем комфортно тянет один уровень мастеров, дерево syndic распределяет нагрузку. Третий — делегирование: командам сегментов отдают их локальные мастера, центр оставляет себе сквозные операции. Если же вам нужна только отказоустойчивость пары мастеров в одной сети — syndic избыточен, берите multi-master. И трезво оценивайте цену: каждый уровень — это свои конфиги, свои ключи и своя специфика отладки.

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

Первая — забытый order_masters: True наверху: иерархия выглядит собранной, ключ syndic принят, но команды вниз не доходят. Вторая — ожидание, что file_roots и pillar «унаследуются» сверху: каждый мастер в дереве обслуживает свои файлы и pillar сам, и без синхронизации (GitFS на всех уровнях) сегменты разъезжаются по версиям состояний. Третья — неверная трактовка таймаутов: вершина показывает «Minion did not respond» для дальних сегментов не потому, что миньоны мертвы, а потому что возвраты не успели подняться, — сначала подстройте тайминги ожидания, потом делайте выводы. Четвёртая — дубли minion id в разных сегментах: наверху их результаты сливаются неразличимо, уникальность id должна соблюдаться во всём дереве, а не в пределах одного мастера.

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

• Масштабирование и HA
• Multi-master
• Архитектура master–minion
• Шина событий
• Ключи и salt-key