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 должна соблюдаться во всём дереве, а не в пределах одного мастера.

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

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

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

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

Полезные ресурсы