自动化运维之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节点 。
推荐阅读
- 华云大咖说 云计算云运维浅谈
- 初探 iOS 自动化工具——快捷指令
- 能装进口袋的工程师运维笔记本：壹号本壹号工程师PC A1
- 国家电网自助终端集成向日葵，远程运维安全高效
- 星鸟公司建立数据运维监控与维护体系 确保数据准确性
- 自动化盈利：靠「知乎好物推荐」月入过万
- 上海道客：工业大数据在生产设备智能运维领域的应用
- 嘘！偷窥鹅厂运维专家，让Linux内核奔跑起来不得不说的秘密
- 工作|好书·书摘丨“自动化”真的是AI独立完成的吗？
- 自动化|唐林垚：“脱离算法自动化决策权”的虚幻承诺