corosync+pacemaker安装并通过crmsh配置

321312

一、简单介绍：

• 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源。
  
  
  

1	yum install corosync pacemaker -y

• crmsh 依赖于pssh. 下载地址：crmsh,pssh都在这里。 epel源中也有pssh
• http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/
  
  

1	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

• 1	cp corosync.conf.example corosync.conf

  
  
  
  

        把注释信息去掉以后就下面这些了：

• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

  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         } }

  
  
  
• 然后再添加以下参数：
  

• 1 2 3 4 5 6 7 8 9 10 11

  } service {         var: 0         name: pacemaker            #表示启动pacemaker } aisexec {                          #表示以哪个身份去启动CRM         user: root         group: root }

  
  
  
• 最后我这里的配置去掉注释以后是这个样子的：
  

• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

  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文件，
  

• 1 2 3 4 5 6 7 8

  [iyunv@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文件发给另一个节点。

• 1 2	scp -p /etc/corosync/authkey node2.star.com:/etc/corosync/ scp -p /etc/corosync/corosync.conf node2.star.com:/etc/corosync/

  
  
  
• 完成安装。
  
  

四、启动corosync。

• 1 2	[iyunv@node1 ~]# service corosync start Starting Corosync Cluster Engine (corosync):               [  OK  ]

  
  
  
• 确认是否启动可以通过查看日志文件：

• 1 2 3

  [iyunv@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'.                     #并且成功读取配置文件

  
  
  
• 确认是否正常发出节点通知
  

• 1 2 3 4 5

  [iyunv@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.

  
  
  
• 查看是否有错误发生
  

• 1 2 3

  [iyunv@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是否启动
  

• 1 2 3 4 5 6

  [iyunv@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      里面可以查看资源代理信息
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。

1 2 3 4 5 6 7 8 9 10 11 12

[iyunv@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看看。

1 2 3 4

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上面。

1 2 3 4 5 6 7 8 9

Usage: location <id> rsc [role=<role>] {node_pref|rules} rsc :: /<rsc-pattern>/         | { resource_sets }         | <rsc> node_pref :: <score>: <node>

我们只定义个简单位置约束， 所以用简单的就行啦。  

1	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行中执行：

1 2 3 4 5

[iyunv@node2 ~]# crm node standby node2.star.com        #node2离线 [iyunv@node2 ~]# crm node online node2.star.com         #node2上线 [iyunv@node2 ~]# crm node online node1.star.com       [iyunv@node2 ~]# crm node standby node2.star.com       [iyunv@node2 ~]# crm node onliine node2.star.com

---

用group组来约束几个资源更简单一点，而且看起来也更清楚一点。
我们先把colocation删了，然后再定义一个位置约束把两个资源分开：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

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上面：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

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的位置约束了。我们这里只是练练手，不要在意资源粘性的作用啊，如果真是在工作中，可就要好好规划这些东西了。

1 2 3 4 5 6 7 8 9 10 11 12

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会提示：推荐的分数。

---

写这点东西一来便于自己的记忆和查看；二来呢也是为了朋友们如果发现写的不好或是错误的地方，希望可以指点一下； 最后如果这点东西还可以帮助到大家的话，那看来自己没有白学啊