corosync pacemaker 配置高可用集群

认识 corosync

corosync 是集群管理套件的一部分,它在传递信息的时候可以通过一个简单的配置文件
来定义信息传递的方式和协议等。
也就是说 corosync 是 Messaging Layer 集群信息层软件,需要 pacemaker 资源管理
器( CRM ),才能构成一个完整的高可用集群;而我们前面说的 heartbeat v2 版本包括了
Messaging Layer 集群信息层功能和资源管理器。

认识 pacemaker

Pacemaker 是一个集群资源管理器。它利用集群基础构件( heartbeat 或 corosync )提
供的消息和成员管理能力来探测并从节点或资源级别的故障中恢复,以实现群集服务(亦称
资源)的最大可用性。
pacemaker 与 heartbeat 的关系
前面说的 heartbeat v2 版本包括了 Messaging Layer 集群信息层功能和资源管理器
( CRM ),而 heartbeat v3 版本只有 Messaging Layer 集群信息层功能,资源管理器分离
成一个单独项目,这个项目就是 pacemaker 。
相比 heartbeat v2 , pacemaker 配置接口更强大: CLI : crm sh 、 pcs 和 GUI :
hawk(WEB-GUI) 、 LCMC 、 pacemaker-mgmt 、 pcs 等。下面将会用 crm sh 来配置。
下图为官网上提供的集群组件关系

所以 heartbeat v3/corosync+ pacemaker,才能构成一个完整的高可用集群
下面将用 corosync+pacemaker 来搭建简单的 WEB 高可用集群。

corosync 和 pacemaker 下载安装

两台节点主机都要安装。

配置 corosync

配置 corosync.conf 配置文件
我们执行 rpm -ql corosync 可以看到 corosync 安装后的文件位置信息,其中我们看
到/etc/corosync /corosync.conf.example,这个文件是 corosync 配置样例文件,我们只需在该目
录下复制一份,并重命名为 corosync.conf,就可以对其进行配置了:

**文件配置信息如下(特别注意的是 consensus:2400 ,节点协商时间,本
机上小于 1200ms 启动会报错):**

totem {           #图腾,每个 node 同其它 node 通信通过 totem 定义
version: 2 # 配置文件的版本号,唯一合法的版本号为 2 ,不是说我们改动过就是第一版之类的,是被 corosync 所支持的版本,各版本
间语法不同
secauth: on # 安全认证,为安全要开启,用 HMAC/SHA1 加密,会消耗系统资源
threads: 2 # 开启多个线程执行加密或多播,若 secauth 为 off 这项
就没用,若为 on 此项才有意义consensus : 2400      #节点协商时间,本机上小于 1200ms 启动会报错
interface {
    ringnumber: 0 # 每个接口所定义的环,若仅有一个
    node 不定义此项,若有多个 node ,每个 node 有两块网卡(冗余),定义多个 node 上的 eth0 是一个环,
    eth1 是一环,若有多个 node 没定义此项,消息在网络中会形成环路一起传递下去
    bindnetaddr: 172.25.254.0 # 绑定的网络地址,若一个node 上有两块网卡,在哪个网络上传递信息,在哪个网络进行多播,这项定义的是网络,不能写 IP ,是 IP所在的网络地址
    mcastaddr: 226.98.254.1 #D 类 IP ,仅能使用224.0.2.0~238.255.255.255
    mcastport: 5405 # 组播端口
    }
}
logging {
    fileline: off # 定义不同的日志间打印分隔符
    to_stderr: no # 发到标准错误输出,也就是屏幕
    to_logfile: yes # 使用指定文件记录日志
    to_syslog: no # 用系统自带的 syslog 记录 /var/log/messages ,只开一项即可
    logfile: /var/log/cluster/corosync.log # 此目录不存在,记得在开启服务前要创建此目录
    debug: off # 出错时打开此项调试
    timestamp: on # 记录时间戳,能定位错误,若开启此项每记录一次日志都要获取一次当前系统时间(一次系统调用要返回用户空间,内核通过硬件获取时间),多记录一个条目会使文件体积变大)
    logger_subsys { # 日志子系统信息
    subsys: AMF
    debug: off
    }
}
amf {
    mode: disabled (没安装 openais ,未启用)
}
service {    # 添加此段,启动 corosync 时,将 pacemaker 也启动
    ver: 0
    name: pacemaker
    #use_mgmtd: yes
}
aisexec { # 运行 openais 所指定用户和组,由于未安装 openais ,此段忽略
    user: root
    group: root
}

配置 authkey 密钥认证文件

在 heartbeat 中我们是通过 authkeys 配置文件来进行的,这里直接执行命令
即可,我们看到生成了 /etc/corosync/authkey 的加密数据,过程如下:

上面在 server1 上配置好了这两个文件,可以直接远程复制到 server2 上,
内容、权限都一样:

启动测试

1 、在 server1 上先启动自己的 corosync 服务,再 SSH 远程启动 server2 的,用 crm_mon
查看监控状态,可以看到两个节点都正常上线, DC 为 server1 :


到这里,配置 corosync+pacemaker 可以正常运行了
下面将用 crm sh 接着进行 corosync+pacemaker+NFS 共享存储的 WEB 高可用集
群的余下相关配置……

认识 crm sh

相比 heartbeat v2 , pacemaker 配置接口更强大: CLI : crm sh 、 pcs 和
GUI : hawk(WEB-GUI) 、 LCMC 、 pacemaker-mgmt 、 pcs 等 , 下面将会用 crm
sh 来配置。
crm ( sh )命令行模式的资源管理器配置接口,从 pacemaker 1.1.8 开始, crm
sh 发展成一个独立项目, pacemaker 中不再提供,得另外下载安装,而我们安装
pacemaker 时另外一个包就是 crmsh ,已经安装了。
crm sh 使用方法
crm sh 两种使用模式:交互式和批处理,批处理配置立即生效使,交互式配置执行
commit 命令以后才生效,交互式支持自动补全。交互式用方法如下:

[root@node1 ~]# crm    # 输入 crm 命令,进入 crm sh 模式
crm(live)# help     # 输入 help 查看一下,会出下很多子命令
crm(live)# configure    #输入configure 就会进入, configure 模式下,
crm(live)configure  #敲两下 tab 键就会显示 configure 下全部命令
crm(live)configure# help node   #输入 help 加你想了解的任意命令,就会显示该命令的使用帮助与案例
crm(live)configure# cd ../  # 返回上一级

crm sh 常用操作
1 、查看一下集群状态,这和使用 crm_mon 是一样的,如下:
crm(live)# status

2 、查看一下 CIB 配置:
crm(live)# configure
crm(live)configure# show
crm(live)configure# show xml # 查 xml 格式文件

3 、检测一下配置文件是否有错,可以看到刚开始默认 STONITH 配
置错误,因为没有 STONITH 设备(下面再解决):
crm(live)configure# verify

4 、查看某种类别下的所用资源代理的列表,分别查看了所有
lsb 类型资源、 heartbeat 资源代理和 pacemaker 资源代理:
crm(live)ra# list lsb
crm(live)ra# list ocf heartbeat
crm(live)ra# list ocf pacemaker

简单说明就到这,其实就是一句话,不会的命令 help 一下。
下面我们开始配置高可用的 Web 集群。

配置集群资源组

集群中拥有三个资源 VIP 、 NFS 存储和 httpd ,如果只是把各个资源
配置进去就启动集群,各资源可能会被分摊到各节点上,而且它
们的启动、停止顺序也不明确,所以我们要根据需要配置资源组
或资源约束。
下面先尝试比较简单的方式,把 VIP 、 NFS 存储和 httpd 三个资源配置到资源组
group_webservice 里,按顺序启动,注意配置的参数,配置过程如下:
1 、先解决上面发现的刚开始默认 STONITH 配置错误,因为没有 STONITH 设备,修改
默认属性配置,如下:
crm(live)configure# property stonith-enabled=false
2、创建 IP 地址资源,IP 资源是主资源,可以查看一下怎么定义一个主资源,配置验证后,记得提
交,提交立即生效,可以看到 VIP 配置到 node1 上,过程如下:

crm(live)configure# primitive
crm(live)configure# primitive vip ocf:heartbeat:IPaddr
params ip=172.25.254.240 nic=eth0 cidr_netmask=24
crm(live)configure# verify
crm(live)configure# commit

3、接着配置 NFS 共享存储和 httpd 服务,配置生效后,看到三个资源不在同一节点上,如下:

crm(live)configure# primitive httpd lsb:httpd
crm(live)configure# verify
crm(live)configure# commit

crm(live)configure# primitive nfs ocf:heartbeat:Filesystem params
device=172.25.254.2:/web/hahtml directory=/var/www/html fstype=nfs
crm(live)configure# verify
crm(live)configure# commit

4、创建资源组,把三个资源加到里面,使三个资源在同一节点上运行,如下:

crm(live)configure# group group_httpd httpd VIP
crm(live)configure# verify
crm(live)configure# commit

由于 NFS 服务失败,只添加了 httpd 和 VIP 测试效果:

正常运行后,查看 VIP 配置在 server1 的 eth0 上,再通过浏览器访问
VIP ,返回的是 server1 服务器上的页面:


使活动节点 server1 关掉,可以看到 server2 成为主节点,查看 VIP 配
置在 server2 的 eth0 上,再通过浏览器访问 VIP ,返回的是 server2 服
务器上的页面:


使活动节点 server1 重新上线,可以看到资源重回转到 server1
资源回转的问题(资源黏性)
上面启动资源组测试第三步: server2 为拥有资源的活动节点,现使得 server1 重新上
线也成功为活动节点,可以看到资源重回转到 node1 (但也可能不回去)。
资源的这种在节点间每一次的来回流动都会造成那段时间内其无法正常被访问,所以,
我们有时候需要在资源因为节点故障转移到其它节点后,即便原来的节点恢复正常也禁止资
源再次流转回来。
而设置提交后,重复上面的测试过程,可以看到 server2 上的资源
不再回转到 server1, 继续留在 server2 上

crm(live)configure# rsc_defaults resource-stickiness=100
crm(live)configure# commit

以上测试说明 crm sh 配置的 corosync+pacemaker 集群提供了高可
用功能