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 {                                #用以启动pacemaker的设置。在corosync 1.4以后，pacemaker是独立守护进程存在，也就不过这一段配置了。
          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:  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:  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  : [:] [:]
colocation 约束名称 分数： 资源 资源

注意：在分数后面的冒号后面可是有一个空格的。

现在两个资源都在node1上了。 分数可以用数字来表示也可以用inf来表示无穷大。还有-inf负无穷大。

那么有时候我们可能要让ip先启动，然后才是httpd， 这样有顺序的去启动资源。  可以用order约束。

这里来约束的值可以用score也可以用kind。 kind有Manadatory表示强制。 后面的两个看来可能是看情况的意思。 也可以用分数来表示。 强制的力度好像更强， 我们就用Manadatory吧。

不知道score中的inf跟kind中的Manadatory一样不。不过都是可以正常生效的，可能力度不一样吧。

上面一开始写错了，所以下面要用delete把所定义的资源删除了， 在edit中直接删除也可以。

然后还有位置约束location。我这个现在在node1上面，如果我希望它们在node2上面。

Usage:

location  rsc [role=] {node_pref|rules}

rsc :: //
        | { resource_sets }
        | 

node_pref :: : 

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

location  rsc : 

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

---

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

转载于:https://blog.51cto.com/fanqie/1662624