DevOps干货：Saltstack MultiMaster（minion谷）

#自动化运维#

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

大家都知道saltstack这个自动化运维领域的神器，功能丰富强大，当然少不了考虑大规模集群下的高可用和高性能了，所以多master架构是个很顺其自然的方案。下面来看看干货。

1. Salt Minion连接多Master

Salt Minion可以同时有多个Master，一旦连住就会保持长连接，并且会不断检测Master是否存活，然后重连。

多Master的连接场景有2种：

Hot connect模式：Minion同时连接多个Master，并且保持长连接。
Failover模式：Minion从中选择一个Master连接，一旦连住就保持长连接，但不会继续连接其他Master。只有发现当前Master故障时，才会去连接下一个Master。

有几个salt minion配置文件中的重要参数

# master_type: str or failover //多master模式时热连接模式还是单连接failover模式 random_master: True/False //按照顺序选择master还是，随机选，在新版本里参数名改成了master_shuffle master_alive_check: 5 //在长链接里检查Master是否存活，若不存活，则重连 auth_timeout: 2 //连接时的timeout时间 auth_tries: 2 //连接失败的重试次数 retry_dns: 5 //由于上一次域名解析失败导致连接master失败的话，等待x秒再发起域名解析master去重连1.1. Hot Connect模式下的参数配置

原则：快速连接，多次稍长间隔重试

# master_type: str random_master: False //这样主Master按照顺序可以先被连接 master_alive_check: 10 auth_timeout: 2 auth_tries: 3 retry_dns: 51.2. Failover模式下的参数配置

# master_type: failover random_master: False //这样主Master按照顺序可以先被连接 master_alive_check: 10 auth_timeout: 2 auth_tries: 3 retry_dns: 52. Multiple Master和大规模Minion场景下的性能调优

master和minion认证过程中计算signature的步骤时非常消耗CPU的，可以提前计算好master_pubkey_signature来进行优化。参考 Performance Tuning

其他参考资料