共计 5706 个字符，预计需要花费 15 分钟才能阅读完成。
一、简介
高可用集群，是指以减少服务中断（如因服务器宕机等引起的服务中断）时间为目的的服务器集群技术。简单的说，集群就是一组计算机，它们作为一个整体向用户提供一组网络资源。这些单个的计算机系统就是集群的节点。
高可用集群的出现是为了减少由计算机硬件和软件易错性所带来的损失。它通过保护用户的业务程序对外不间断提供的服务，把因软件 / 硬件 / 人为造成的故障对业务的影响降低到最小程度。如果某个节点失效，它的备援节点将在几秒钟的时间内接管它的职责。因此，对于用户而言，集群永远不会停机。高可用集群软件的主要作用就是实现故障检查和业务切换的自动化。
高可用集群框架图：
架构整体说明：
随着互联网技术的迅速发展很多大中小型公司已经离不开互联网办公及其提供服务，例如淘宝、美团等网站宕机几个小时损失是致命的，很多网站对其高可用性越来越强，这就意味着运维人员需做到从硬件和软件两方面保证服务器的平均无故障时间减小，才能提高其可用性。corosync 是一个集群管理套件的部分，它在传递信息的时候可以通过一个简单的配置来定义信息传递的方式和协议等，能实现资源间的高可用。目前，corosync 功能和特性已经非常完善了，所以 pacmaker 独立出来之后通常都将 pacmaker 和 corosync 结合来使用，corosync 并没有通用的资源管理器，因此要借助 pacmaker 来实现，pacemaker 是作为 corosync 的插件来使用的，所以只需要在 corosync 配置文件中启动 pacemaker 插件即可; 但是真正启动 corosync 并且配置它需要命令行接口进行调用，没配置 pcs 那么这里我们只能使用 crm 工具来对其进行资源的管理。
架构详细说明图：
corosync 集群常见的组合方式及配置接口：
heartbeat v1 + hasource
heartbeat v2 + crm
heartbeat v3 + pacemaker + crmsh(corosync v1 版本时没有投票系统，corosync v2 有投票系统，当系统发生网络分区、脑裂时则将会将所有的资源转移至可用的其他主机之上)
corosync v1 + pacemaker corosync v2 + pacemaker
cman +rgmanager corosync v1 + cman + pacemaker
CRM：集群资源管理
资源类型：
primitive: 基本资源，主资源，仅能运行一个节点
group: 组，将组成一个高可用服务所需要的所有资源集合在一起
clone: 克隆，同一资源科出现多份，可运行在多个节点
multi-state(master/slave): 多状态类型，是克隆资源的特殊表现，副本间可存在主从的关系
RA：资源代理
资源代理类别:
LSB: 位于 /etc/rc.d/init.d/*, 支持 start，stop，restart，reload，status，force-reload
注意：使用 LSB 资源类型的不能开机自动运行
OCF(open cluster framework)：/usr/lib/ocf/resource.d/provider/, 类似于 LSB 的脚本，但仅支持 start，stop，status，monitor，meta-data
STONITH: 调用 stonith 设备的功能，systemd:unite ifle,/usr/lib/systemd/system/
注意：必须设置 enable，设置为开机自动启动
资源约束方式：
位置约束：定义资源对节点的倾向性
排序约束：定义资源彼此能否运行在同一个节点的倾向性
顺序约束：多个资源启动顺序的依赖关系
HA 集群常用的工作模型：
A/P：两节点，active/passive，工作于主备模型
A/A：两节点，active/active，工作于主主模型
N-M：N>M，N 个节点，M 个服务，假设每个节点运行一个服务，活动节点数为 N，备用节点数为 N -M
在集群分裂 (split-brain) 时需要使用到资源隔离，有两种隔离级别：
STONITH：节点级别的隔离，通过断开一个节点的电源或者重新启动节点
fencing：资源级别的隔离，类似通过向交换机发出隔离信号，特意让数据无法通过此接口
当集群分裂，即分裂后的一个集群的法定票数小于总票数一半时采取对资源的控制策略
二、corosync 安装及其配置
安装：
要求：1. 基于主机名之间进行相互解析 2. 各个节点之间时间需同步
安装：yum -y install pacemaker (CentOS7)
corosync 配置详解：corosync 的主要配置分为 totem、logging、quorum、nodelist 配置段
totem {#定义各个节点之间的通信方式、加密与否，
version: 2 #指明 totem 的版本信息
cluster_name:myclusters #定义集群名称
crypto_cipher: aes128 #定义加密算法
crypto_hash: sha1 #定义 hash 算法
interface {#心跳及其事务传递接口
ringnumber: 0 #环接口号
bindnetaddr: 10.1.0.0 #绑定的网段
mcastaddr: 239.25.102.1 #多播地址
mcastport: 5405 #多播端口
ttl: 1 #生存时间，防止发生环路
}
}
logging {#日志模块
fileline: off
to_stderr: no #标准错误输出
to_logfile: yes
logfile: /var/log/cluster/corosync.log #日志存放路径
to_syslog: no
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {#投票系统
provider: corosync_votequorum #开启投票机制
}
nodelist {#节点列表
node {
ring0_addr: 10.1.10.65 #节点 IP 地址
nodeid: 1 #节点编号
}
node {
ring0_addr: 10.1.10.66 #节点列表
nodeid: 2 #节点编号
}
}
完成上诉配合后需生成密码：corosync-kegen -l
将上诉配置文件和秘钥文件拷贝至另一台 cluster 即可。
启动服务：
systemctl start corosync
systemctl start pacemaker
安装 crmsh 接口工具来管理集群资源及其配置：yum -y install crmsh-2.1.4-1.1.x86_64.rpm pssh-2.3.1-4.2.x86_64.rpm Python-pssh-2.3.1-4.2.x86_64.rpm
三、corosync+pacemaker+nfs 实现高可用案例
此实验需将另一台服务器启动 nfs 服务并挂载至两节点上配置同样的页面文件
node 167840321: node1.alren.com \ #默认设置，此在 corosync 配置文件中定义
attributes standby=on
node 167840322: node2.alren.com \
attributes standby=off
primitive webip IPaddr \ #定义 webip
params ip=10.1.10.80 \
meta target-role=Started
primitive webserver systemd:httpd #定义 webserver
primitive webstore Filesystem \ #定义 webstore
params device=”10.1.10.67:/www/html” directory=”/var/www/html” fstype=nfs \
op start timeout=60s interval=0 \ #附加选项为超时时间、时间间隔
op stop timeout=60s interval=0
group webservice webip webstore webserver #将 webip、webserver、webstore 加入到 webservice 组
location cli-prefer-webservice webservice role=Started inf: node1.alren.com
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=myclusters \
stonith-enabled=false \
symmetric-cluster=true
# vim: set filetype=pcmk:
实验测试图：
将节点一手动设置为 standby 模式，则资源会自动转移至节点二
上诉配置可用排列约束和顺序约束实现并且能实现节点之间的粘性和启动顺序
crm(live)configure# show
node 167840321: node1.alren.com \
attributes standby=on
node 167840322: node2.alren.com \
attributes standby=off
primitive webip IPaddr \
params ip=10.1.10.80 \
meta target-role=Started
primitive webserver systemd:httpd
primitive webstore Filesystem \
params device=”10.1.10.67:/www/html” directory=”/var/www/html” fstype=nfs \
op start timeout=60s interval=0 \
op stop timeout=60s interval=0
colocation webip_webserver_with_webstore inf: webip webserver webstore #设定排列约束
order webip_before_webstore_before_webserver Mandatory: webip webstore webserver #设定顺序约束，此时启动顺序为：webip,webstore,webserver
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=myclusters \
stonith-enabled=false \
symmetric-cluster=true \
default-resource-stickiness=200
定义资源监控配置如下：当 httpd 服务停止时，将自动重启 httpd, 如重启失败则将资源转移至可用的节点
crm(live)configure# show
node 167840321: node1.alren.com \
attributes standby=off
node 167840322: node2.alren.com \
attributes standby=on
primitive webip IPaddr \
params ip=10.1.10.80 \
meta target-role=Started
primitive webserver systemd:httpd \
op start timeout=15s interval=0 \ #定义资源启动间隔及其超时时间
op stop timeout=15s interval=0 \ #定义资源停止时间间隔及其超时时间
op monitor interval=15s timeout=15s #定义资源监控的时间间隔及其超时时间
primitive webstore Filesystem \
params device=”10.1.10.67:/www/html” directory=”/var/www/html” fstype=nfs \
op start timeout=60s interval=0 \
op stop timeout=60s interval=0
colocation webip_webserver_with_webstore inf: webstore webip webserver
order webip_before_webstore_before_webserver Mandatory: webip webstore webserver
property cib-bootstrap-options: \
have-watchdog=false \
dc-version=1.1.13-10.el7-44eb2dd \
cluster-infrastructure=corosync \
cluster-name=myclusters \
stonith-enabled=false \
symmetric-cluster=true \
default-resource-stickiness=200 \
no-quorum-policy=ignore \
last-lrm-refresh=1479180221
总结：综合上诉的配置总体感觉 corosync+pacemaker 的方式实现高可用比 lvs 略微复杂，corosync 同样可实现对 RS 的健康状态检测，可借助 ldirectory 实现自动生成 ipvs 规则。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-11/137149.htm
