DevOps干货：saltstack高可用架构

我是一个在北京互联网厂子里996的程序员，一边学习追赶新技术，怕被潮流甩下掉队，一边学习投资理财方法，让自己的薪水滚雪球。我相信，越努力越幸运，虽然刚开始雪球滚起来很慢，但是只要坚持下去，它就会越滚越快，自己的养老就靠它了。在财富自由的道路上，我与你共勉。欢迎来评论区与我交流心得和干货，这样我们就可以收获更多。

#saltstack#

大家都知道，作为DevOps的顺手工具，一个是ansible，一个是saltstack，必须要精通一个。今天聊一聊saltstack的高可用架构。

1. Master负责的Minion数量过多，并发消息量过大，导致Master过载而丢消息
2. 如果使用MultiMaster模式，会导致Minion跟Master跨机房通信
3. 如果使用Syndic会导致MOM(MasterOfMaster)无法感知存活的Minion
4. Salt-API没有身份鉴定，命令审核功能

为了解决如上问题，根据官方Saltstack的高可用架构的描述，我们选择了MultiMaster-With-Failover模式作为基础，在此基础之上扩展出了MultiMaster-With-Failover-With-Proxy模式。此处我们将Syndic替换成自研的Proxy。

我们的架构中，同一个机房部署多台Master，Minion使用master_type: failover和 master_shuffle=True的方式随机连接本机房其中一个Master，并且让Minion根据master_alive_interval 定期检查所连Master的健康状态，发现当前Master故障后会自动连接其他Master实现Failover。

优点：该方案可以使得

1. Minion跟Master之间的通信不跨机房
2. 一个Minion同时只跟一个Master保持连接，避免了重复接收命令的问题，并且高可用
3. 通过水平扩展Master，使得Master和Minion的配比保持在一个合理的范围，分散了单个Master的压力

为了实现如上的架构，我们还需要开发Proxy来替换Syndic，对Proxy的需求有

1. 部署在Master机器上，负责从消息管道Subscribe消息，匹配规则，匹配通过后转给本地的Master进而发送给Minion，不匹配则丢弃，规则有如果使用minion id精确匹配，那么Minion需要与本Master直接相连如果使用list、glob、regex等方式，则对连接本Master的Minion进行匹配计算，需要至少匹配到一个待续
2. 将Minion返回给Master的执行结果写入中心的Database保存
3. 定期（如每10s）向Connector汇报本机Master所连接的Minion的连通性状态

优点：该方案可以使得

1. 尽可能减少无用命令的下发
2. 全局知晓Minion的连通性
3. 通过MQ将Connector跟Proxy进行解耦，Proxy也可以水平扩展，Connector也可以

对Connector的需求有

1. 以HTTP协议接收用户请求的命令，兼容原生Salt-API的接口格式支持高并发支持用户身份鉴定支持调用方IP白名单支持命令内容检查支持限流，1分钟内调用不超过N次，可配除了特权用户，其他用户匹配Minion不能用*，批量不超过30，可配
2. 将命令Publish到MQ中，等待Proxy来Subscribe
3. 接收来自所有Proxy的Minion连通状态数据，维护在状态表里，对于精确匹配和List匹配Minion id的API调用，如果其中有失联的Minion，根据用户参数决定是拒绝请求还是接受，如接受，则在返回结果里注明失联

优点：该方案使得

1. Connector可以水平扩展
2. Connector提供了更强的认证和审查机制

通过Flume将Proxy日志，Master日志，Minion日志，Connector日志统一采集汇总到ES

1. 被动模式：实时将错误日志通过邮件发送给开发人员进行问题排查
2. 主动模式：开发人员通过Kibana过滤错误日志进行问题排查

好了，今天的分享就到这里。 如果大家觉得我的分享对你有用，还请点一点关注，在评论区跟我交流，我会持续分享一些有用的知识点和心得。