续我的上篇博文：https://mp.csdn.net/postedit/89001835。即ansible已经安装配置好
一、前言
前面我们均以单master管理多minion的方式开展学习，在saltstack架构扩展中，我们将学习如何扩展salt的架构，解决salt在管理大量minion时的扩展问题以及salt master的高可用问题。
1、salt的多master高可用架构
- salt多master只需要在minion端配置多个master地址即可实现。salt支持多master的配置，salt多master方式只是让一台minion可以同时接受两台或多台master的管理而已。因此，多个master之间不会有任何感知，也没有状态的同步，我们只需要自己维护多个master，让它们的配置文件、状态文件和**文件完全相同，否则只从minion端配置多个master是无法实现高可用架构的。
在生产环境中，应注意master之间的配置文件、状态文件和**文件的实时同步问题，可以用比较成熟的rsync+inotify或sersync方式完成实时同步。
2、syndic方式扩展salt的管理架构
- 通过salt的多master高可用的方式我们可以避免了salt-master的单点问题，但是如果管理主机的数量非常巨大，那一台master性能就会出现问题，这时候我们需要对salt进行多级扩展，用syndic的方式可以完成多级扩展，syndic的扩展架构如上图。
- 什么是syndic？它是一种中间层，接受来自master的任务，然后将任务下发给所有由syndic管理的minion机器，最后将所有minion执行的结果返回给syndic，syndic再将结果发回给master。有了syndic作为中间层，大大减轻了master的压力，不需要master和每一台被管理的minion直接进行通信。
- salt-syndic如果大家知道zabbix proxy的话那就可以很容易理解了，syndic的意思为理事，其实如果叫salt-proxy的话那就更好理解了，它就是一层代理，如同zabbix proxy功能一样，隔离master与minion，使其不需要通讯，只需要与syndic都通讯就可以，这样的话就可以在跨机房的时候将架构清晰部署了。
本篇博文只讲解syndic方式扩展salt
二、实验环境(rhel7.3版本)
1、selinux和firewalld状态为disabled
2、各主机信息如下：
| 主机 | ip |
|---|---|
| server1（master） | 172.25.83.1 |
| server2（minion） | 172.25.83.2 |
| server3（minion） | 172.25.83.3 |
| server4（top mater） |
172.25.83.4 |
原本server4为server1的minion端，在这个实验中我们要将server4作为topmaster端。server1作为master端，server2,3为server1的minion端。
3、删除之前的实验环境，配置所需的实验环境
（1）在master端（server1）删除minion（server4）
[[email protected] ~]# salt-key -d server4 #删除server4这个minion
The following keys are going to be deleted:
Accepted Keys:
server4
Proceed? [N/y] y
Key for minion server4 deleted.
[[email protected] ~]# salt-key -L
Accepted Keys:
server1
server2
server3
Denied Keys:
Unaccepted Keys:
Rejected Keys:
（2）在server4端：停掉salt-minion服务，并设置为开机不自启，安装salt-master软件
[[email protected] ~]# systemctl stop salt-minion
[[email protected] ~]# systemctl disable salt-minion
[[email protected] ~]# yum install salt-master -y
三、salt-syndic的部署
配置server4：
[[email protected] ~]# vim /etc/salt/master
1054 order_masters: True
#参数解释:当额外的数据需要发送和传递,并且这个master控制的minions是被低等级的master或syndic直接管理下,那么”order_masters”这个值必须得设置为True
[[email protected] ~]# systemctl start salt-master
配置server1：
[[email protected] ~]# vim /etc/salt/master
1058 syndic_master: 172.25.83.4 #指定top master
[[email protected] ~]# systemctl restart salt-master #修改配置文件之后,重启服务
[[email protected] ~]# yum install salt-syndic -y #安装salt-syndic软件
[[email protected] ~]# rpm -ql salt-syndic
/usr/bin/salt-syndic
/usr/lib/systemd/system/salt-syndic.service #正是启动salt-syndic服务所需的文件
/usr/share/man/man1/salt-syndic.1.gz
[[email protected] ~]# systemctl start salt-syndic #启动salt-syndic服务
测试：
[[email protected] ~]# salt-key -L #master端(server1)上的salt-key有server1,server2,server3
Accepted Keys:
server1
server2
server3
Denied Keys:
Unaccepted Keys:
Rejected Keys:
[[email protected] ~]# salt-key -L #top master端(server4)上的salt-key只有server1(master端)。
Accepted Keys:
Denied Keys:
Unaccepted Keys:
server1
Rejected Keys:
[[email protected] ~]# salt-key -A #添加所有的minion端
The following keys are going to be accepted:
Unaccepted Keys:
server1
Proceed? [n/Y] y #输入y
Key for minion server1 accepted.
[[email protected] ~]# salt '*' test.ping
值的一提的是：测试时，server1端的mariadb服务（之前做“SaltStack把数据返回到mysql数据库“实验时安装的mariadb-server服务，并在/etc/salt/master中配置过mysql。）必须开启，否则会报下面的错。
[[email protected] ~]# salt server2 state.sls httpd.service #给server2端推送httpd服务- 在server2端查看httpd服务对应的8888端口是否已经打开
上述测试表明：在master端（server1）上能执行的操作，在top master端（server4）上也能执行。