自动化运维之SaltStack，架构分析和总结接上一篇介绍SaltStack的部署和使用后

接上一篇介绍SaltStack的部署和使用后，今天这篇主要想谈一谈我之前在用SaltStack时，遇到的几方面问题，也算是SaltStack的不足之处。
再通过分析其多种不同的部署架构，能否规避这些问题和不足。希望能帮助到有需要的朋友们。
一，发现和遇到的问题Saltstack拥有强大的远程控制能力，但基于它实现的自动化运维系统在实践过程中发现存在以下问题：
1. Salt-master节点会因CPU占用过多而卡死，发送的命令无法响应。
【自动化运维之SaltStack，架构分析和总结】2. Salt-minion节点偶然出现无法控制(进程正常但失去连接)的情况。
3. Salt-minion数量越来越庞大，对默认部署架构性能和稳定性有影响。
针对以上1 ， 3问题，构建一个稳定的可扩展的SaltStack架构是很有必要的。
至于问题2 ，使用最新版本的minion进行测试，可能的构建代码规避此问题。但是对于windows的支持，就很有限， linux替代windows这个也是大势所趋。
二， SaltStack架构分析通过研读salt最新版文档，总结出下面三种官方架构，并对每种架构与需求的适应性作出总结。
2.1 Multi-master架构
文章插图
这种架构，以两个master为例，对每个对象进行说明：
F5/自制调度系统：对web传过来的请求进行分流，均衡每个master的负载。因为F5无法判断选择的master节点是否能够对指定的minion进行控制，即F5无法判断salt-master是否已无法工作，所以此处我们需要选用自制的调度系统。此调度系统应该能够提供一个可靠的master ，并且进行简单的随机均衡。
Master：每个master都会连接所有的minion ，可以想象， minion数量会越来越多， master将无法承受越来越大的压力。
Shared disk:共享文件/存储的存在是因为master之间需要保持某些数据的一致性。
总结：
此架构可以通过自制调度服务来保证master的稳定性(满足问题1) ，但是无法满足问题3 ，即随着minion数目的增长， master会不堪重负。
2.2 Syndic架构
文章插图
这种架构，以两个syndic-master为例，对每个对象进行说明：
Syndic-master：是介于minion和master之间的一种类型，相当于对整体的salt结构进行分割，每个syndic-master节点控制一部分minions ，因此针对问题3 ，这是个合适的解决方案。
Master of master：是位于syndic上层的master节点，从该节点上执行salt-key –L只能看到syndic节点的key ，无法看到连接到syndic的minion端的key ，但是从此master节点发送指令到某个minion端是可行的。
总结：
Syndic模式分割了saltstack整体，化整为零进行管理，对于大规模的部署较为有利。但是，此架构未能保证master的稳定性，当master of master节点出现问题，此架构将无法工作。
2.3 Syndic-with-multimaster架构
文章插图
这种架构，综合multi-master和syndic ，使问题1和问题3得到基本解决。
使用该架构应该着重考虑下面几点：
1、自制调度系统的构建较为复杂，它应该能实现下列功能：
a) 用户指令到达时，能够定向到某个可用的master上。
b) 应能够达到简单的均衡效果，可以通过随机数。
c) 应能够发现并解决master出现卡死的问题。
d) 应能够转送web端与python端的数据包，可以考虑特殊的sock模式。
2、Minion端注册时需要有规划的选择某个syndic-master节点。