背景: 新来这家公司使用Salt来作为基础配置库管理和自动化运维的工具,但是前期同事刚开始使用时只是简单使用,因此对于可用性和可靠性来说都会存在很大问题(具体可能出现的问题下面会提到)。不过作为一个专业的SRE或者运维人员,在使用一个基础组件时,必须要考虑的一个问题就是可用性
和可靠性
,以前使用Ansible作为配置管理和自动化运维工具时只需对ssh-key
或者密码进行管理即可通过水平扩容来保证高可用,而在Salt
中需要涉及到salt-minion
的发现以及key
的管理,接下来对高可用的Salt集群架构
进行介绍和实施。
单节点salt-master问题
-
比如说2c2g的机器在管理500+左右的ECS时,就会发现异常慢,而且调用salt-api会出现异常,此时如果去检查资源使用率,就会发现cpu和load都会暴涨,这是因为在使用salt的场景中大部分会使用同步调用,此时salt相关的进程会一直占用资源,直到minion返回结果
-
当单节点主机异常时,整体的salt管控端将会失效,也就意味着全量的主机将无法被统一管理,这对于任何一个基于salt的自动化管理系统来说都是一个大灾难
因此,基于以上考虑,salt-master高可用架构的构建对于任何一个生产环境
的自动化基础设施来讲都是刻不容缓的。
salt-master高可用架构方案
salt高可用方案
在salt的官方文档中提供了三种高可用的方案:
- 多Master结构: 该种方式需要在
minion
中配置多个master,此时默认所有的master都是在线的,同时多个master必须共享相同的cryptographic keys
,而且minion keys
必须在所有的master节点单独允许,此外还需要file_roots
和pillar_roots
保持同步
- 故障切换的多Master结构: 同上,都是多Master架构,默认情况下采用的是顺序master,不过可以通过
master_type
参数修改为failover
,以此来保障多Master节点之间的故障切换(通常failover需要master_alive_interval
和master_shuffle: True
参数支持)
- syndic: salt-syndic其实不能算是一种严格的高可用架构,它有点儿类似代理的方式,即在主控master节点下设置syndic节点,由syndic节点来管控旗下的minion节点
大概了解了集中高可用方案之后,我们做一个简单分析:
- 首先我们为了保障高可用,需要允许任意节点都是高可用的,因此排除
syndic
方案
- 在
多master
,故障切换的多master
和多master下的syndic
中,在可用用性和性能承受范围内考虑架构的简洁性,排除多master下的syndic
方案
因此,最终可供我们选择的即为多master
方案,至于failover
其实只是多master
下的一种类型。
salt-master高可用实施
注意:
在多Master结构
中也提到了,cryptographic key
和file_roots
以及pillar_roots
需要保持同步,我们这里使用共享存储方式来实现多master节点的文件同步。
如果使用的是阿里云,可以使用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使用问题和注意事项
Author
BGBiao
LastMod
2020-11-01
License
原创文章,如需转载请注明文章作者和出处。谢谢!