双控制节点通过heartbeat+pacemaker监控相关服务，所以须在两台控制节点上先安装heartbeat软件，安装过程可参照：

      pacemaker主要是对控制节点上的资源进行切换，实际需求如下：只要主控制节点上任何一个与openstack相关的服务停止，都需要把vip及相关服务切换到备控制节点。

      备控制节点的安装和主控制节点一样，在配置数据库时需要配置成slave，和主控制节点上的master实时同步，可以参照前面文档安装。

开始配置crm资源，通过crm交互模式进行配置，主要演示web、vip、nova-network的切换

property stonith-enabled=false
property no-quorum-policy=ignore
property start-failure-is-fatal=false
rsc_defaults migration-threshold=1
primitive vip ocf:heartbeat:IPaddr2 params ip=10.1.6.100 nic=br100 op monitor interval=3s
primitive www lsb:apache2 op monitor interval="10s" 
primitive nova-network lsb:nova-network op monitor interval="60s"
colocation vip_and_www inf: www vip
order vip_and_www_order inf: vip www
location compute-1 vip 200: compute-1
location compute-2  vip 100: compute-2
commit

      通过交互模式配置资源，最后必须commit，否则配置信息不会保存的，保存的配置信息文件在/var/lib/heartbeat/crm/cib.xml


      注意：配置某个RA前，进入ra模式使用meta查看一下该RA的常用选项，及其语法规则，有的选项后面带单位s（秒），有的不带。另外，建议直接调高pacemaker群集默认的最小值。示例如：

crm(live)ra#meta ocf:heartbeat:Filesystem
crm(live)configure# property default-action-timeout=60

      如果是两个节点的集群，应该设置no-quorum-policy为ignore，如果一个节点down掉，另一个节点仍能正常运行。设置start- failure-is-fatal 为false，允许你为每一个资源设置migration-threshold属性。如果没有定义stonith资源则必须设置stonith-enabled为 false。


删除vip资源

    crm_resource -D -r www -t primitive

删除Failed actions

    crm resource cleanup www

      在配置完成后，你会发现nova-*服务在检测状态时是不正常的，从而导致无法切换，这是因为服务的状态检测脚本有些小问题。

      LSB格式的resource agent script中必须支持status功能，所谓的resource agent就是服务的启动脚本，这我这里叫runhttpd.sh,runjboss等，必须能接收start,stop,status三个参数，如果是OCF格式agent，则必须支持start,stop,monitor三个参数。其中status和monitor参数是用来监控资源的，非常重要。

       例如LSB风格的脚本，运行./runhttpd.sh status时候：
       返回值包含OK或则running则表示资源正常
       返回值包含stopped或者No则表示资源不正常

       假如是OCF风格的脚本，运行./runhttpd.sh monitor时候：
       返回0表示资源是正常的, 返回3表示资源出现问题

nova-*服务的启动脚本在/etc/init.d/目录下都是/lib/init/upstart-job的软连接，所以只要修改upstart-job脚本就可以了，主要修改检测服务时的返回状态码即可。

返回码修改参照：

http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/ap-lsb.html

       在把主控制节点宕机或者宕掉相关服务后，可以顺利切换到备控制节点，但是在主控制节点恢复后，从备控制节点再切回主控制节点时在本次实验环境下会有些问题，主要是数据库方面的。

关于本次切换的感想：

     这些切换也不是无缝切换的，在消息队列方面的问题还是比较多的。在不做二次开发，利用第三方开源软件基本上可以实现高可用性。

pacemaker来实现的，在计算节点和vm实例的监控可以参照下面两篇文章:

这是<<openstack cookbook>>建议的监控工具，老外用的工具在国内还真小众，不过上面的云服务提供商也是用的这两款监控软件。


    当初的实验环境备破坏掉了，这些是根据笔记整理出来的内容。

附上crm_resource命令使用方法：

Queries:
       -L, 显示所有资源
       -l, 显示所有实例化的资源，不会显示组、克隆等信息
       -O, 显示当先活动的资源操作
       -o, 显示所有的资源操作
       -q, --query-xml
              Query the definition of a resource (template expanded)
       -w, --query-xml-raw
              Query the definition of a resource (raw xml)
       -W, 显示当前位置的资源
       -A, --stack
              Display the prerequisites and dependents of a resource
       -a, 显示当前位置的资源约束关系
Commands:
       -p, --set-parameter=value
              Set the named parameter for a resource. See also -m, --meta
       -g, --get-parameter=value
              Display the named parameter for a resource. See also -m, --meta
       -d, --delete-parameter=value
              Delete the named parameter for a resource. See also -m, --meta
       -M, 从当前位置把资源迁移走, 目的地址可以使用 (-N)指定            
       -U, --un-move
              Remove all constraints created by a move command
Advanced Commands:
       -D, 从CIB中删除一个资源
       -F, 告诉集群这个资源失效
       -R, -更新CIB从LRM
       -C, 从LRM中删除资源
       -P, --reprobe
              (Advanced) Re-check for resources started outside of the CRM
Additional Options:
       -N, 节点名称
       -t, 资源的属性 (primitive, clone, group, ...)
       -v, --parameter-value=value
              Value to use with -p, -g or -d
       -u, 迁移约束关系时的时间
       -m, 修改资源的配置选项，和-p -g -d使用               
       -z, 修改资源使用的属性和 -p, -g, -d使用
       -s, --set-name=value
              (Advanced) ID of the instance_attributes object to change
       -i, --nvpair=value
              (Advanced) ID of the nvpair object to change/delete
       -f, --force

参考连接：

 http://wangxiaoyu.blog.51cto.com/blog/922065/520923
http://sushan.blog.51cto.com/3532080/733484