高可用集群corosync+pacemaker之crmsh使用（一）
上一篇博客我们聊了下高可用集群corosync+pacemaker的相关概念以及corosync的配置，回顾请参考https://www.cnblogs.com/qiuhom-1874/p/13585921.html；今天我们来说一下corosync+pacemaker高可用集群的配置工具crmsh安装和使用；在centos7上默认base仓库没有crmsh这个工具，红帽默认在base仓库中只留了pcs这个配置工具，所以我们要想在centos7上使用crmsh这个工具来管理corosync+pacemaker高可用集群，需要去找对应的包进行安装；好在opensuse给centos7提供了一个仓库，我们可以使用opensuse的仓库去安装这个工具；
上一篇博客我们聊了下高可用集群corosync+pacemaker的相关概念以及corosync的配置，回顾请参考https://www.cnblogs.com/qiuhom-1874/p/13585921.html；今天我们来说一下corosync+pacemaker高可用集群的配置工具crmsh安装和使用；在centos7上默认base仓库没有crmsh这个工具，红帽默认在base仓库中只留了pcs这个配置工具，所以我们要想在centos7上使用crmsh这个工具来管理corosync+pacemaker高可用集群，需要去找对应的包进行安装；好在opensuse给centos7提供了一个仓库，我们可以使用opensuse的仓库去安装这个工具；
1、配置opensuse仓库
[root@node01 ~]# cd /etc/yum.repos.d/ [root@node01 yum.repos.d]# ls CentOS-Base.repo CentOS-Debuginfo.repo CentOS-Sources.repo epel.repo CentOS-Base.repo.bak CentOS-fasttrack.repo CentOS-Vault.repo CentOS-CR.repo CentOS-Media.repo docker-ce.repo [root@node01 yum.repos.d]# rz rz waiting to receive. zmodem trl+C ȡ 100% 350 bytes 350 bytes/s 00:00:01 0 Errors [root@node01 yum.repos.d]# ls CentOS-Base.repo CentOS-Debuginfo.repo CentOS-Sources.repo docker-ce.repo CentOS-Base.repo.bak CentOS-fasttrack.repo CentOS-Vault.repo epel.repo CentOS-CR.repo CentOS-Media.repo crmsh.repo [root@node01 yum.repos.d]# cat crmsh.repo [network_ha-clustering_Stable] name=Stable High Availability/Clustering packages (CentOS_CentOS-7) type=rpm-md baseurl=http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/ gpgcheck=1 gpgkey=http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-7/repodata/repomd.xml.key enabled=1 [root@node01 yum.repos.d]#
提示：crmsh这个工具是一个集群管理工具，只需要在集群某一台server上安装即可，如果有需要在其他节点管理集群，也可以在其他节点配置yum仓库，安装即可；
2、安装crmsh
[root@node01 yum.repos.d]# cd [root@node01 ~]# yum install crmsh -y 已加载插件：fastestmirror, langpacks Loading mirror speeds from cached hostfile * base: mirrors.aliyun.com * extras: mirrors.aliyun.com * updates: mirrors.aliyun.com 正在解决依赖关系 --> 正在检查事务 ---> 软件包 crmsh.noarch.0.3.0.0-6.2 将被 安装 --> 正在处理依赖关系 crmsh-scripts >= 3.0.0-6.2，它被软件包 crmsh-3.0.0-6.2.noarch 需要 --> 正在处理依赖关系 python-parallax，它被软件包 crmsh-3.0.0-6.2.noarch 需要 --> 正在检查事务 ---> 软件包 crmsh-scripts.noarch.0.3.0.0-6.2 将被 安装 ---> 软件包 python-parallax.noarch.0.1.0.1-29.1 将被 安装 --> 解决依赖关系完成 依赖关系解决 ==================================================================================================== Package 架构 版本 源 大小 ==================================================================================================== 正在安装: crmsh noarch 3.0.0-6.2 network_ha-clustering_Stable 746 k 为依赖而安装: crmsh-scripts noarch 3.0.0-6.2 network_ha-clustering_Stable 93 k python-parallax noarch 1.0.1-29.1 network_ha-clustering_Stable 36 k 事务概要 ==================================================================================================== 安装 1 软件包 (+2 依赖软件包) 总计：875 k 总下载量：782 k 安装大小：2.9 M ……省略部分内容…… Running transaction 正在安装 : crmsh-scripts-3.0.0-6.2.noarch 1/3 正在安装 : python-parallax-1.0.1-29.1.noarch 2/3 正在安装 : crmsh-3.0.0-6.2.noarch 3/3 验证中 : python-parallax-1.0.1-29.1.noarch 1/3 验证中 : crmsh-3.0.0-6.2.noarch 2/3 验证中 : crmsh-scripts-3.0.0-6.2.noarch 3/3 已安装: crmsh.noarch 0:3.0.0-6.2 作为依赖被安装: crmsh-scripts.noarch 0:3.0.0-6.2 python-parallax.noarch 0:1.0.1-29.1 完毕！ [root@node01 ~]#
3、crmsh的使用
[root@node01 ~]# crm crm(live)# ls cibstatus help site cd cluster quit end script verify exit ra maintenance bye ? ls node configure back report cib resource up status corosync options history crm(live)# status Stack: corosync Current DC: node02.test.org (version 1.1.21-4.el7-f14e36fd43) - partition with quorum Last updated: Mon Aug 31 22:08:50 2020 Last change: Mon Aug 31 19:41:56 2020 by root via crm_attribute on node01.test.org 2 nodes configured 0 resources configured Online: [ node01.test.org node02.test.org ] No resources crm(live)# bye bye [root@node01 ~]# crm ls cibstatus help site cd cluster quit end script verify exit ra maintenance bye ? ls node configure back report cib resource up status corosync options history [root@node01 ~]# crm status Stack: corosync Current DC: node02.test.org (version 1.1.21-4.el7-f14e36fd43) - partition with quorum Last updated: Mon Aug 31 22:09:08 2020 Last change: Mon Aug 31 19:41:56 2020 by root via crm_attribute on node01.test.org 2 nodes configured 0 resources configured Online: [ node01.test.org node02.test.org ] No resources [root@node01 ~]#
提示：crm有两种使用方式，一种是交互式，直接在命令行敲crm命令就可以进入交互式shell；另外一种是非交互式，在crm 命令后面直接加要执行的命令；
4、crmsh的帮助信息
提示：进入交互式shell使用ls可以查看当前所在位置支持使用那些命令；crmsh它类似Linux中的文件系统，它可以使用ls查看当前位置可以使用的命令，也可以使用cd命令进入到指定配置，或者cd ..返回上级配置界面；比如要进入configure配置，我们可以使用cd configure 也可以直接敲configure进入configure配置；查看帮助可以使用help ，默认是显示当前界面的所有命令的简要帮助，如果要查看某个命令的详细使用格式，可以help 某个命令，如下所示；
5、常用命令使用
status：查看集群状态信息同crm_mon显示一样，不同的是在crmsh交互式界面使用status它不会阻塞，在命令行使用crm_mon它会阻塞终端；
verify：验证当前所在位置的配置信息是否正确，
提示：以上校验配置信息反馈给我们说我们配置了STONITH 但是并没有发现STONITH设备；解决办法关闭STONITH选项
提示：我们的所有配置相关的操作都要进入到configure界面操作；property这个命令是用来设置集群相关属性的；crmsh支持命令补全，如果不知道一个命令有那些参数可设置可以连续敲两次tab键，它会列出支持的参数；
验证配置，提交配置
提示：只要verify没有报任何错误信息都表示当前配置界面的配置信息正确；没有任何错误，我们就可以使用commit命令来提交配置，让其配置生效；
ra相关命令
classes/class：列出资源类别
info ：查看指定资源代理的元数据信息，简单讲就是查看一个资源代理的详细帮助信息；
提示：以上截图表示查看ocf类别下的heartbeat下的IPaddr这个资源代理的详细帮助信息，其中带星号的参数是必选项，其他选项不指定都是使用默认值；
list：列出指定类别资源代理列表，就是查看指定类别的资源代理中有那些资源可以代理；
providers：查看指定资源是那个providers下的资源代理；
configure相关命令
primitive：定义一个基本资源；
命令使用语法
提示：在configure配置界面，可以使用primitive命令来定义一个资源，其中rsc表示给资源起一个名称，然后指定资源的类别，和资源代理，然后加上指定资源代理需要的参数，以及选项就可以定义好一个资源；
示例：在configure配置界面使用ocf这个资源类别下的heartbeat下的IPaddr来定义一个ip资源，
提示：可以看到当我们验证配置界面的配置没有问题以后，commit配置，对应的资源就生效了，并且在node01上生效了；
验证：在node01上查看对应的ip地址是否配置上去了？
提示：可以看到对应ip地址的确在node01上给配置好了；
验证：把node01模拟下线，看看对应ip地址是否会转移呢？
提示：我们把node01设置为standby以后，在查看集群状态信息，可以看到对应的webip 这个资源已经停止了，并且给我们报了一个错误，说在node02.test.org上没有配置；其实原因是在node02上并没有br0这块网卡，所以它转移过去配置不成功；
在node02上添加一个br0网桥并把ens33桥接到br0上，把ens33的地址配置到br0上，然后重启网络服务，看看对应webip是否会迁移上来呢？
[root@node02 ~]# cd /etc/sysconfig/network-scripts/
[root@node02 network-scripts]# cat ifcfg-br0
TYPE=Bridge
NAME=br0
DEVICE=br0
ONBOOT=yes
IPADDR=192.168.0.42
PREFIX=24
GATEWAY=192.168.0.1
DNS1=192.168.0.1
[root@node02 network-scripts]# cat ifcfg-ens33
TYPE=Ethernet
NAME=ens33
DEVICE=ens33
ONBOOT=yes
BRIDGE=br0
[root@node02 network-scripts]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:0c:29:91:99:30 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.42/24 brd 192.168.0.255 scope global ens33
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fe91:9930/64 scope link
valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:fe:1b:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:fe:1b:15 brd ff:ff:ff:ff:ff:ff
[root@node02 network-scripts]# systemctl restart network
[root@node02 network-scripts]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
link/ether 00:0c:29:91:99:30 brd ff:ff:ff:ff:ff:ff
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
link/ether 52:54:00:fe:1b:15 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN qlen 1000
link/ether 52:54:00:fe:1b:15 brd ff:ff:ff:ff:ff:ff
7: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether 00:0c:29:91:99:30 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.42/24 brd 192.168.0.255 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::b41a:aeff:fe2e:ca6e/64 scope link
valid_lft forever preferred_lft forever
[root@node02 network-scripts]#
提示：可以看到node02上已经有br0，但是我们配置的ip地址并没有迁移过来；
重新将node01上线，然后在下线，看看webip是否能够迁移到node02上？
提示：重新将node01上线以后，再次查看集群状态发现node02离线了，对应webip也停止了；这可能是因为我们刚才在node02上把IP地址迁移到br0上的原因；对于webip不能工作的原因是我们的集群是两个节点的特殊集群，当其中一台server处于离线，就发生了集群网络分区，在线的一方并没有大于总选票的一半，所以对应资源也就停止了；
重启node02上的corosync pacemaker，然后再次进入crmsh终端使用status命令查看集群状态信息
提示：重启node02的corosync和pacemaker后，集群状态恢复正常；
现在将node01设置成standby模式，看看是否将webip迁移到node02上？
提示：可以看到把node01设置为standby模式以后，webip就自动迁移到node02上了；
验证：在node02上查看对应的webip是否真的迁移过来了呢？
提示：在node02上也能看到对应webip资源迁移过来了；
monitor：定义资源的监控选项
命令使用语法
示例：给刚才的webip定义监控选项
提示：从上面的截图可以看到，我们给资源添加监控选项，不外乎在资源的后面用OP参数，指定了OP参数类型是monitor，interval=# timeout=#；其实我们给资源添加监控选项在创建资源的时候就可以在其后使用OP monitor interval=时间 timeout=时间；这里在校验配置信息时提示我们设置的超时时间过短；为了不让它警告我们，我们可以修改对应资源的timeout的值即可，如下
edit：用vim编辑器打开配置文件，进行编辑
提示：使用edit命令即可打开当前configure界面的配置文件，我们可以修改自己需要修改的地方，然后保存退出即可
提示：可以看到当我们修改配置文件以后，再次使用show命令可以看到对应选项的值已经发生变化，校验都没有任何警告；
验证：把node02上的br0:br0:1 down掉,看看它会不会自动启动起来？
提示：刚开始把br0:br0:1down掉以后，在查看集群状态,对应webip是处于正常启动状态的，这是因为监控探测的时间还没有到；等上一会我们再次查看集群状态就会发现报错了；
提示：我们定义的资源监控选项监控到对应资源故障以后，它会把故障写进CIB中，然后把对应的资源进行重启；报错是为了方便我们查看对应资源是否发生故障，提醒管理员排查相关故障；
示例2：定义web服务httpd托管在corosync+pacemaker高可用集群上
1、在集群节点上安装httpd
[root@node01 ~]# yum install httpd -y
提示：在需要转移的所有节点上都要安装；
2、查看httpd资源代理需要用到的参数信息
提示：从上面的截图看，托管httpd不需要任何参数指定；
3、定义托管httpd
提示：以上就是在定义httpd资源时，一起把监控选项给定义好；
查看集群状态
提示：这里提示我们webserver在node01上启动发生了未知错误，所以它在node02上启动了；默认情况托管的服务会负载均衡的在集群节点上运行着；
在node01上排查错误
提示：在node01上查看端口信息，发现node01的80端口被占用了，这也就导致httpd在node01上无法正常启动的原因；
停止掉node01的nginx服务，看看对应webserver是否会迁回node01?
提示：可以看到把node01上的nginx服务停掉以后，webserver并没有从node02迁回node01，这是因为webserver对node02的倾向性和对node01的倾向性是一样的，所以它不会从node02迁移至node01，必经迁移资源也会印象业务嘛；
利用nfs共享存储为httpd提供网页文件
配置node03为nfs服务器
[root@node03 ~]# mkdir -p /data/htdocs/ [root@node03 ~]# cd /data/htdocs/ [root@node03 htdocs]# ls [root@node03 htdocs]# echo "<h1> This page on nfs server</h1>" > index.html [root@node03 htdocs]# cat index.html <h1> This page on nfs server</h1> [root@node03 htdocs]# cat /etc/exports /data/htdocs/ 192.168.0.0/24(rw) [root@node03 htdocs]# groupadd -g 48 apache [root@node03 htdocs]# useradd -u 48 -g 48 -s /sbin/nologin apache [root@node03 htdocs]# id apache uid=48(apache) gid=48(apache) groups=48(apache) [root@node03 htdocs]# setfacl -m u:apache:rwx /data/htdocs/ [root@node03 htdocs]# systemctl start nfs [root@node03 htdocs]# systemctl enable nfs-server.service Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service. [root@node03 htdocs]#
提示：nfs提供共享的目录必须要让apache用户对其有读权限，其次httpd服务来访问nfs是通过在httpd服务器上的apache用户身份来访问nfs,在nfs这边它会识别其UID,GID，所以我们在nfs上要新建一个同httpd服务器上的apache同id的用户；并且设置该用户对nfs共享出来的目录有读权限，如果业务需要上传文件，我们还需要对共享目录设置写和执行权限；
配置托管nfs服务
验证：查看集群状态，看看nfs服务是否运行到集群节点上了？
提示：可以看到westore已经在node01启动了；
验证：在node01上看看对应nfs是否真的挂载上了？
提示：可以看到node01上的确把nfs挂载到我们指定的目录上了；
group：定义组，把多个资源归并到一组；
提示：这里设置多个资源为一个组，默认它会按照先后顺序启动，停止是相反的顺序，所以这里的资源的前后决定了资源启动顺序和停止顺序；当然对于监控选项也是可以加上的，这个和定义单独的资源的监控选项一样，我们可以理解为group是把多个资源归并到一起，使得我们可以以组为单位进行调配和设定；
再次查看集群状态信息
提示：可以看到webstore已经从node01迁移到node02上了；为啥是webstore从node01迁往node02上呢？这是因为webip和webserver都在node02上，它两对node02的倾向性总和要大于webstore；所以webservice对node02的倾向性就要大于node01的倾向性，所以webstore会从node01迁移到node02上；
测试：用浏览器访问webip看看是否能够访问到对应的网页？
测试：把node02设置为standby模式，看看对应网页是否能够继续访问？
提示：可以看到把node02设置成standby模式以后，上面的资源都会迁移到node01上，对于服务来说只是短暂的影响，通常这种影响在用户层面上无所感知的；
到此一个完整的web服务就托管到高可用集群corosync+pacemaker之上了；对于其他服务都是相同的逻辑；
