【OpenStack云平台】Packmaker 集群

个人名片：
因为云计算成为了监控工程师‍
个人博客：念舒_C.ying
CSDN主页️：念舒_C.ying

Packmaker 集群

Pacemaker 通过资源代理程序（默认提供了 70 多种）和应用程序进行交互，在 Pacemaker集群中应用第三方资源代理程序也非常容易。OpenStack 高可用配置中使用了 Pacemaker 自带的资源代理程序（如 MySQL 数据库服务、虚拟 IP 地址等）、已有的第三方资源代理程序（如 RabbitMQ 服务）以及 OpenStack 资源代理程序（如 OpenStack 身份认证服务、磁盘镜

像服务）。

1.1 安装软件包

Pacemaker 中的节点服务器之间必须通过 Corosync 建立集群通信，需要安装以下软件包(以及它们的依赖软件包，通常软件包管理器将自动所有依赖软件包)：

pacemaker （说明：crm 命令行工具需要另外单独下载。）
crmsh
corosync
cluster-glue
fence-agents （说明：只针对 Fedora 发行版；其它 Linux 发行版都使用 cluster-glue 软件包中的fence 资源代理)
resource-agents

1.2 Corosync 基本配置

corosync 软件包安装之后，首先创建它的配置文件：/etc/corosync/corosync.conf 。大多数 Linux 发行版都会附带一份配置示例：corosync.conf.example，大致内容如下：
Corosync 配置文件（corosync.conf）.

totem {

 version: 2

 # Time (in ms) to wait for a token

 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

 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.

 rrp_mode: active

 # The following is a two-ring multicast configuration.

 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

 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

 }}

token 是时间，单位为毫秒，在该配置项指定的时间内， Corosync 令牌应该完成在回环网络中的传输。如果令牌传输超时就会被丢弃，而一台节点服务器连续出现token_retransmits_before_loss_const 令牌失效，将会被认为是无效节点。也就是说，一台节点服务器最长的无响应时间不能超对 token ×token_retransmits_before_loss_const 的乘积（单位毫秒），否则会被认为是无效节点。token的默认值是 1000 （即 1 秒），同时默认的重试次数为 4 。默认配置的目标是尽量缩短故障恢复时间，但是可能出现较多的“false alarm” 提醒，发生短期的网络故障时也有可能导致失效切换。本处示例中的配置参数更安全一些，但是失效切换的时间会长一些。
当启用 secauth 时，Corosync 节点之间通信时会使用一个 128 位的密钥进行双向认证。密钥存放在 /etc/corosync/authkey 文件中，可以通过 corosync-keygen 命令生成。启用 secauth 后，集群通信数据也会进行加密。
Cororsync 可以使用冗余的心跳网络（即多个 interface 配置），但是必须同时将 RRP 模式设置为除 none之外的其它值，建议使用 active 模式。
在推荐的网络接口配置中有几件事需要注意：

所有心跳网络的 ringnumber 配置不能重复，最小值为 0 。
bindnetaddr 是心跳网卡 IP 地址对应的网络地址。示例中使用了两个子网掩码为 /24的 IPv4 网段。
Multicast groups (mcastaddr) must not be reused across cluster boundaries. In other words, no two distinct clusters should ever use the same multicast group. Be sure to select multicast addresses compliant with RFC 2365, “Administratively Scoped IP Multicast”.
Corosync 通信使用 UDP 协议，端口为 mcastport （接收数据）和 mcastport - 1 （发送数据）。配置防火墙时需要打开这两个端口。

pacemaker 对应的 service 配置段，可以放在 corosync.conf ，也可以单独作为一个配置文件 /etc/corosync/service.d/pacemaker 。

注意
如果是在 Ubuntu 14.04 系统中运行 Corosync 2，那么应该将 stanza 对应的
service 配置段删除或者全部注释，以确保 Pacemaker 可以启动。

1.3 启动Corosync

Corosync 启动方法和普通的系统服务没有区别，根据 Linux 发行版的不同，可能是 LSB init脚本、upstart 任务、systemd 服务。不过习惯上，都会统一使用 corosync 这一名称：

/etc/init.d/corosync start （LSB）
service corosync start （LSB，另一种方法）
start corosync （upstart）
systemctl start corosync （systemd）
使用以下两个工具检查 Corosync 连接状态。
corosync-cfgtool ，执行时加上 -s 参数，可以获取整个集群通信的健康情况：

# corosync-cfgtool -s

 Printing ring status.

Local node ID 435324542

RING ID 0

 id = 192.168.42.82

 status = ring 0 active with no faults

RING ID 1

 id = 10.0.42.100

 status = ring 1 active with no faults

corosync-objctl 命令可以列出 Corosync 集群的成员节点列表：

# corosync-objctl runtime.totem.pg.mrp.srp.members

 runtime.totem.pg.mrp.srp.435324542.ip=r(0) ip(192.168.42.82) r(1) ip(10.0.42.100)

runtime.totem.pg.mrp.srp.435324542.join_count=1

runtime.totem.pg.mrp.srp.435324542.status=joined

runtime.totem.pg.mrp.srp.983895584.ip=r(0) ip(192.168.42.87) r(1) ip(10.0.42.254)

runtime.totem.pg.mrp.srp.983895584.join_count=1

runtime.totem.pg.mrp.srp.983895584.status=joined

status=joined标示着每一个集群节点成员。

1.4 启动 Pacemaker

Corosync 服务启动之后，一旦各节点正常建立集群通信，就可启动 pacemakerd（ Pacemaker 主进程）：

/etc/init.d/pacemaker start （LSB）
service pacemaker start （LSB，另一种方法）
start pacemaker （upstart）
systemctl start pacemaker （systemd）

Pacemaker 服务启动之后，会自动建立一份空白的集群配置，不包含任何资源。可以通过crm_mon 工具查看 Packemaker 集群的状态：

============

Last updated: Sun Oct 7 21:07:52 2012

Last change: Sun Oct 7 20:46:00 2012 via cibadmin on node2

Stack: openais

Current DC: node2 - partition with quorum

Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c

2 Nodes configured, 2 expected votes

0 Resources configured.

============

Online: [ node2 node1 ]

1.5 设置集群基本属性

Pacemaker 启动之后，建议首先对集群基本属性进行配置。配置时，首先执行 crm 命令，然后输入 configure 进入配置菜单。也可以执行 crm configure 命令直接进入 Pacemaker 配置菜单。
然后，设置下列属性：

 property no-quorum-policy="ignore"

 pe-warn-series-max="1000"

 pe-input-series-max="1000"

 pe-error-series-max="1000"

 cluster-recheck-interval="5min"

对于 2 个节点的 Pacemaker 集群，集群属性 no-quorupolicy="ignore"是必须配置的，因为：如果强制集群满足合法节点数要求，当其中一个节点失效时，剩下的一个节点无法达到集群多数节点在线的要求，从而不能接管原来运行在失效节点上的集群资源。这种情况下，解决方法只能是忽略集群合法节点数要求。但是这一属性只能用于2 个节点的集群，对于 3 个节点及以上的集群来说，是不应该配置该属性的。需要注意的是，2 个节点的集群配置该属性之后，会出现脑裂（ split-brain）的风险，这是因为当 2 个节点都在线但是互相无法通信时，2个节点都认为对方出现故障，从而尝试接管对方的集群资源。因此建议布署 3 个节点及以上的集群。
将 pe-warn-series-max、 pe-input-series-max 以及 pe-error-series-max 设置为 1000，是为了让
Pacemaker 保存更多 Policy Engine 的处理输入、错误以及警告信息。这些历史记录对排除集群故障会有很大帮忙。
Pacemaker 处理集群状况时使用事件驱动机制。但是某些 Pacemaker 操作只会在固定的时间间隔触发。该时间间隔可以配置，cluster-recheck-interval，默认值是 15 分钟。针对特定的集群，可以适当缩短这一间隔，如 5 分钟或者 3 分钟。

作完这些改变后，可以提交更新配置。

期待下次的分享，别忘了三连支持博主呀~
我是 念舒_C.ying ，期待你的关注~

附专栏链接
【云原生 · Kubernetes】部署 kube-proxy 组件
 【云原生 · Kubernetes】部署高可用kube-scheduler集群
 【云原生 · Kubernetes】部署高可用 kube-controller-manager 集群
 【云原生 · Kubernetes】runtime组件
 【云原生 · Kubernetes】apiserver高可用