Масштабирование и HA

Один Salt-мастер — это и узкое место производительности, и единая точка отказа. Хорошая новость: масштабируется Salt заметно лучше, чем кажется, — грамотно настроенный одиночный мастер обслуживает тысячи миньонов, потому что publish-канал широковещательный и не плодит соединения на каждую машину. Поэтому первый шаг всегда — тюнинг существующего мастера, и только потом архитектурные изменения. Их два вида: multi-master (несколько равноправных мастеров для отказоустойчивости и распределения нагрузки) и syndic (иерархия мастеров для очень больших или сегментированных инфраструктур). Эти подходы решают разные задачи и комбинируются, поэтому важно понимать, от какой именно проблемы вы уходите: от падения мастера, от его перегрузки или от сетевой сегментации.

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

Вертикальный путь: мастеру добавляют CPU и память, увеличивают worker_threads (процессы, обрабатывающие запросы миньонов на порту 4506), разносят нагрузку по времени через batch-выполнение и splay в расписаниях. Горизонтальный путь номер один — multi-master: несколько мастеров с одинаковой парой RSA-ключей мастера, миньоны указывают их списком в опции master: и либо держат соединения со всеми (режим по умолчанию), либо работают с одним и переключаются при отказе (master_type: failover). Файлы состояний и pillar при этом нужно синхронизировать между мастерами — обычно через GitFS, который делает git единственным источником правды. Горизонтальный путь номер два — syndic: промежуточные мастера подключаются к мастеру-над-мастерами (order_masters: True), команды спускаются вниз по дереву, события и результаты поднимаются вверх. Каждый syndic-сегмент несёт свою долю миньонов, снимая нагрузку с вершины.

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

До нескольких тысяч миньонов чаще всего достаточно одного мастера с тюнингом — начинайте с гайда «Using Salt at scale», а не с новой архитектуры. Multi-master берите, когда требования формулируются как отказоустойчивость: обновление или падение мастера не должно останавливать управление парком; заодно активно-активная схема распределяет нагрузку запросов файлов и pillar. Syndic нужен в двух случаях: парк настолько велик, что один уровень мастеров не вывозит, либо инфраструктура сегментирована (регионы, изолированные площадки, DMZ), и в каждом сегменте нужен локальный мастер, а сверху — единая точка управления. Не забывайте и про эксплуатационную математику: каждый новый мастер — это ещё один сервер с ключами от всего парка, который нужно защищать, обновлять и мониторить.

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

Первая — строить multi-master до тюнинга: команда решает архитектурой проблему, которая лечится настройкой worker_threads и батчами, и получает двойную эксплуатационную нагрузку без нужды. Вторая — multi-master с рассинхронизированными file_roots/pillar: миньоны получают разные состояния в зависимости от того, к какому мастеру обратились; GitFS или общий репозиторий обязательны. Третья — «thundering herd» после рестарта мастера: тысячи миньонов переаутентифицируются одновременно и кладут его снова; лечится настройками задержек переподключения (random_reauth_delay, acceptance_wait_time). Четвёртая — ожидать от syndic строгой консистентности: возвраты агрегируются асинхронно, и вершина иерархии может видеть результаты с задержкой — это нормальное поведение, а не баг.

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

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

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

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

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