背景: 新来这家公司使用Salt来作为基础配置库管理和自动化运维的工具,但是前期同事刚开始使用时只是简单使用,因此对于可用性和可靠性来说都会存在很大问题(具体可能出现的问题下面会提到)。不过作为一个专业的SRE或者运维人员,在使用一个基础组件时,必须要考虑的一个问题就是可用性可靠性,以前使用Ansible作为配置管理和自动化运维工具时只需对ssh-key或者密码进行管理即可通过水平扩容来保证高可用,而在Salt中需要涉及到salt-minion的发现以及key的管理,接下来对高可用的Salt集群架构进行介绍和实施。

单节点salt-master问题

  1. 比如说2c2g的机器在管理500+左右的ECS时,就会发现异常慢,而且调用salt-api会出现异常,此时如果去检查资源使用率,就会发现cpu和load都会暴涨,这是因为在使用salt的场景中大部分会使用同步调用,此时salt相关的进程会一直占用资源,直到minion返回结果

  2. 当单节点主机异常时,整体的salt管控端将会失效,也就意味着全量的主机将无法被统一管理,这对于任何一个基于salt的自动化管理系统来说都是一个大灾难

因此,基于以上考虑,salt-master高可用架构的构建对于任何一个生产环境的自动化基础设施来讲都是刻不容缓的。

salt-master高可用架构方案

salt高可用方案

在salt的官方文档中提供了三种高可用的方案:

  • 多Master结构: 该种方式需要在minion中配置多个master,此时默认所有的master都是在线的,同时多个master必须共享相同的cryptographic keys,而且minion keys 必须在所有的master节点单独允许,此外还需要file_rootspillar_roots保持同步
  • 故障切换的多Master结构: 同上,都是多Master架构,默认情况下采用的是顺序master,不过可以通过master_type参数修改为failover,以此来保障多Master节点之间的故障切换(通常failover需要master_alive_intervalmaster_shuffle: True参数支持)
  • syndic: salt-syndic其实不能算是一种严格的高可用架构,它有点儿类似代理的方式,即在主控master节点下设置syndic节点,由syndic节点来管控旗下的minion节点

大概了解了集中高可用方案之后,我们做一个简单分析:

  1. 首先我们为了保障高可用,需要允许任意节点都是高可用的,因此排除syndic方案
  2. 多master故障切换的多master多master下的syndic中,在可用用性和性能承受范围内考虑架构的简洁性,排除多master下的syndic方案

因此,最终可供我们选择的即为多master方案,至于failover其实只是多master下的一种类型。

salt-master高可用实施

注意:多Master结构中也提到了,cryptographic keyfile_roots以及pillar_roots需要保持同步,我们这里使用共享存储方式来实现多master节点的文件同步。

如果使用的是阿里云,可以使用NAS服务来实现多主机的共享文件存储.

NAS存储

如果是非云,或者非阿里云的环境,可以采用传统的NFS存储方式来实现共享存储,不过NFS仅提供了共享,却不保证高可用性,如果需要大规模使用也是需要考虑备份错输。另外其他的方式就是采用GlusterFS或者CephFS之类的分布式共享存储方案。因此在迁移迁移阶段,我们先采用GlusterFS来提供底层的高可用的共性存储(后期会直接迁移到阿里云的NAS服务)

1.创建一个glusterfs volume

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# 创建一个salt卷(复制卷)
$ gluster volume create salt replica 2 node4:/data/salt node5:/data/salt force

# 查看当前gluster集群下的volume(也供给k8s中的自建mysql使用)
$ gluster volume list
k8s
salt

# 启动salt volume
$ gluster volume start salt
$ gluster volume info salt


# 开启磁盘配额的限制
$ gluster volume quota salt enable
volume quota : success

$ gluster volume quota salt limit-usage / 200GB 90%
volume quota : success

# 查看磁盘配额情况
$ gluster volume quota salt list
+----  1 line: Path                   Hard-limit  Soft-limit      Used  Available  Soft-limit exceeded? Hard-limit exce
-------------------------------------------------------------------------------------------------------------------------------
/                                        200.0GB     90%(180.0GB)   0Bytes 200.0GB              No                   No

# 使用(被挂载节点需要绑定这个hosts)
# 所有的客户端主机均需要安装(glusterfs客户端)
$ yum install glusterfs glusterfs-client -y
$ cat /etc/hosts
10.0.21.74  node4
10.0.21.73 node5

$ mount -t glusterfs 10.0.21.73:/salt /opt/data/salt-data/
$ df -H | grep /opt/data/
10.0.21.73:/salt  215G     0  215G    0% /opt/data/salt-data

2.修改salt-master配置文件

注意: 每次master接收minion的认证后会将认证文件统一存放在pki_dir目录下,如果是在单master像多Master改造,需要保持该文件的全量同步

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# salt-master-1
$ grep -v ^#  /etc/salt/master  | grep -v ^$
interface: 10.0.217.78
pki_dir: /opt/data/salt-data/pki/master
timeout: 10
file_recv: True
log_file: /var/log/salt/master
log_level: info

# salt-master-2
$ grep -v ^#  /etc/salt/master  | grep -v ^$
interface: 10.0.79.88
pki_dir: /opt/data/salt-data/pki/master
timeout: 10
file_recv: True
log_file: /var/log/salt/master
log_level: info

# salt-minion配置示例
# 这里使用随机master,可以减少master的负载
# 如果使用failover模式的话,将永远只有失败之后使用另外的salt-master,整体性价比较低(不过可随时切换)
$ grep -v ^# /etc/salt/minion | grep -v ^$
master:
    - salt-master-2.bgbiao.top
    - salt-master-1.bgbiao.top
random_master: True
id: 10.0.79.90

# 分别重启salt-master和salt-minion进程
# 在任意一台salt-master中同步key
$ salt-key -a 10.0.79.90 -y

# 测试后发现两个salt-master均可以对目标主机执行操作
[root@salt-master-2 ~]# salt 10.0.79.90 test.ping
10.0.79.90:
    True

[root@salt-master-1 ~]# salt 10.0.79.90 test.ping
10.0.79.90:
    True

3.修改file_roots和pillar_sls目录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# 修改salt-master相关配置
# 增加file_roots目录(默认在/srv/salt/目录下)
$ grep -v ^#  /etc/salt/master  | grep -v ^$
interface: 10.0.79.88
pki_dir: /opt/data/salt-data/pki/master
timeout: 10
file_recv: True
file_roots:
  base:
    - /opt/data/salt-data/salt-sls/
log_file: /var/log/salt/master
log_level: info

# 将源master节点/srv/salt/下文件同步到/opt/data/salt-data/salt-sls/目录即可

# 测试salt state文件使用
# 测试hadoop客户端安装
[root@salt-master-2 salt-sls]# salt 10.0.79.90 state.sls hadoop-client.init-hadoop-env
....
....
Summary
-------------
Succeeded: 25 (changed=24)
Failed:     0
-------------
Total states run:     25

# 使用state初始化hadoop环境后测试hadoop客户端是否正常
[root@salt-master-2 salt-sls]# salt 10.0.79.90 cmd.run 'source /etc/profile && hadoop fs -ls /hive;'
10.0.79.90:
    19/12/10 16:37:59 WARN util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
    19/12/10 16:38:00 WARN shortcircuit.DomainSocketFactory: The short-circuit local reads feature cannot be used because libhadoop cannot be loaded.
    Found 3 items
    drwxr-x--x   - root   hadoop          0 2018-12-03 20:05 /hive/dw
    drwxr-x--x   - root   hadoop          0 2019-04-02 11:03 /hive/ods
    drwxr-x--x   - hadoop hadoop          0 2019-07-18 21:26 /hive/rpt

注意:在新的master节点验证完毕后,将全部master节点的/etc/salt/master配置文件进行同步(interface参数需要为指定的地址)即可.

salt-minion接入使用

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
# 安装salt-minion
$ yum install salt-minion -y

# 修改salt-minion配置文件(id为唯一标识salt-minion)
$ cat /etc/salt/minion
master:
    - salt-master-2.bgbiao.top
    - salt-master-1.bgbiao.top
random_master: True
# 其实这里的id可以不用指定,默认为socket.getfqdn()函数值(其实就是ipv4)
id: 10.0.79.90

# 重启salt-minion
$ systemctl daemon-reload && systemctl restart salt-minion

# salt-master手动同意请求(可用设置成定期accept all)
$ salt-key -a 10.0.79.90 -y

salt使用问题和注意事项

  • master设备会为每个minion的auth-request请求计算签名。 在有许多minions和频繁的auth请求时,这可以消耗掉master服务器上相当多的CPU资源.