Масштабирование и 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 строгой консистентности: возвраты агрегируются асинхронно, и вершина иерархии может видеть результаты с задержкой — это нормальное поведение, а не баг.

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

• Multi-master
• Syndic
• Тюнинг производительности
• GitFS
• Batch-выполнение