openstack controller ha测试环境搭建记录（二）——配置corosync和pacemaker
corosync.conf请备份再编辑：
# vi /etc/corosync/corosync.conf
totem {
version: 2
token: 10000
token_retransmits_before_loss_const: 10
secauth: off
rrp_mode: active
interface {
ringnumber: 0
bindnetaddr: 10.0.0.0
broadcast: yes
mcastport: 5405
ttl: 1
}
transport: udpu
}
nodelist {
node {
ring0_addr: 10.0.0.12
}
node {
ring0_addr: 10.0.0.13
}
}
logging {
fileline: off
to_stderr: no
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
two_node: 1
wait_for_all: 1
last_man_standing: 1
last_man_standing_window: 10000
}
每个节点都要编辑corosync.conf。
在两个节点上都启动corosync服务：
# systemctl enable corosync.service
# systemctl start corosync.service
在任一节点查看corosync服务的状态：
# corosync-cmapctl runtime.totem.pg.mrp.srp.members
runtime.totem.pg.mrp.srp.members.167772172.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772172.ip (str) = r(0) ip(10.0.0.12)
runtime.totem.pg.mrp.srp.members.167772172.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.167772172.status (str) = joined
runtime.totem.pg.mrp.srp.members.167772173.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.167772173.ip (str) = r(0) ip(10.0.0.13)
runtime.totem.pg.mrp.srp.members.167772173.join_count (u32) = 2
runtime.totem.pg.mrp.srp.members.167772173.status (str) = joined
167772172是member id，其IP是10.0.0.12，状态是joined；
167772173是member id，其IP是10.0.0.13，状态是joined；
corosync服务状态正确。
在两个节点上都启动pacemaker服务：
# systemctl enable pacemaker.service
# systemctl start pacemaker.service
查看服务启动状态：
# crm_mon
Last updated: Tue Dec 8 03:58:37 2015
Last change: Tue Dec 8 03:58:27 2015
Stack: corosync
Current DC: controller3 (167772173) - partition with quorum
Version: 1.1.12-a14efad
2 Nodes configured
0 Resources configured
Online: [ controller2 controller3 ]
pacemaker服务状态很好。如果状态不好，会出现“脑裂”现象。即在controller2和controller3分别运行crm_mon，看到的Current DC不是统一的，而是各自本身。出现此问题其中一种可能的原因是开启了防火墙。
在任一节点执行“crm configure”命令：
# crm configure property no-quorum-policy="ignore" pe-warn-series-max="1000" pe-input-series-max="1000" pe-error-series-max="1000" cluster-recheck-interval="5min"
默认的表决规则建议集群中的节点个数为奇数且不低于3。当集群只有2个节点，其中1个节点崩坏，由于不符合默认的表决规则，集群资源不发生转移，集群整体仍不可用。no-quorum-policy="ignore"可以解决此双节点的问题，但不要用于生产环境。换句话说，生产环境还是至少要3节点。
pe-warn-series-max、pe-input-series-max、pe-error-series-max代表日志深度。
cluster-recheck-interval是节点重新检查的频率。
禁用stonith：
# crm configure property stonith-enabled=false
stonith是一种能够接受指令断电的物理设备，测试环境无此设备，如果不关闭该选项，执行crm命令总是含其报错信息。
查看配置：
# crm configure show
corosync和pacemaker状态无误，就能创建VIP资源了。我的VIP是“10.0.0.10”：
# crm configure primitive myvip ocf:heartbeat:IPaddr2 params ip="10.0.0.10" cidr_netmask="24" op monitor interval="30s"
------------------------------------------------------------------------------------------------------
/etc/corosync/corosync.conf
文件中的token含义是：
The token value specifies the time, in milliseconds, during which the Corosync token is expected to be transmitted around the ring. When this timeout expires, the token is declared lost, and after token_retransmits_before_loss_const lost tokens, the non-responding processor (cluster node) is declared dead. In other words, token × token_retransmits_before_loss_const is the maximum time a node is allowed to not respond to cluster messages before being considered dead. The default for token is 1000 milliseconds (1 second), with 4 allowed retransmits. These defaults are intended to minimize failover times, but can cause frequent “false alarms” and unintended failovers in case of short network interruptions. The values used here are safer, albeit with slightly extended failover times.
节点通讯有两种方式，一种是多播，一种是单播。我在测试中采用的是单播，即指定了nodelist。
多播方式配置：
totem {
version: 2
# Time (in ms) to wait for a token (1)
token: 10000
# How many token retransmits before forming a new
# configuration
token_retransmits_before_loss_const: 10
# Turn off the virtual synchrony filter
vsftype: none
# Enable encryption (2)
secauth: on
# How many threads to use for encryption/decryption
threads: 0
# This specifies the redundant ring protocol, which may be
# none, active, or passive. (3)
rrp_mode: active
# The following is a two-ring multicast configuration. (4)
interface {
ringnumber: 0
bindnetaddr: 192.168.42.0
mcastaddr: 239.255.42.1
mcastport: 5405
}
interface {
ringnumber: 1
bindnetaddr: 10.0.42.0
mcastaddr: 239.255.42.2
mcastport: 5405
}
}
amf {
mode: disabled
}
service {
# Load the Pacemaker Cluster Resource Manager (5)
ver: 1
name: pacemaker
}
aisexec {
user: root
group: root
}
logging {
fileline: off
to_stderr: yes
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
tags: enter|leave|trace1|trace2|trace3|trace4|trace6
}}
1、token和token_retransmits_before_loss_const相乘的结果决定了集群的故障转移时间。token的单位是毫秒。如果某个节点超过$(token*token_retransmits_before_loss_const)未响应，则被认为节点死亡。
2、如果启用了secauth选项，则节点间的通讯使用128位密钥加密，密钥存储在/etc/corosync/authkey，可以使用corosync-keygen生成。
3、Corosync配置需要冗余网络（用到不只一个网络接口），必须采用RRR模式，
注意下述推荐的接口配置：
3.1、每个接口的配置必须有一个唯一的ringnumber，且起始数值为0。
3.2、bindnetaddr是你想要绑定的IP地址网段，
3.3、多组播地址mcastaddr不能在跨越集群的边界重用，即从来没有两个独立的集群使用了相同的多播组地址。多播组的地址必须遵循RFC 2365, “Administratively Scoped IP Multicast”
3.4、防火墙配置方面，Corosync仅需要UDP通信，使用mcastport（接收）和mcastport - 1（发送）。
4、pacemaker服务可以在corosync.conf中声明，也可以在/etc/corosync/service.d/pacemaker中声明。
注意：如果是在Ubuntu 14.04下的Corosync（version 2），需要注释服务stanza中启动pacemaker的命令。此外，要需要注意Corosync和Pacemaker的启动顺序，需要手动指定：
# update-rc.d pacemaker start 20 2 3 4 5 . stop 00 0 1 6 .
/etc/corosync/uidgid.d/pacemaker必须增加：
uidgid {
uid: hacluster
gid: haclient
}
5、注意所有节点上的corosync.conf和authkey都要保持同步。
6、service节点中，ver: 1表示corosync不自动启动pacemaker。如果要corosync自动启动pacemaker，设置ver为0。由于centos7没有/etc/rc.d/init.d/pacemaker脚本（pacemaker服务在centos7中可以用systemctl命令设置），故我的配置中没有这个小节。可手动创建/etc/rc.d/init.d/pacemaker，与下一篇关于haproxy的文章中创建/etc/rc.d/init.d/haproxy脚本的方法相同。
单播方式配置：
totem {
#...
interface {
ringnumber: 0
bindnetaddr: 192.168.42.0
broadcast: yes (1)
mcastport: 5405
}
interface {
ringnumber: 1
bindnetaddr: 10.0.42.0
broadcast: yes
mcastport: 5405
}
transport: udpu (2)
}
nodelist { (3)
node {
ring0_addr: 192.168.42.1
ring1_addr: 10.0.42.1
nodeid: 1
}
node {
ring0_addr: 192.168.42.2
ring1_addr: 10.0.42.2
nodeid: 2
}
}
1、如果broadcast参数被设置成yes，广播地址被用于通信。如果使用了broadcast参数，就不要使用mcastaddr参数。
2、transport指令控制传输的方法。如果要完全消除多播，指定udpu单播传输参数。这需要用nodelist指定成员列表。transport默认是udp，也可以设置成updu或iba。
3、nodelist中的每个节点，必须至少有一个ring0_addr字段，其它可能的选项有ring{X}_addr和nodeid，{X}是ring的序号，ring{X}_addr指定节点IP，nodeid是需要同时使用IPv4和IPv6时才指定。
votequorum方式配置
votequorum库是Corosync项目中的一部分。采用votequorum是为了避免脑裂发生，以及：
1、查询quorum状态；
2、获得quorum服务所知道的节点列表；
3、接收quorum状态改变的通知；
4、改变votes的数量，并分配域一个节点（Change the number of votes assigned to a node）
5、Change the number of expected votes for a cluster to be quorate
6、Connect an additional quorum device to allow small clusters remain quorate during node outages
votequorum库被创建于用来替换和取代qdisk（表决盘）。
采用了votequorum配置的corosync.com如下：
quorum {
provider: corosync_votequorum (1)
expected_votes: 7 (2)
wait_for_all: 1 (3)
last_man_standing: 1 (4)
last_man_standing_window: 10000 (5)
}
注意：
corosync_votequorum启动了votequorum。
expected_votes为7表示，7个节点，quorum为4。如果设置了nodelist参数，expected_votes无效。
wait_for_all值为1表示，当集群启动，集群quorum被挂起，直到所有节点在线并加入集群，这个参数是Corosync 2.0新增的。
last_man_standing为1表示，启用LMS特性。默认这个特性是关闭的，即值为0。这个参数开启后，当集群的处于表决边缘（如expected_votes=7，而当前online nodes=4），处于表决边缘状态超过last_man_standing_window参数指定的时间，则重新计算quorum，直到online nodes=2。如果想让online nodes能够等于1,必须启用auto_tie_breaker选项，生产环境不推荐。
last_man_standing_window单位为毫秒。在一个或多个主机从集群中丢失后，重新计算quorum。
