corosync+pacemaker来实现http服务的高可用性

jhegw

一、corosync概述
1、AIS概述
AIS（应用程序接口规范）是用来定义应用程序接口（API）的开放性规范的集合，这些应用程序作为中间件为应用服务提供一种开放、高移植性的程序接口。另外，服务可用性论坛（SA Forum）是一个开放性论坛，它开发并免费发布这些规范，使用AIS规范的应用程序接口，可以减少应用程序的复杂性和缩短应用程序的开发时间。这些规范的主要目的是为了提高中间组件可移植性和应用程序的高可用性。SAF AIS是一个开放性工程，在不断更新中。
2、OpenAIS概述
OpenAIS是基于SA Forum标准的集群框架的应用程序接口规范。OpenAIS提供了一种集群模式，这个模式包括集群框架、集群成员管理、通信方式、集群监测等等，能够为集群软件或工具提供满足AIS标准的集群接口。但是它没有集群资源管理功能，不能独立的形成一个集群。OpenAIS包含三个分支：Picacho、Whitetank、Wilson。Wilson是最新的。现在比较常用的是Whitetank和Wilson，这两者之间有很多地方是不同的。在Wilson版本中，Corosync被独立出来了，Wilson把OpenAIS的核心架构组件独立出来放到Corosync（Corosync是一个集群管理引擎）里面。而剩下的组件都是AIS组件。

3、Corosync概述
Corosync是Wilson版本中独立出来的一个项目，它也是OpenAIS的一部分。Corosync包含OpenAIS的核心架构用来对Wilson的标准接口的使用、管理。Corosync是一个集群管理引擎，它工作在messaging Layer上用来传递集群各节点的相关信息，如各节点的心跳信息等。Corosync不具有管理集群资源的功能，它可以借助pacemaker来实现集群资源的管理。

二、pacemaker概述
pacemaker是一个集群资源管理器，它可以利用你喜欢的集群基础构件（OpenAIS和heartbeat）提供的消息和成员管理能力来探测并从节点或资源级别的故障中恢复过来，以实现集群服务的最大可用性。pacemaker不是heartbeat的一个工具，最初开发的项目是heartbeat v3，后来pacemaker成为该项目中的子项目。pacemaker支持heartbeat和Corosync等messaging Layer工具。

三、实验
利用Corosync+pacemaker来实现http服务的高可用性

前提：
1）本配置共有两个测试节点，分别ha1.xsl.com和ha2.xsl.com，相的IP地址分别为192.168.108.199和192.168.108.201；
2）集群服务为apache的httpd服务；
3）提供web服务的地址为192.168.108.100；
4）系统为rhel5.8
1、准备工作
为了配置一台Linux主机成为HA的节点，通常需要做出如下的准备工作：
1）所有节点的主机名称和对应的IP地址解析服务可以正常工作，且每个节点的主机名称需要跟"uname -n“命令的结果保持一致；因此，需要保证两个节点上的/etc/hosts文件均为下面的内容：
192.168.108.199   ha1.xsl.com
192.168.108.201   ha2.xsl.com
为了使得重新启动系统后仍能保持如上的主机名称，还分别需要在各节点执行类似如下的命令：
ha1.xsl.com:
# sed -i [url=]'s@\(HOSTNAME=\).*@\1ha1.xsl.com@g'[/url]  /etc/sysconfig/network
# hostname ha1.xsl.com
ha2.xsl.com：
# sed -i [url=]'s@\(HOSTNAME=\).*@\1ha2.xsl.com@g'[/url] /etc/sysconfig/network
# hostname ha2.xsl.com
2）设定两个节点可以基于密钥进行ssh通信，这可以通过类似如下的命令实现：
ha1.xsl.com:
# ssh-keygen -t rsa
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@ha2.xsl.com
ha2.xsl.com:
# ssh-keygen -t rsa
# ssh-copy-id -i ~/.ssh/id_rsa.pub root@ha1.xsl.com

2、安装如下rpm包：
libibverbs, librdmacm, lm_sensors, libtool-ltdl, openhpi-libs, openhpi, perl-TimeDate
3、安装corosync和pacemaker，首先下载所需要如下软件包至本地某专用目录（这里为/root/cluster）：
cluster-glue
cluster-glue-libs
heartbeat
resource-agents
corosync
heartbeat-libs
pacemaker
corosynclib
libesmtp
pacemaker-libs
下载地址：http://clusterlabs.org/rpm/。请根据硬件平台及操作系统类型选择对应的软件包；这里建议每个软件包都使用目前最新的版本。
  32bits rpm包下载地址：   http://clusterlabs.org/rpm/epel-5/i386/
  64bits rpm包下载地址：   http://clusterlabs.org/rpm/epel-5/x86_64/
  
下载libesmtp
# wget ftp://ftp.univie.ac.at/systems/linux/fedora/epel/5/x86_64/libesmtp-1.0.4-5.el5.x86_64.rpm
# wget ftp://ftp.univie.ac.at/systems/linux/fedora/epel/5/i386/libesmtp-1.0.4-5.el5.i386.rpm

使用如下命令安装：
# cd /root/cluster
# yum -y --nogpgcheck localinstall *.rpm
4、配置corosync，（以下命令在ha1.xsl.com上执行）
# cd /etc/corosync
# cp corosync.conf.example corosync.conf
#####
totem {          #这是一种协议，用来传递集群节点之间心跳等相关信息
        version: 2     #这是totem协议的版本号
        secauth: on    #是否启用安全认证，可以避免非集群节点随意加入到集群中来
        threads: 0     #启动几个线程来传递心跳信息。如果有多个节点且cpu是多核的，可以多启动几个。0为默认配置
        interface {     #定义心跳信息传递的接口
                ringnumber: 0  #定义接口的循环次数，避免报文无限循环下去
                bindnetaddr: 192.168.1.1 #定义传递心跳信息的那个网卡的所在网络
                mcastaddr: 226.94.1.1  #定义使用多播地址来传递心跳信息
                mcastport: 5405    #定义服务监听端口
        }
}
logging {       #定义日志功能
        fileline: off
        to_stderr: no    #是否将标准错误输出到屏幕上，一般使用no
        to_logfile: yes    #是否将日志保证至文件中
        to_syslog: no    #是否开启syslog日志功能，如果开启，则日志保存在/var/log/messages
        logfile: /var/log/cluster/corosync.log #日志文件,这个文件所在目录事先不存在，需要手动创建
        debug: off     #是否开启调试功能
        timestamp: on    #是否使用时间戳
        logger_subsys {   
                subsys: AMF
                debug: off
        }
}
amf {
        mode: disabled
}

接着编辑corosync.conf，添加如下内容：
service {
  ver:  0
  name: pacemaker
  # use_mgmtd: yes
}
aisexec {
  user: root
  group:  root
}
并设定此配置文件中 bindnetaddr后面的IP地址为你的网卡所在网络的网络地址，我们这里的两个节点在192.168.108.0网络，因此这里将其设定为192.168.108.0；如下
bindnetaddr: 192.168.108.0
生成节点间通信时用到的认证密钥文件：
# corosync-keygen
注：corosync生成key文件会默认调用/dev/random随机数设备，一旦系统中断的IRQS的随机数不够用，将会产生大量的等待时间，因此，为了节约时间，我们在生成key之前讲random替换成urandom，以便节约时间。
[root@ha1.xsl.com corosync]# mv /dev/{random,random.bak}   
[root@ha1.xsl.com corosync]# ln -s /dev/urandom /dev/random
[root@ha1.xsl.com corosync]# corosync-keygen   
Corosync Cluster Engine Authentication key generator. # grep -e "Corosync Cluster Engine" -e "configuration file" /var/log/messages
   
Gathering 1024 bits for key from /dev/random.   
Press keys on your keyboard to generate entropy.   
Writing corosync key to /etc/corosync/authkey.

将corosync.conf和authkey复制至ha2.xsl.com:
# scp -p corosync.conf authkey  ha2.xsl.com:/etc/corosync/
分别为两个节点创建corosync生成的日志所在的目录：
# mkdir /var/log/cluster
# ssh ha2.xsl.com  'mkdir /var/log/cluster'

5、尝试启动，（以下命令在ha1.xsl.com上执行）：
# /etc/init.d/corosync start
查看corosync引擎是否正常启动：
# grep -e "Corosync Cluster Engine" -e "configuration file" /var/log/messages
Jun 14 19:02:08 ha1.xsl.com corosync[5103]:   [MAIN  ] Corosync Cluster Engine ('1.2.7'): started and ready to provide service.
Jun 14 19:02:08 ha1.xsl.com corosync[5103]:   [MAIN  ] Successfully read main configuration file '/etc/corosync/corosync.conf'.
Jun 14 19:02:08 ha1.xsl.com corosync[5103]:   [MAIN  ] Corosync Cluster Engine exiting with status 8 at main.c:1397.
Jun 14 19:03:49 ha1.xsl.com corosync[5120]:   [MAIN  ] Corosync Cluster Engine ('1.2.7'): started and ready to provide service.
Jun 14 19:03:49 ha1.xsl.com corosync[5120]:   [MAIN  ] Successfully read main configuration file '/etc/corosync/corosync.conf'.

查看初始化成员节点通知是否正常发出：
# grep  TOTEM  /var/log/messages
Jun 14 19:03:49 ha1.xsl.com corosync[5120]:   [TOTEM ] Initializing transport (UDP/IP).
Jun 14 19:03:49 ha1.xsl.com corosync[5120]:   [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [TOTEM ] The network interface [192.168.108.199] is now up.
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [TOTEM ] A processor joined or left the membership and a new membership was formed.

检查启动过程中是否有错误产生：
# grep ERROR: /var/log/messages | grep -v unpack_resources

查看pacemaker是否正常启动：
# grep pcmk_startup /var/log/messages
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [pcmk  ] info: pcmk_startup: CRM: Initialized
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [pcmk  ] Logging: Initialized pcmk_startup
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [pcmk  ] info: pcmk_startup: Maximum core file size is: 4294967295
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [pcmk  ] info: pcmk_startup: Service: 9
Jun 14 19:03:50 ha1.xsl.com corosync[5120]:   [pcmk  ] info: pcmk_startup: Local hostname: ha1.xsl.com

如果上面命令执行均没有问题，接着可以执行如下命令启动ha2.xsl.com上的corosync
# ssh ha2.xsl.com -- /etc/init.d/corosync start
注意：启动ha2.xsl.com需要在ha1.xsl.com上使用如上命令进行，不要在ha2.xsl.com节点上直接启动；

使用如下命令查看集群节点的启动状态：
# crm status
============
Last updated: Tue Jun 14 19:07:06 2011
Stack: openais
Current DC: ha1.xsl.com - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, 2 expected votes
0 Resources configured.
============
Online: [ ha1.xsl.com ha2.xsl.com ]
从上面的信息可以看出两个节点都已经正常启动，并且集群已经处于正常工作状态。
执行ps auxf命令可以查看corosync启动的各相关进程。
root      4665  0.4  0.8  86736  4244 ?        Ssl  17:00   0:04 corosync
root      4673  0.0  0.4  11720  2260 ?        S    17:00   0:00  \_ /usr/lib/heartbeat/stonithd
101       4674  0.0  0.7  12628  4100 ?        S    17:00   0:00  \_ /usr/lib/heartbeat/cib
root      4675  0.0  0.3   6392  1852 ?        S    17:00   0:00  \_ /usr/lib/heartbeat/lrmd
101       4676  0.0  0.4  12056  2528 ?        S    17:00   0:00  \_ /usr/lib/heartbeat/attrd
101       4677  0.0  0.5   8692  2784 ?        S    17:00   0:00  \_ /usr/lib/heartbeat/pengine
101       4678  0.0  0.5  12136  3012 ?        S    17:00   0:00  \_ /usr/lib/heartbeat/crmd

6、配置集群的工作属性，禁用stonith
corosync默认启用了stonith，而当前集群并没有相应的stonith设备，因此此默认配置目前尚不可用，这可以通过如下命令验正：
# crm_verify -L
crm_verify[5202]: 2011/06/14_19:10:38 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
crm_verify[5202]: 2011/06/14_19:10:38 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
crm_verify[5202]: 2011/06/14_19:10:38 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
  -V may provide more details
我们里可以通过如下命令先禁用stonith：
# crm configure property stonith-enabled=false
使用如下命令查看当前的配置信息：
# crm configure show
node ha1.xsl.com
node ha2.xsl.com
property $id="cib-bootstrap-options" \
  dc-version="1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87" \
  cluster-infrastructure="openais" \
  expected-quorum-votes="2" \
  stonith-enabled="false
  
从中可以看出stonith已经被禁用。
上面的crm，crm_verify命令是1.0后的版本的pacemaker提供的基于命令行的集群管理工具；可以在集群中的任何一个节点上执行。

7、为集群添加集群资源
corosync支持heartbeat，LSB和ocf等类型的资源代理，目前较为常用的类型为LSB和OCF两类，stonith类专为配置stonith设备而用；
可以通过如下命令查看当前集群系统所支持的类型：
# crm ra classes
heartbeat
lsb
ocf / heartbeat pacemaker
stonith
如果想要查看某种类别下的所用资源代理的列表，可以使用类似如下命令实现：
# crm ra list lsb
# crm ra list  heartbeat
# crm ra list ocf heartbeat
# crm ra list ocf pacemaker
# crm ra list stonith
查看某个资源代理所支持的参数和配置语法格式，可以使用如下命令：
# crm ra info [class:[provider:]]resource_agent

例如：
# crm ra info ocf:heartbeat:IPaddr

8、接下来要创建的web集群创建一个IP地址资源，以在通过集群提供web服务时使用；这可以通过如下方式实现：
语法：
primitive <rsc> [<class>:[<provider>:]]<type>
          [params attr_list]
          [operations id_spec]
            [op op_type [<attribute>=<value>...] ...]
   
rsa:这个是配置资源时所起的名字。如要配置ip地址时，给ip地址这个资源起个名字为webip
class={heartbeat|lsb|ocf|stonith},provider={heartbeat|pacemaker}
op_type={start | stop | monitor}
例子：
primitive apcfence stonith:apcsmart \
          params ttydev=/dev/ttyS0 hostlist="ha1.xsl.com ha2.xsl.com" \
          op start timeout=60s \
          op monitor interval=30m timeout=60s
ip地址资源配置应用：
# crm configure primitive WebIP ocf:heartbeat:IPaddr params ip=192.168.108.100  nic=eth0  cidr_netmask=24

通过如下的命令执行结果可以看出此资源已经在ha1.xsl.com上启动：
# crm status
============
Last updated: Tue Jun 14 19:31:05 2011
Stack: openais
Current DC: ha1.xsl.com - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ ha1.xsl.com ha2.xsl.com ]
WebIP  (ocf::heartbeat:IPaddr):  Started ha1.xsl.com
当然，也可以在ha1.xsl.com上执行ifconfig命令看到此地址已经在eth0的别名上生效：
# ifconfig
eth0:0    Link encap:Ethernet  HWaddr 00:0C:29:AA:DD:CF  
          inet addr:192.168.108.100  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:67 Base address:0x2000
         
而后我们到ha2.xsl.com上通过如下命令停止ha1.xsl.com上的corosync服务：
# ssh ha1.xsl.com -- /etc/init.d/corosync stop
查看集群工作状态：
# crm status
============
Last updated: Tue Jun 14 19:37:23 2011
Stack: openais
Current DC: ha2.xsl.com - partition WITHOUT quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ ha2.xsl.com ]
OFFLINE: [ ha1.xsl.com ]
上面的信息显示ha1.xsl.com已经离线，但资源WebIP却没能在ha2.xsl.com上启动。这是因为此时的集群状态为"WITHOUT quorum"，即已经失去了quorum，此时集群服务本身已经不满足正常运行的条件，这对于只有两节点的集群来讲是不合理的。因此，我们可以通过如下的命令来修改忽略quorum不能满足的集群状态检查：
# crm configure property no-quorum-policy=ignore
片刻之后，集群就会在目前仍在运行中的节点ha2.xsl.com上启动此资源了，如下所示：
# crm status
============
Last updated: Tue Jun 14 19:43:42 2011
Stack: openais
Current DC: ha2.xsl.com - partition WITHOUT quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ ha2.xsl.com ]
OFFLINE: [ ha1.xsl.com ]
WebIP  (ocf::heartbeat:IPaddr):  Started ha2.xsl.com

好了，验正完成后，我们正常启动ha1.xsl.com:
# ssh ha1.xsl.com -- /etc/init.d/corosync start
正常启动ha1.xsl.com后，集群资源WebIP很可能会重新从ha2.xsl.com转移回ha1.xsl.com。资源的这种在节点间每一次的来回流动都会造成那段时间内其无法正常被访问，所以，我们有时候需要在资源因为节点故障转移到其它节点后，即便原来的节点恢复正常也禁止资源再次流转回来。这可以通过定义资源的黏性(stickiness)来实现。在创建资源时或在创建资源后，都可以指定指定资源黏性。
资源黏性值范围及其作用：
0：这是默认选项。资源放置在系统中的最适合位置。这意味着当负载能力“较好”或较差的节点变得可用时才转移资源。此
选项的作用基本等同于自动故障回复，只是资源可能会转移到非之前活动的节点上；
大于0：资源更愿意留在当前位置，但是如果有更合适的节点可用时会移动。值越高表示资源越愿意留在当前位置；
小于0：资源更愿意移离当前位置。绝对值越高表示资源越愿意离开当前位置；
INFINITY：如果不是因节点不适合运行资源（节点关机、节点待机、达到migration-threshold 或配置更改）而强制资源转移，资源总是留在当前位置。此选项的作用几乎等同于完全禁用自动故障回复；
-INFINITY：资源总是移离当前位置；
我们这里可以通过以下方式为资源指定默认黏性值：
# crm configure rsc_defaults resource-stickiness=100

9、结合上面已经配置好的IP地址资源，将此集群配置成为一个active/passive模型的web（httpd）服务集群
为了将此集群启用为web（httpd）服务器集群，我们得先在各节点上安装httpd，并配置其能在本地各自提供一个测试页面。
ha1.xsl.com:
# yum -y install httpd
# echo "<h1>ha1.xsl.com</h1>" > /var/www/html/index.html
ha2.xsl.com:
# yum -y install httpd
# echo "<h1>ha2.xsl.com</h1>" > /var/www/html/index.html
而后在各节点手动启动httpd服务，并确认其可以正常提供服务。接着使用下面的命令停止httpd服务，并确保其不会自动启动（在两个节点各执行一遍）：
# /etc/init.d/httpd stop
# chkconfig httpd off

接下来我们将此httpd服务添加为集群资源。将httpd添加为集群资源有两处资源代理可用：lsb和ocf:heartbeat，为了简单起见，我们这里使用lsb类型：
首先可以使用如下命令查看lsb类型的httpd资源的语法格式：
# crm ra info lsb:httpd
lsb:httpd
Apache is a World Wide Web server.  It is used to serve \
         HTML files and CGI.
Operations' defaults (advisory minimum):
    start         timeout=15
    stop          timeout=15
    status        timeout=15
    restart       timeout=15
    force-reload  timeout=15
    monitor       interval=15 timeout=15 start-delay=15
接下来新建资源WebSite：
# crm configure primitive WebSite lsb:httpd
查看配置文件中生成的定义：
node ha1.xsl.com
node ha2.xsl.com
primitive WebIP ocf:heartbeat:IPaddr \
  params ip="192.168.108.100"
primitive WebSite lsb:httpd
property $id="cib-bootstrap-options" \
  dc-version="1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87" \
  cluster-infrastructure="openais" \
  expected-quorum-votes="2" \
  stonith-enabled="false" \
  no-quorum-policy="ignore"
  
查看资源的启用状态：
# crm status
============
Last updated: Tue Jun 14 19:57:31 2011
Stack: openais
Current DC: ha2.xsl.com - partition with quorum
Version: 1.0.11-1554a83db0d3c3e546cfd3aaff6af1184f79ee87
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ ha1.xsl.com ha2.xsl.com ]
WebIP  (ocf::heartbeat:IPaddr):  Started ha1.xsl.com
WebSite  (lsb:httpd):  Started ha2.xsl.com

从上面的信息中可以看出WebIP和WebSite有可能会分别运行于两个节点上，这对于通过此IP提供Web服务的应用来说是不成立的，即此两者资源必须同时运行在某节点上。
由此可见，即便集群拥有所有必需资源，但它可能还无法进行正确处理。资源约束则用以指定在哪些群集节点上运行资源，以何种顺序装载资源，以及特定资源依赖于哪些其它资源。pacemaker共给我们提供了三种资源约束方法：
1）Resource Location（资源位置）：定义资源可以、不可以或尽可能在哪些节点上运行；
2）Resource Collocation（资源排列）：排列约束用以定义哪些集群资源可以或不可以在某个节点上同时运行；
3）Resource Order（资源顺序）：顺序约束定义集群资源在节点上启动的顺序；
定义约束时，还需要指定分数。各种分数是集群工作方式的重要组成部分。其实，从迁移资源到决定在已降级集群中停止哪些资源的整个过程是通过以某种方式修改分数来实现的。分数按每个资源来计算，资源分数为负的任何节点都无法运行该资源。在计算出资源分数后，集群选择分数最高的节点。INFINITY（无穷大）目前定义为 1,000,000。加减无穷大遵循以下3个基本规则：
1）任何值 + 无穷大 = 无穷大
2）任何值 - 无穷大 = -无穷大
3）无穷大 - 无穷大 = -无穷大
定义资源约束时，也可以指定每个约束的分数。分数表示指派给此资源约束的值。分数较高的约束先应用，分数较低的约束后应用。通过使用不同的分数为指定资源创建更多位置约束，可以指定资源要故障转移至的目标节点的顺序。
因此，对于前述的WebIP和WebSite可能会运行于不同节点的问题，可以通过定义排列约束来解决：
# crm configure colocation website-with-ip INFINITY: WebSite WebIP

接着，我们还得确保WebSite在某节点启动之前得先启动WebIP，因此，需要配置顺序约束，这可以使用如下命令实现：
# crm configure order httpd-after-ip mandatory: WebIP WebSite
此外，由于HA集群本身并不强制每个节点的性能相同或相近，所以，某些时候我们可能希望在正常时服务总能在某个性能较强的节点上运行，这可以通过位置约束来实现：
# crm configure location prefer-ha1.xsl.com WebSite rule 200: hostname eq  ha1.xsl.com
这条命令实现了将WebSite约束在ha1.xsl.com上，且指定其分数为200；

测试
当节点ha1.xsl.com服务停止时，资源会不会自动转移到ha2.xsl.com节点上。在ha1.xsl.com这个节点上，可以使用如下命令来模拟服务转移：
#crm  node   standy
crm(live)# status
============
Last updated: Wed Feb 18 01:34:33 2015
Stack: openais
Current DC: ha2.xsl.com - partition with quorum
Version: 1.0.12-unknown
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Node ha1.xsl.com: standby
Online: [ ha2.xsl.com ]
webip (ocf::heartbeat:IPaddr): Started ha2.xsl.com
webhttp (lsb:httpd): Started ha2.xsl.com
由此可以看出，当节点ha1.xsl.com出现故障时，集群资源会转移到ha2.xsl.com上去。

测试，当节点ha1.xsl.com重新上线时，资源是否会重新回到ha1.xsl.com这个节点上去。在ha1.xsl.com，我们可以使用如下命令来模拟ha1.xsl.com重新上线：
#crm node  online
crm(live)# status
============
Last updated: Wed Feb 18 20:54:55 2015
Stack: openais
Current DC: ha1.xsl.com - partition with quorum
Version: 1.0.12-unknown
2 Nodes configured, 2 expected votes
2 Resources configured.
============
Online: [ ha1.xsl.com ha2.xsl.com ]
webip (ocf::heartbeat:IPaddr): Started ha2.xsl.com
webhttp (lsb:httpd): Started ha2.xsl.com

由此看出，当节点ha1.xsl.com重新上线时，资源并没有转移回来，这是因为，我们定义了位置约束和资源粘性。

通过上面的步骤我们已经完成了web高可用集群的配置，其集群配置如下：
crm(live)configure# show
node ha1.xsl.com \
attributes standby="off"
node ha2.xsl.com \
attributes standby="off"
primitive webhttp lsb:httpd \
meta target-role="Stopped"
primitive webip ocf:heartbeat:IPaddr \
params ip="192.168.108.100" \
meta target-role="Stopped"
location prefer-node webhttp \
rule $id="prefer-node-rule" 200: hostname eq ha1.xsl.com
colocation webhttp-with-webip inf: webhttp webip
order http-after-ip inf: webip webhttp
property $id="cib-bootstrap-options" \
dc-version="1.0.12-unknown" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
last-lrm-refresh="1424355566"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"


对于上述，由于集群资源可能不在同一个节点上，我们是通过定义排列约束和顺序约束来解决的。其实，除了这种方式之外，我们还可以通过定义资源组的方式来实现，资源组就是将多个资源绑定在一起，这样资源就不会分散。
首先停止webip和webhttp这两个资源，webip和webhttp都是资源的名称，执行如下命令即可：
#crm resource start webip
#crm resource start webhttp



然后在主节点（或者称为活动的节点）上清理的资源，执行如下命令即可：
#crm resource  clean  webip  ha1.xsl.com
#crm resource  clean  webip  ha2.xsl.com

在资源停止后，需要将其之前定义的排列约束和顺序约束的相关配置删除，因为在这里我们使用资源组的概念来将所有的资源绑定在一起，上面已经介绍了如何利用排列约束和顺序约束来将资源绑定在一起。其相关配置如下：
删除排列约束和顺序约束需要执行如下命令,prefer-node和http-after-ip为定义排列约束和顺序约束的id号。
#crm configure  webhttp-with-webip
#crm configure  http-after-ip

删除完成之后的配置如下：
crm(live)configure# show
node ha1.xsl.com \
attributes standby="off"
node ha2.xsl.com \
attributes standby="off"
primitive webhttp lsb:httpd \
meta target-role="Stopped"
primitive webip ocf:heartbeat:IPaddr \
params ip="192.168.108.100" \
meta target-role="Stopped"
location prefer-node webhttp \
rule $id="prefer-node-rule" 200: hostname eq ha1.xsl.com
property $id="cib-bootstrap-options" \  
dc-version="1.0.12-unknown" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
last-lrm-refresh="1424355566"
rsc_defaults $id="rsc-options" \
resource-stickiness="100"

说明：如果删除操作是在crm的shell下完成的，则每一次改变配置文件时，需要执行commit命令。如上述所示，crm(live)就是crm的shell环境。如果要执行commit命令，需要执行如下命令：
crm(live)configure#commit

定义资源组
#crm configure  group webcluster webip  webhttp

定义资源组完成之后，启动资源,需要执行如下命令：（有可能定义完成之后，自动启动了）
#crm resource start webip
#crm resource start webhttp
#crm resource start webcluster

资源组定义完成之后，就可以进行测试了。测试方法如上。
当然在做实验时，只需要使用一种方法来将资源绑定在一起，避免分散。可以用资源组的方法绑定，也可以使用排列约束+顺序约束的方法来绑定在一起。使用哪种方法因人而异吧。


后端共享文件系统配置
对于web高可用集群来说，后端一般都有一个共性文件系统，一般说来，我们将一些静态的文件存储在共享文件系统中，这样不管那个节点作为主节点，服务器都可以正常访问到共享文件系统中的数据。在这里，我们使用nfs文件系统。
对于共享存储，建议将其配置lvm，这样当容量不够时，可以在其基础上增加；如果容量过大时，可以将其减小。

创建LVM
(1)、创建pv
[iyunv@nfs ~]# pvcreate  /dev/sda6
  dev_is_mpath: failed to get device for 8:6
  Writing physical volume data to disk "/dev/sda6"
  Physical volume "/dev/sda6" successfully create
  
(2)、创建VG
  [iyunv@nfs ~]# vgcreate  MYVG /dev/sda6
  Volume group "MYVG" successfully created
  [iyunv@nfs ~]# lvcreate -L 2.5G -n   MYLV MYVG
  Logical volume "MYLV" created

(3)、创建lv
[iyunv@nfs ~]# lvcreate -L 2.5G -n   MYLV MYVG
  Logical volume "MYLV" already exists in volume group "MYVG"
  
  显示lv的信息
  [iyunv@nfs ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/MYVG/MYLV
  VG Name                MYVG
  LV UUID                2eulwL-36CE-TIAP-JY6J-gLyb-O3wi-9UQYJb
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                2.50 GB
  Current LE             640
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1
  
(4)、格式化lv
[iyunv@nfs ~]# mke2fs -j /dev/MYVG/MYLV
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
327680 inodes, 655360 blocks
32768 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=671088640
20 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912
Writing inode tables: done                           
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

(5)、挂载文件系统
[iyunv@nfs ~]# mount /dev/MYVG/MYLV /www/web
在/www/web目录下创建一个文件为index.html,需要执行如下命令即可：
#vim index.html
<h1>hello  the  world</h1>
将其配置为开启自动挂载，需要编辑/etc/fstab文件：
需要添加如下行则可：
/dev/MYVG/MYLV          /www/web                ext3    defaults        0 0
执行如下命令，重新挂载/etc/fstab文件中的文件系统
mount -a

编辑nfs的配置文件
#vim  /etc/exports
添加如下行：
/www/web 192.168.108.0/24(rw,no_root_squash)

启动portmap服务和启动nfs服务
[iyunv@nfs ~]# service portmap start
Starting portmap:                                          [  OK  ]
[iyunv@nfs ~]# service nfs start
Starting NFS services:                                     [  OK  ]
Starting NFS quotas:                                       [  OK  ]
Starting NFS daemon:                                       [  OK  ]
Starting NFS mountd:                                       [  OK  ]
Stopping RPC idmapd:                                       [  OK  ]
Starting RPC idmapd:                                       [  OK  ]
[iyunv@nfs ~]#


nfs配置完成之后，还需要在活动的节点上，加入nfs文件系统的配置，配置命令如下：
#crm configure primitive filesys  ocf:heartbeat:Filesystem params device="192.168.108.202:/www/web"  directory="/www/xsl.com"  fstype='nfs'
说明：作者的web服务的根路径为'/www/xsl.com'
params后面接的是参数，因为Filesystem这个ra是ocf风格的，可以使用如下命令查看：
#crm ra   providers Filesystem
heartbeat

当然，我们还需要将Filesys这个资源和之前的webip和webhttp绑定在一起，可以使用资源组的方式也可以使用排列约束+顺序约束的方式进行绑定，在这里我使用资源组的方式进行绑定：
首先还得停止webCluste这个资源组，需要执行如下命令：
#crm  resource  stop webcluster

然后删除这个资源组，需要执行如下命令：
#crm  configure delete  webcluster

再重新创建资源组为webcluster，需要执行如下命令：
#crm configure  group webcluster webip webhttp  filesys

测试,使用浏览器访问http://192.168.108.100，观察浏览页面的内容
然后再在主节点上执行如下命令：
#crm node standby
再次访问http://192.168.108.100，观察浏览页面的内容。如果两次观察的内容一次，说明nfs挂载成功，web服务器可以正常访问nfs了。

beson2000

谢谢分享