saltstack集群管理简介：saltstack的常规方案为 ‘单master-多minions’ 架构 ，如下图左，对批量节点进行管理和操作；在较大规模的集群系统下，常用的为三层架构，‘单master-单syndic-多minions’架构，对集群进行分块管理，如下图右，三层架构可以通过master节点将任务分发到syndic节点，对各个syndic管理的区域的minion机器进行操作，之后结果返回到syndic节点，并二次返回到master节点，可以再master节点一并获取返回结果。
问题：上述架构中的高可用性方案是没有的，仅仅作为一个管理工具，上述架构已经可以满足基本要求；
然而因为公司更多的业务系统通过调用saltstack来进行集群管理，那么对salt的要求也从工具到了基础架构组件的层面，因此，对服务可用性方面的要求
就更高了，salt原生默认‘单master-minion’架构，salt-api也是daemon方式运行，因此，在推广到生产环境之后，可用性就遭到了极其严重的考验，
比如，单master故障整个集群的操作就实现不了，如何实时迁移恢复，如何对文件进行备份，如何对master节点和syndic节点做主备方案，如何使得主备管理均可访问到
minion节点，又如何对三层架构syndic节点存储的文件做到统一管理，并且进行文件主备方案，高可用性也是在生产环境中任何系统所必须的一项内容。
方案：mutil-master，mutil-syndic，以及使用gitfs对syndic节点的文件进行同步到服务器。并将服务器做好两城主备。
官方相关参考文档：http://docs.saltstack.com/en/latest/topics/highavailability/index.html
在参考了几个成功案例之后，最后的架构参考了：MultiSyndic、MultiMaster、Failover Minion、Ext Job Cache
博客地址：http://openskill.cn/article/181
mutil-syndic
首先是mutil-syndic，mutil-syndic是指一台syndic节点同时被多台MOfM（master of masters）管理，官方文档对简单的配置做了一些介绍：
https://docs.saltstack.com/en/latest/topics/topology/syndic.html
具体的源码则是放到了minion.py，本身原理便是MultiSYndic会去复用一些Syndic的功能，然后做一些转发的处理。
具体的设置综合mutil-master，需要设置syndic_master为一个list，另外key等文件要做共享设置，其次就是写入一些必要
的syndic本身的配置。
Failover Minion or MultiMinion
这是salt在minion端实现的特性，它允许minion定期的去探测当前master的存活性，一旦发现master不可用，就在一定时间
内做出切换，从而提供整体服务调用的可用性。
具体配置参考官网内容：https://docs.saltstack.com/en/develop/topics/tutorials/multimaster_pki.html
需要注意的是配置multi-master或者multimaster PKI都可以使用failover特性。minion的具体配置内容如下：
# multi-master
master:
- 172.16.0.10
- 172.16.0.11
- 172.16.0.12
# 设置为failover minion
master_type: failover
# 设置启动时随机选择一台master
master_shuffle: True
# 探测master是否存活的schedule job
# 即使用salt schedule特性实现的功能
master_alive_interval: <seconds>
但是上述架构也是有弊端的，正如开端描述的，MOfM在下发命令的时候，所有的节点都通过syndic节点在短时间内大量返回，MofM就等于承受了一次短时间的数据流量的
冲击，1W台minion就是1W条minion job数据，再加上find job任务，理论上产生的数据量和计算能力的消耗是巨大的。
因而在生产环境中，我们目前基本上是在采用，对于某些区域的机器，直接在syndic节点进行操作。这样就避免造成master巨大的处理能力。
然而，我们在master节点进行全区域操作的情况下，master并非是对所有区域同时进行访问，而是在等待单syndic节点返回结束后，开始进行下一个syndic节点的返回。