corosync+pacemaker+crmsh实现3节点高可用web服务
高可用集群的方案主要作用就是利用多个节点主机提供相同的服务以实现缩短服务故障后可快速恢复服务，从而保证服务的持久服务。高可用集群架构分三层：
一、Messaing/Infrastructure:称为基础设施层或消息层。我们称为message layer层
二、ResourceAllocation：称为资源非配层。我们称为clusterresource manager，资源管理层，简称CRM
三、Resource ：称为资源层。也叫作resource agent，资源代理层。
message layer层：
通过corosync或openAIS来传递各node之间的心跳信息和事物信息。
CRM层：
DesignatedCoordinator，简称DC，是整个集群中用来决策事物的节点叫做DC。而DC是通过policy engine组件来完成决策事物的过程的。决策过程传递信息都要通过CRM由corosync层向其他节点来进行传递Local ResourceManager，简称LRM，本地资源管理层，是CRM用来处理相应的resource agent的统一接口。ClusterInformation Base,简称cib，是整个集群的信息资源库，存放整个集群的配置信息。所有的集群配置，（不论通过pcs在哪个node上进行配置），都会通过message layer（即corosync）层连接DC节点，然后配置生效的，之后DC将配置信息在通过messagelayer层同步给其他节点。
resouce agent层：
简称RA。ra实际上可以认为是各种服务的启动脚本。因此RA有不同风格的类型。一般分为5类。 1、service（heartbeat legacy）: /etc/ha.d/haresources.d/目录下的脚本,成为通用目的的服务 2、LSB: 如/etc/rc.d/init.d/目录下的脚本 3、OCF：open clusterframework 开放集群框架 provider：脚本提供者有: heartbeat pacemaker linbit 4、STONITH:专用于stonith设备的服务脚本ra 5、systemd：如centos7上/etc/systemd/system/multi-user.wants
实例：使用corosync+pacemaker+crmsh实现httpd服务的高可用。
corosync+pacemaker 布置3节点高可用集群：messaging layer基于多播传递，基于认证传递
（corosync默认的投票系统需要三个节点才能启动）
第一步：在三个主机节点上yum安装corosync+pacemaker，实现httpd服务的高可用，其中httpd服务采用nfs共享存储。
主机1：lpw1 ：172.16.249.209 //集群node1,httpd-server,ansible主控机
主机2：lpw2 ：172.16.249.73 //集群node2,httpd-server
主机3：lpw3 ：172.16.249.208 //集群node3,httpd-server
主机4：lpw4 ：172.16.249.236 //nfs-server,
要在corosync的host文件中设置认证的功能，需要为每一个node提供相同的秘钥；使用corosync-keygen自动生成秘钥，默认会放在/etc/corosync/authkey ,也可以使用-k选项指定秘钥存放位置。
# corosync-keygen -l
然后将此authkey文件复制到每一个node的/etc/corosync/目录下
# scp -p ./authkeyroot@172.16.249.73:/etc/corosync/
# scp -p ./authkeyroot@172.16.249.208:/etc/corosync/
在第一个主机节点（lpw1）上修改corosync的配置
# cat corosync.conf |grep -v '^[[:space:]]*#'
totem {
version:2
crypto_cipher:aes128
crypto_hash:sha1
secauth:on
interface{
ringnumber: 0
bindnetaddr: 172.16.0.0
mcastaddr: 239.254.1.1
mcastport: 5405
ttl: 1
}
}
#此处如果指定使用udpu协议，上面的配置不能使用mcastaddr，而要使用unicast或者broadcast，udpu协议是传播单播的，但是也可基于广播传递，但是不能是组播
nodelist {
node{
ring0_addr:172.16.249.209
nodeid:1
}
node{
ring0_addr:172.16.249.73
nodieid:2
}
node{
ring0_addr:172.16.249.208
nodeid:3
}
}
logging {
fileline:off
to_stderr:no
to_logfile:yes
logfile:/var/log/cluster/corosync.log
to_syslog:no
debug:off
timestamp:off
logger_subsys{
subsys: QUORUM
debug: off
}
}
quorum {
provider:corosync_votequorum
}
将此配置文件复制到其他两个主机节点
# scp -p./corosync.conf root@172.16.249.73:/etc/corosync/
# scp -p ./corosync.confroot@172.16.249.208:/etc/corosync/
在各个节点启动corosynce服务
# systemctl startcorosync.service
或者使用ansible启动
# ansible clu -mservice -a 'name=corosync.service state=started'
可以在各节点验证：
可以使用corosync-cfgtool命令查看当前节点的信息
corosync-cfgtool [-i <interface ip>]-s] [-r] [-H] [-k] [-a]
-s ：显示当前节点的信息
-a ：显示指定节点的ip地址
-k ：根据node id来杀死某个节点
-R ：重载corosync.conf配置文件
-H ：关闭当前节点的corosync服务
#corosync-cmapctl
message layer层准备完毕
启动pacemaker服务
# vim/etc/sysconfig/pacemaker //此文件是pacemaker的环境配置文件，默认情况下不需要设置。
PCMK_logfile=/var/log/pacemaker.log
可以在各个节点上使用systemctlstart pacemaker.service启动pacemaker服务，这里使用ansible启动
# ansible clu -mservice -a 'name=pacemaker.service state=started'
查看pacemaker的启动情况
使用crm_mon命令可以监视pacemaker各节点的当前信息，该工具是由pacemaker自带的。
#crm_mon
至此messagelayer层和CRM层已经准备完毕。
# mkdir -pv /www/htdocs
mkdir: 已创建目录 "/www"
mkdir: 已创建目录 "/www/htdocs"
# vim /www/htdocs/index.html
# vim /etc/exports
/www/htdocs/ 172.16.0.0/16(rw)
启动rpcbind和nfs服务
# service rpcbind start
正在启动 rpcbind： [确定]
# service nfs start
启动 NFS 服务： [确定]
启动 NFS mountd： [确定]
启动 NFS 守护进程： [确定]
#
然后设置nfs开机启动：
# chkconfig nfs on
确保三个几点主机都能使用挂在nfs-server的目录
在每个节点都测试挂载并能访问http服务
节点1：
# mount -t nfs172.16.249.236:/www/htdocs /var/www/pma
# systemctl starthttpd.service
# curl http://172.16.249.209
this is cluster heml
然后关闭httpd服务，但要保证开机启动
# umount /var/www/pma
# systemctl stophttpd.service
# systemctl enablehttpd.service
节点2：
# mount -t nfs172.16.249.236:/www/htdocs /var/www/pma
# curl http://172.16.249.73
this is cluster heml
#
然后关闭httpd服务，但要保证开机启动
# umount /var/www/pma
# systemctl stophttpd.service
# systemctl enablehttpd.service
节点3：
# mount -t nfs172.16.249.236:/www/htdocs /var/www/pma
# systemctl starthttpd.service
# curl http://172.16.249.208
this is cluster heml
然后关闭httpd服务，但要保证开机启动
#umount /var/www/pma
# systemctl stop httpd.service
# systemctl enablehttpd.service
接下来配置资源：
此次配置根据资源约束来定义资源对各节点的依赖。
使用crm的configur命令配置
crm(live)# configure
crm(live)configure# show
node 1: lpw1.com
node 2: lpw2.com
node 3: lpw3.com
property cib-bootstrap-options: \
have-watchdog=false\
dc-version=1.1.12-a14efad\
cluster-infrastructure=corosync
配置集群属性：
确保关闭stonith功能
crm(live)# configure propertystonith-enabled=false
crm(live)# configure verify
crm(live)# configure commit
查看
在其他节点做校验
# crm_verify -L -V
# crm_verify -L -V
接下来配置资源
定义原始资源：
crm(live)configure# primitive webipocf:heartbeat:IPaddr2 params ip="172.16.249.100" op monitorinterval=30s timeout=30s
crm(live)configure# verify
crm(live)configure# primitive webserbersystemd:httpd op monitor interval=30s timeout=30s
crm(live)configure# verify
crm(live)configure# primitive webstoreocf:heartbeat:Filesystem params device="172.16.249.236:/www/htdocs"directory="/var/www/pma" fstype="nfs" op start timeout=60sop stop timeout=60s op monitor interval=20s timeout=40s
crm(live)configure# verify
定义约束
定义排列约束：crm(live)configure#colocation webserver_with_webstore_and_webip inf: webserver ( webip webstore )crm(live)configure#verify定义顺序约束：crm(live)configure#order webstore_after_webip Mandatory: webip webstorecrm(live)configure#verifycrm(live)configure#order webserver_after_webstore Mandatory: webstore webservercrm(live)configure#verifycrm(live)configure#commit
然后开始测试：
当前资源在node2上
停止node2，查看资源转移情况
crm(live)# node standby lpw2.com
crm(live)# status
此时资源转移到node3上
在另外的主机上测试httpd服务是否可用
# curlhttp://172.16.249.100
lpw 3 this is cluster heml
#
高可用集群配置如下：
crm(live)# configure
crm(live)configure# show
node 1: lpw1.com \
attributesstandby=off
node 2: lpw2.com \
attributesstandby=on
node 3: lpw3.com \
attributesstandby=on
primitive webip IPaddr \
paramsip=172.16.249.100 \
opmonitor interval=20s timeout=20s \
metatarget-role=Started
primitive webserver systemd:httpd \
opmonitor interval=20s timeout=20s \
metatarget-role=Started
primitive webstore Filesystem \
paramsdevice="172.16.249.236:/www/htdocs"directory="/var/www/html" fstype=nfs \
opstart timeout=60s interval=0 \
opstop timeout=60s interval=0 \
opmonitor timeout=40s interval=20s
colocationwebserver_with_webip_and_webstore inf: webserver ( webip webstore )
order webserver_after_webstore Mandatory:webstore webserver
order webstore_after_webip Mandatory: webipwebstore
property cib-bootstrap-options: \
stonith-enabled=false\
have-watchdog=false\
dc-version=1.1.12-a14efad\
cluster-infrastructure=corosync
特别注意：使用共享存储的nfs-server作为资源使用时，必须保证nfs-server共享出来的目录本身有可读或写权限，同时在定义/etc/exports文件时也要给响应的权限，这里一个难点就是nfs-server默认情况会对root用户实行权限压缩，而本实验环境是使用root身份来做的，因此在定义/etc/export文件共享目录的权限时要加上no_root_squash，
可以定义位置约束来指明资源对某个节点的粘性：
crm(live)configure# locationwebserver_pref_node1 webip 100: lpw1.com
显示当前集群的资源
crm(live)# status
现在资源在node1上，然后手动下线当前node1节点，然后在查看资源已经转移
crm(live)# node standby
crm(live)# status
之后恢复当前node1在线，查看资源已经回到node1节点
crm(live)# node online
crm(live)# status
下面介绍几种高可用集群的解决方案：
高可用集群可用版本：
1、heartbeat v1 //单独的v1版，因为它本身就是完整的，有投票系统
2、heartbeat v2 //单独的v2版，也是完整的体系
3、heartbeat v3 + pacemaker //v3版的hearbeat中投票系统pacemaker被独立出来成文单独项目，因此两种必须同时使用，heartbeat v3不常用。
4、corosync + pacemaker //centos6使用的corosync v1版，corosync v2版需要自己编译，v1版的corosync没有投票系统，
5、cman + rgmanager//cman的投票系统很强大，但是rgmanger功能有点弱
6、corosync + cman + pacemaker //corosync提供message layer层，cman提供投票系统，pacemaker提供CRM层
注意：centos6上的heartbeat v1和v2版没有rpm包
以上是centos6上可以实现的方案
7、corosync + pacemaker // centos7 可直接使用corosync v2
但是生产环境中实现高可用集群的最多的keepalived解决方案
页:
[1]