corosync+pacemaker安装并通过crmsh配置
一、简单介绍：
corosync是高可用集群的底层信息传递层， 主要负责与上层交互并完成心跳和上层所要发送的事务信息。还有，为了防止发生Split brain以后所带来的问题，还有法定票数（quorum）这一概念。这里所要安装的是1.4版本的，负责集群票数的统计，每个节点一张票，到了2.*版本以后有了投票的功能，可以设定某节点可以持有多少张票。 最后完成票数的统计并交于CRM层来决策节点集群是否还要运行。 更多概念朋友们自己去查吧， 我自己对这方面了解的也少。而且我打字真的很慢。
pacemaker是高可用集群中的CRM（Cluster Resource Manager)资源管理层，它是一个服务，可以做为一个单独的服务启动， 不过在我们使用corosync-1.4的版本中，可以设置为corosync来启动pacemaker.
pacemaker的配置接口可以在任意节点上安装crmsh或者pcs还有一些GUI界面的软件来完成。crmsh好像在RrdHat6.4以后都不是官方自带的了，官方的是pcs。 而crmsh好像是OpenSUSE所开发的。
两个节点在集群中是一种很特殊集群。在正常的情况下，两个节点集群工作正常，一个完整的集群也就拥有了两张票。 但在发生Split brain以后，每个集群只有持有大于半数的票才可以继续工作。而两个节点在发生Split brain以后每个集群都只有1张票，所以都不再工作。 解决方式：要么有仲裁设备（1、ping节点，2、仲裁盘），要么就是大于两个节点并且是奇数节点。或者在我们这种实验环境中可以在集群中定义参数，修改在发生Split brain以后所作的动作，如 ignore。
可以用这个命令：crm configure property no-quorum-policy=ignore
说明：文中所出现的网址只是做实验时随便起的，跟互联网上的域名无关。
二、环境：
两个节点，都是CentOS6.5-x86_64
三、安装：
在所有节点上安装。直接yum 安装 corosync和pacemaker即可。有可能要用到epel源。
yum install corosync pacemaker -y
crmsh 依赖于pssh. 下载地址：crmsh,pssh都在这里。 epel源中也有pssh
http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/
yum install crmsh-2.1-1.6.x86_64.rpm pssh-2.3.1-2.el6.x86_64.rpm
所有节点的主机都必须要能够解析所有节点的IP，并且解析名称要跟节点的主机名称一致。
为了防止DNS单点故障引起不能解析， 最好的作法就是在各个节点的/etc/hosts文件中添加各个节点的解析记录，并发到所有节点。
为了传配置文件方便，最好是所有节点都ssh密钥登录。可以在一个节点生成私钥和公钥，并对自己完成用密钥登录，这样本节点就有了私钥和公钥还有authorized_keys文件。再把私钥和公钥还有authorized_keys发给所有节点。 这样就完成了所有节点的互信，以后传东西也方便点。 这只是我们的实验环境， 在线上就不知道可否了， 毕竟越方便可能就越不安全。
集群各节点的时间一定要同步，可以在别的电脑上装个ntp服务，来让各个节点同步时间。
要查看网卡是否开启了多播功能。ip link show 看是否有MLTICAST。或者是ifconfig看是否有MLTICAST相关的字眼。
corosync配置文件: /etc/corosync/corosync.conf
cp corosync.conf.example corosync.conf
把注释信息去掉以后就下面这些了：
compatibility: whitetank #是否要兼容0.8以前的。 totem { #totem是corosync之间传输信息的协议 version: 2 #totem协议版本号 secauth: off #是否打开安全认证，这里我们要打开，on就可以。 threads: 0 #认证线程数，0表示默认 interface { ringnumber: 0 #环号吗，为了防止本机网卡发出的心跳 #被另一网卡接受到，所作的识别。 bindnetaddr: 192.168.1.0 #绑定到哪个网络， #工作在哪个网络。 mcastaddr: 239.255.1.1 #组播地址。 mcastport: 5405 #组播端口。 ttl: 1 #ttl，转发次数。1表示只本机 #发送一次，其它设备不会转发。 } } logging { fileline: off to_stderr: no #是否发送到标准错误输出 to_logfile: yes #是否要保存到日志文件。 logfile: /var/log/cluster/corosync.log #日志文件 to_syslog: yes #是否要发给rsyslog来管理日志。 #这两个日志输出只一个就好。 debug: off #是否开启调试 timestamp: on #是否打开日志的时间戳。 logger_subsys { subsys: AMF debug: off } }然后再添加以下参数：
} service { var: 0 name: pacemaker #表示启动pacemaker } aisexec { #表示以哪个身份去启动CRM user: root group: root }最后我这里的配置去掉注释以后是这个样子的：
compatibility: whitetank totem { version: 2 secauth: on threads: 0 interface { ringnumber: 0 bindnetaddr: 172.16.0.0 #bindnetaddr: 192.168.1.0 mcastaddr: 239.255.100.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: AMF debug: off } } service { var: 0 name: pacemaker } aisexec { user: root group: root } ~ok，配置文件搞定， 因为我们上面的secauth: on 所以执行命令 corosync-keygen 来生成authkey文件，
[root@node1 ~]# corosync-keygen Corosync Cluster Engine Authentication key generator. Gathering 1024 bits for key from /dev/random. Press keys on your keyboard to generate entropy. Press keys on your keyboard to generate entropy (bits = 208). Press keys on your keyboard to generate entropy (bits = 272). Press keys on your keyboard to generate entropy (bits = 336). Press keys on your keyboard to generate entropy (bits = 400).
哇，这里要用到一些随机数，而我这里随机数不够用，要等一会儿了。
终于好了， 然后我们把配置文件和刚才所生成的authkey文件发给另一个节点。
scp -p /etc/corosync/authkey node2.star.com:/etc/corosync/ scp -p /etc/corosync/corosync.conf node2.star.com:/etc/corosync/
完成安装。
四、启动corosync。
[root@node1 ~]# service corosync start Starting Corosync Cluster Engine (corosync): [ OK ]
确认是否启动可以通过查看日志文件：
[root@node1 ~]# grep -e "Corosync Cluster Engine" -e "configuration file" /var/log/cluster/corosync.log #查看corosync是否启动 Jun 17 13:00:21 corosync [MAIN ] Corosync Cluster Engine ('1.4.7'): started and ready to provide service. #corosync 集群引擎启动 Jun 17 13:00:21 corosync [MAIN ] Successfully read main configuration file '/etc/corosync/corosync.conf'. #并且成功读取配置文件确认是否正常发出节点通知
[root@node1 ~]# grep TOTEM /var/log/cluster/corosync.log #totem协议 Jun 17 13:00:21 corosync [TOTEM ] Initializing transport (UDP/IP Multicast). Jun 17 13:00:21 corosync [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0). Jun 17 13:00:21 corosync [TOTEM ] The network interface [172.16.5.11] is now up. Jun 17 13:00:21 corosync [TOTEM ] A processor joined or left the membership and a new membership was formed.
查看是否有错误发生
[root@node1 ~]# grep ERROR: /var/log/cluster/corosync.log Jun 17 13:00:21 corosync [pcmk ] ERROR: process_ais_conf: You have configured a cluster using the Pacemaker plugin for Corosync. The plugin is not supported in this environment and will be removed very soon. Jun 17 13:00:21 corosync [pcmk ] ERROR: process_ais_conf: Please see Chapter 8 of 'Clusters from Scratch' (http://www.clusterlabs.org/doc) for details on using Pacemaker with CMAN
以上错误只是在提示：pacemaker很快将不再作为corosync的插件启动， 只是说明以后的版件将是单独的服务启动。跟我们这里没有关系。 而第二个错误也只是说可以用CMAN来代替corosync，跟我们这里也没有关系。
查看pacemaker是否启动
[root@node1 ~]# grep pcmk_startup /var/log/cluster/corosync.log Jun 17 13:00:21 corosync [pcmk ] info: pcmk_startup: CRM: Initialized Jun 17 13:00:21 corosync [pcmk ] Logging: Initialized pcmk_startup Jun 17 13:00:21 corosync [pcmk ] info: pcmk_startup: Maximum core file size is: 18446744073709551615 Jun 17 13:00:21 corosync [pcmk ] info: pcmk_startup: Service: 9 Jun 17 13:00:21 corosync [pcmk ] info: pcmk_startup: Local hostname: node1.star.com
如果一切正常就可以启动第二个节点了，在当前节点用ssh来启动其它的节点可以在日志里看到更多的一些信息。 这个也无所谓了， 只要查看日志发现没问题。 再用crm查看一下节点状态。
五、crm配置pacemaker。
crmsh安装完成以后的执行文件名称就是crm. crm可以直接在shell界面命令行执行，也可以在交互式模式下执行，我也是初学者，当然要在交互式下啦。
直接键入命令就可以进入下一级菜单，cd .. 或 up，就可以返回上级菜单。
资源不可以自动启动，要由集群来调度启动。
说明：以下节点名称只是随便起的，跟互联网上的域名无关。
在主菜单下执行status用来查看集群状态，上面我们可以看到集群各节点和资源的大概信息还有DC节点。
可以用ls来查看此菜单的各个命令，也可以用help来详细查看。 ls 和 help自身也是其中的命令。
也可以help一个命令，来查看下一级的命令。
简单介绍下在主菜单中常用到的各个命令的信息吧：
ra 里面可以查看资源代理信息，resource agent的简写。
configure 主要用到的就这个了， 定义资源。
node 管理节点，如，删除一个不再上线，不再使用的节点。
resource 管理资源。
在configure中可以用verify来校验当前的配置。
出问题啦，什么也没有配置就出问题了。 没有STONITH资源被定义， 可以在stonith-enabled中关闭STONITH, 集群中的共享数据需要STONITH来保证数据的完整性。
STONITH主要是用来把失败的节点给kill掉（如：停止供电）。 防止它再使用资源，或者资源终止不掉，而带来的各种恐怖的后果。
当然了，我们的实验可没有STONITH设备。 所以就要关闭STONITH设备。
在configure下用property命令来配置， 可以用双TAB来查看参数的，单TAB来补全命令。
verify 用来校验当前配置， commit用来提交。 注意一点：命令执行完成以后 就会写入xml文档，verify就是用来校验这个文档，而commit是用来生效的。 定义这些参数错误了，可以重新定义即可， 如果在定义资源的时候出现了问题，就要删除资源，然后再重新定义。
我们定义一个资源尝试一下：就来定义web服务吧， 首先是要定义vip(Virtual IP).
定义一个资源可以通过primitive来定义。 可以help一下这个命令看看格式，关键是还有很多例子。
定义资源要用到资源代理，CRM其中的一个组件LRM通过资源代理来管理资源。
我们主要用到两种： OCF 和 LSB的。 ocf就是软件自带的，lsb就是我们在/etc/init.d/下面的服务脚本啦。 当然不是所有的服务脚本都可以使用的，比如要可以识别 start stop status 而且会返回 stopped running才行。 LRM就是通过执行那些资源代理来启动、停止还有监控资源的。
而我们定义资源的时候要定义的一些值就是要让LRM运行资源代理的时候所要用到的参数。
好啦，废话说太多了。试一下就知道了。
webip 是给这个资源起的名称， 后面的就是资源代理， params关键字， ip= 就是参数了。
so easy否？show来显示所定的资源或一些参数，也可以通过edit来直接打开xml文件查看。
上面所定义的ip就是给资源代理的参数啦。而这些参数都是可以在主菜单的ra里面查看的。
classes 可以显示有哪些类的资源代理。
lsb和ocf上面介绍到了。 其它的那两种这里用不到，可以用info或meta来查看详细信息。用list来查看所有的或是各个类的资源代理。
上面我们说的lsb、ocf就是class了，而heartbeat、pacemaker就是provider（供应商）了。
太多了，这里就不帖了， 第一列的 ip*,nic等等都是参数，有*号的是必须的。
我们来定义第二个资源， 已经有ip了，再有就是httpd了。
LSB类型的资源代理没有任何的参数。 直接像这样加上就可以。 我们返回主菜单查看一下现在的状态。
嗯，ip在node1上， httpd在node2上。这也不能正常访问啊。
注意：资源不能在集群调度之前就已经启动，要由集群来调度启动。
如：上边的ip，节点上面不能本来就已经有这个ip了。 httpd也不能本来就是启动着的。
要在系统上查看Ip是否生效，要用 ip 命令，ifconfig是看不到的，除非在定义Ip的时候有参数Iflabel。
[root@node1 ~]# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:0c:29:4c:12:89 brd ff:ff:ff:ff:ff:ff inet 172.16.5.11/16 brd 172.16.255.255 scope global eth0 inet 172.16.5.5/16 brd 172.16.255.255 scope global secondary eth0 #在这里 inet6 fe80::20c:29ff:fe4c:1289/64 scope link tentative dadfailed valid_lft forever preferred_lft forever
可以用两种方式来让资源在同一个节点上启动。 1，资源组。 2，colocation（排列约束）
我们先试试定义一个colocation看看。
Usage: #role我们暂时用不到 colocation <id> <score>: <rsc>[:<role>] <with-rsc>[:<role>] colocation 约束名称 分数： 资源 资源
注意：在分数后面的冒号后面可是有一个空格的。
现在两个资源都在node1上了。 分数可以用数字来表示也可以用inf来表示无穷大。还有-inf负无穷大。
那么有时候我们可能要让ip先启动，然后才是httpd， 这样有顺序的去启动资源。 可以用order约束。
这里来约束的值可以用score也可以用kind。 kind有Manadatory表示强制。 后面的两个看来可能是看情况的意思。 也可以用分数来表示。 强制的力度好像更强， 我们就用Manadatory吧。
不知道score中的inf跟kind中的Manadatory一样不。不过都是可以正常生效的，可能力度不一样吧。
上面一开始写错了，所以下面要用delete把所定义的资源删除了， 在edit中直接删除也可以。
然后还有位置约束location。我这个现在在node1上面，如果我希望它们在node2上面。
Usage:
location <id> rsc [role=<role>] {node_pref|rules}
rsc :: /<rsc-pattern>/
| { resource_sets }
| <rsc>
node_pref :: <score>: <node>
我们只定义个简单位置约束， 所以用简单的就行啦。
location <id> rsc <score>: <node>
webip与webserver已经约束在一起了， 所以只定义一个资源到别的位置就可以了。
分数是一个度量值，如果在node1上的约束数值是大于50的，那么就回去了。 而且以现在这种状态，node2离线了以后，资源都转移到node1上，但是node2上线以后，资源就又会转移回来。
每一次转移都代表着业条中断。 so， 我们可以定义资源粘性。
所谓资源粘性就是指： 资源到一个节点以后本身就拥有在这个节点的倾向值。 就好像资源本身就有粘性，到哪一个节点就粘在哪个节点。
资源粘性我们可以定义成资源默认值，让资源生来就拥有粘性，而不至于因为很低分数的位置约束就让资源转移。
上面我们所定义的webip和webserver因为排列约束在一起，它们在一起的数值是无穷大的。
而每个资源的粘性是50，它们两个就是100，没有超过100的位置约束值，是不会转移的。
而如果它们每个的排列约束只有50，两个资源分别有一个100的不同位置的约束值， 它们也就分开了。
这就是这些分数的意义，集群计算这些分数来决定资源的位置。
上面定义完成以后，node2再次上线以后，资源还会停在当前节点。而当当前节点挂了的话，才会转移到一个位置约束高的节点node2。而不会转移到一个配置差，运行慢的节点。
当然了我们这里只有两个节点，再转也转不到哪去。
模拟节点离线：可以用 node下面的standby。 上线就用 online.
也可以直接在shell行中执行：
[root@node2 ~]# crm node standby node2.star.com #node2离线 [root@node2 ~]# crm node online node2.star.com #node2上线 [root@node2 ~]# crm node online node1.star.com [root@node2 ~]# crm node standby node2.star.com [root@node2 ~]# crm node onliine node2.star.com
用group组来约束几个资源更简单一点，而且看起来也更清楚一点。
我们先把colocation删了，然后再定义一个位置约束把两个资源分开：
crm(live)configure# delete webip_with_webserver crm(live)configure# location conn_node1 webserver 100: node1.star.com crm(live)configure# cd There are changes pending. Do you want to commit them (y/n)? y crm(live)# status Last updated: Wed Jun 17 20:03:09 2015 Last change: Wed Jun 17 20:02:41 2015 Stack: classic openais (with plugin) Current DC: node1.star.com - partition with quorum Version: 1.1.11-97629de 2 Nodes configured, 3 expected votes 2 Resources configured Online: [ node1.star.com node2.star.com ] webip (ocf::heartbeat:IPaddr): Started node2.star.com webserver (lsb:httpd): Started node1.star.com crm(live)#
二个资源，一个资源对node2的位置约束为50，一个资源对node1的位置约束为100。
定义组以后应该会去node1上面：
crm(live)# cd crm(live)# configure crm(live)configure# group webip_webserver webip webserver INFO: resource references in location:conn_node2 updated INFO: resource references in order:webip_before_webserver updated INFO: resource references in location:conn_node1 updated INFO: resource references in order:webip_before_webserver updated crm(live)configure# verify crm(live)configure# commit crm(live)configure# show node node1.star.com \ attributes standby=off node node2.star.com \ attributes standby=off primitive webip IPaddr \ params ip=172.16.5.5 primitive webserver lsb:httpd group webip_webserver webip webserver location conn_node1 webip_webserver 100: node1.star.com location conn_node2 webip_webserver 50: node2.star.com property cib-bootstrap-options: \ dc-version=1.1.11-97629de \ cluster-infrastructure="classic openais (with plugin)" \ expected-quorum-votes=3 \ last-lrm-refresh=1434504714 \ stonith-enabled=false rsc_defaults rsc-options: \ resource-stickiness=50 crm(live)configure# cd crm(live)# status Last updated: Wed Jun 17 20:09:36 2015 Last change: Wed Jun 17 20:08:46 2015 Stack: classic openais (with plugin) Current DC: node1.star.com - partition with quorum Version: 1.1.11-97629de 2 Nodes configured, 3 expected votes 2 Resources configured Online: [ node1.star.com node2.star.com ] Resource Group: webip_webserver webip (ocf::heartbeat:IPaddr): Started node1.star.com webserver (lsb:httpd): Started node1.star.com
上面提示了一些INFO信息， 因为组是自身就有启动顺序的，所以order约束就自动失效了，自动删除了order约束， 而location约束由原来对单个资源的，自动变成了对组的约束了。
还有对于组里面资源的启动顺序，刚才试了一下， 确实是第一个资源先启动的， 我把httpd的执行文件给删了，这样如果httpd先启动的话，启动失败就不再启动IP了。 如果IP先启动，那么IP就启动了，然后httpd失败。 可能对于不同版本的配置工具，也会有所不同吧。
有时候资源出现问题，如：我上面把httpd程序移回去以后，资源还是不会自动启动，或是想要清除上面资源的错误信息。 可以用resource cleanup webserver
如果是在系统界面下，就直接执行: crm resource cleanup webserver 就可以了，清理信息，重新部署资源。
在系统界面下面执行的crm 就是在交互式模式里的各个菜单加上参数。
资源监控
以现在我们的配置来看运行的还算可以，但是如果httpd程序突然挂了，或IP地址出问题了怎么办。默认情况下pacemaker是不会去监控资源状态的， 这个需要我们自己来指定。 用monitor来给资源添加监控。
我们来试试加上监控，让pacemaker发现资源停止以后可以自动重启资源。
监控是作为资源的选项而存在的。 我们在指定资源的时候可以直接指定监控了。
interval监控区间， timeout获取资源状态超时时间。
然后就可以试试把httpd给kill或者service httpd stop。 如果查看集群日志可以看到监控信息。
在定义资源时直接添加监控。
说到这里，还有一点就是timeout的问题， 如果timeout超时了怎么办， 系统默认是ignore。
我们可以在定义监控的时候用on-fail=来指定。它的参数有: ignore、restart、stop、block、fence、standby。
ignore：忽略，
restart：重启资源，也许会转移资源（可能是在重启不成功的情况下）。
stop：停止资源。
block：好像跟stop差不多，刚学完就给忘了@_@。
fence：隔离这个节点，STONITH来一下，。
standby：standby节点，并转移此节点上的所有资源。
这样在获取一个资源状态超时的时候就会重启资源。 在测试这个的时候把httpd脚本的status给注释了，然后资源就会一直在重启，但是不会转移，不知道什么原因，不知道是不是因为重启httpd的时候所返回的信息已经让pacemaker知道这个资源启动成功了呢。#_#
standby会standby节点，在做实验的时候有可能会发现所有节点都standby了。
简单应用也就这些了，简单定义资源、约束还有监控。
例：定义ip和nfs资源还有httpd。 并且在同一个节点，启动顺序:ip-nfs-server。倾向于node1节点。
注意：我们还有资源粘性值，三个资源在一起就是150。 如果想让它们从node2移到node1就要有大于150的位置约束了。我们这里只是练练手，不要在意资源粘性的作用啊，如果真是在工作中，可就要好好规划这些东西了。
crm(live)configure# primitive webip ocf:heartbeat:IPaddr params ip=172.16.5.5 nic=eth0 op monitor interval=30s timeout=20s on-fail=restart crm(live)configure# verify crm(live)configure# primitive webstore ocf:heartbeat:Filesystem params device="172.16.5.20:/webdata" directory="/var/www/html" fstype=nfs op start timeout=60s op stop timeout=60s op monitor interval=30s timeout=40s on-fail=restart crm(live)configure# verify crm(live)configure# primitive webserver lsb:httpd op monitor interval=30s timeout=20s on-fail=restart crm(live)configure# verify crm(live)configure# crm(live)configure# group webip_webstore_webserver webip webstore webserver crm(live)configure# verify crm(live)configure# location web webip_webstore_webserver 200: node1.star.com crm(live)configure# verify crm(live)configure# commit
上面所定义的资源在ra菜单info中可以查看，而且可以在定义的时候双TAB键也会显示出来。
而且在定义监控分数的时候，verify会提示：推荐的分数。
写这点东西一来便于自己的记忆和查看；二来呢也是为了朋友们如果发现写的不好或是错误的地方，希望可以指点一下； 最后如果这点东西还可以帮助到大家的话，那看来自己没有白学啊。