SaltStack中 Syndic架构

一、salt 架构

目前百度还有的知识都是单独master

上述架构比较好搭建都按着默认参数配置即可，但是上述弊端主master 挂了之后，影响使用，本次介绍是双master.架构如下：

master	syndic	minion
salt-master1	sa-syndic1	sa-minion1
salt-master2	sa-syndic2	sa-minion2
node1\node2	node3\node4	node5\node6

在两个主master 上配置：

1 [root@linux-node1 ~]# grep "^[a-Z]" /etc/salt/master
2 default_include: master.d/*.conf
3 file_roots:
4 order_masters: True                        ###### 修改这里，表示允许开启多层master

在sa-syndic 上安装配置：

[root@linux-node3 salt]# yum install salt-syndic -y
[root@linux-node3 salt]# cd /etc/salt/
[root@linux-node3 salt]# grep "^[a-Z]" master
syndic_master: 
  - 192.168.56.11                            # master文件里
  - 192.168.56.12                            ##写上两台master ip
syndic_failover: ordered                       #### 此配置主要有两个参数，random(default) or ordered 默认是random，但是选择此参数后，配置双master ，在任意一台master test.ping minion ,会有时通有时不通，但是选择oeder参数，默认永远是第一台通，第二台不通，只有第一台挂了之后，第二台才开始通信。
syndic_wait: 5

[root@linux-node3 salt]# systemctl start salt-master.service
[root@linux-node3 salt]# systemctl start salt-syndic.service      ###还有就是杀死master进程或者重启syndic 也会自动消失，所以启动master 之后还需要启动syndic
[root@linux-node3 salt]# netstat -tpln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      1/systemd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      998/sshd
tcp        0      0 0.0.0.0:4505            0.0.0.0:*               LISTEN      6013/python
tcp        0      0 0.0.0.0:4506            0.0.0.0:*               LISTEN      6019/python
tcp6       0      0 :::111                  :::*                    LISTEN      1/systemd
tcp6       0      0 :::22                   :::*                    LISTEN      998/sshd

在minion 上配置如下：

[root@linux-node5 salt]# grep "^[a-Z]" minion
master:
  - 192.168.56.13        #两台syndic 主机ip
  - 192.168.56.14

然后回到syndic

[root@linux-node3 salt]# salt-key -L
Accepted Keys:
Denied Keys:
Unaccepted Keys:
linux-node5.example.com
linux-node6.example.com
Rejected Keys:
[root@linux-node3 salt]# salt-key –A                # 把key接受了

最后回到master

[root@linux-node1 ~]# salt-key –L                    # 发现并没有linux-node3.example.com
Accepted Keys:
linux-node3.example.com
linux-node4.example.com

Denied Keys:
Unaccepted Keys:
Rejected Keys:
[root@linux-node1 ~]# salt '*' test.ping
linux-node3.example.com:
    True
linux-node4.example.com:
    True
linux-node5.example.com:                        # 但是它会出现效果
	True
linux-node6.example.com:
    True

三、测试

如果我们syndic的master 配置文件不写syndic_failover: order 参数配置会出现如下情况

[root@linux-node1 ~]# salt -L 'linux-node5.example.com,linux-node6.example.com' test.ping    ####master1
linux-node5.example.com:
    Minion did not return. [No response]
linux-node5.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]

[root@linux-node2 /root]
# salt -L 'linux-node5.example.com,linux-node6.example.com' test.ping 
linux-node5.example.com:
    True
linux-node6.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]

就会出现有时通，有时不通的情况，猜测random(default) 为默认参数，如果不写他会安装随机数去选择master,就会都是有时选择第一台，有时选择第二台

我们参数配置ordered 顺序的方式测试

[root@root@linux-node1 ~]
# salt -L 'linux-node5.example.com,linux-node6.example.com' test.ping 
linux-node5.example.com:
    True
linux-node6.example.com:
    True

[root@root@linux-node1 ~]
# salt -L 'linux-node5.example.com,linux-node6.example.com' test.ping 
linux-node5.example.com:
    True
linux-node6.example.com:

第一台永远都是通的

[root@root@linux-node2 ~]# salt -L 'linux-node5.example.com,linux-node6.example.com' test.ping 
linux-node5.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]
linux-node5.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]
ERROR: Minions returned with non-zero exit code
[root@root@linux-node2 ~ ~]# salt -L 'linux-node5.example.com,linux-node6.example.com' test.ping 
linux-node5.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]
linux-node5.example.com:
    Minion did not return. [No response]
linux-node6.example.com:
    Minion did not return. [No response]
ERROR: Minions returned with non-zero exit code


第二台master永远不通，只要当第一台master 宕机之后才会选择第一台

以上就是SaltStack中Syndic 架构双master 双syndic 架构的测试及使用。

syndic 架构的工作原理：

Syndic 本质上是一个特殊的 Minion，其代码就位于 minion.py 中。 Syndic 需要在本地运行 Master，并将需要管理的 Minions 的 Master 指向 Syndic 所在的主机。Syndic 是这么来工作的：

冒充 Minion，建立与高级别的 Master 的连接，订阅所有来自高级 Master 下发的任务。
接收高级 Master 下发的数据后，首先进行解密，解密完成后，将其扔到本地的 Master 接口上进行二次下发。
Syndic 在进行二次下发之后，监听本地 Event 接口，获取所管理的 Minions 的返回。
将返回发送给高级 Master。

syndic 架构优缺点

优点
通过 Syndic，可以建立多层级的 Salt 拓扑，Syndic 下的 Minions 即可通过 Syndic 所在的 Master 进行管理，也可以通过高级 Master 进行管理，架构变得异常灵活。
由于 Syndic 只订阅高级 Master 下发下来的任务，对于文件服务等，Syndic 本地进行配置，可以有效地降低高级 Master 的负载。
缺点
需要保证 Syndic 上的 file_roots 及 pillar_roots 与高级 Master 是一致的。
由于 Syndic 管理了旗下 Minions 的认证，这样高级 Master 并不知道有多少 Syndic 主机，Syndic 下边有多少 Minions。 在高级 Master 上使用 Salt 命令行下发远程执行命令时，如果 Syndic 此时与高级 Master 网络之间有抖动，导致没有收到消息或延迟收到消息， 高级 Master 并不知情。Syndic 并没有返回结果或延迟返回结果，高级 Master 并不能感知到，会导致结果不完整。 如果没有其他验证机制，结果将变得不可控。官方提供的解决方案是增大 syndic_wait 选项，但是只能缓解，并不能根治问题。

后续研究salt 的监控：

针对syndic-wait 参数的官方介绍：
SYNDIC WAIT
syndic_wait is a master configuration file setting that specifies the number of seconds the Salt client should wait for additional syndics to check in with their lists of expected minions before giving up. This value defaults to 5 seconds.

The syndic_wait setting is necessary because the higher-level master does not have a way of knowing which minions are below the syndics. The higher-level master has its own list of expected minions and the masters below them have their own lists as well, so the Salt client does not how long to wait for all returns. The syndic_wait option allows time for all minions to return to the Salt client.

Note

To reduce the amount of time the CLI waits for Minions to respond, install a Minion on the Syndic or tune the value of the syndic_wait configuration.

While it is possible to run a Syndic without a Minion installed on the same system, it is recommended, for a faster CLI response time, to do so. Without a Minion installed on the Syndic node, the timeout value of syndic_wait increases significantly - about three-fold. With a Minion installed on the Syndic, the CLI timeout resides at the value defined in syndic_wait.

Note

If you have a very large infrastructure or many layers of Syndics, you may find that the CLI doesn’t wait long enough for the Syndics to return their events. If you think this is the case, you can set the syndic_wait value in the Master configs on the Master or Syndic nodes from which commands are executed. The default value is 5, and should work for the majority of deployments.

In order for a Master or Syndic node to return information from Minions that are below their Syndics, the CLI requires a short wait time in order to allow the Syndics to gather responses from their Minions. This value is defined in the syndic_wait config option and has a default of five seconds.