双控制节点通过heartbeat+pacemaker监控相关服务，所以须在两台控制节点上先安装heartbeat软件，安装过程可参照：
http://my.oschina.net/guol/blog/90128
pacemaker主要是对控制节点上的资源进行切换，实际需求如下：只要主控制节点上任何一个与openstack相关的服务停止，都需要把vip及相关服务切换到备控制节点。
备控制节点的安装和主控制节点一样，在配置数据库时需要配置成slave，和主控制节点上的master实时同步，可以参照前面文档安装。
开始配置crm资源，通过crm交互模式进行配置，主要演示web、vip、nova-network的切换
property stonith-enabled=falseproperty no-quorum-policy=ignoreproperty start-failure-is-fatal=falsersc_defaults migration-threshold=1primitive vip ocf:heartbeat:IPaddr2 params ip=10.1.6.100 nic=br100 op monitor interval=3sprimitive www lsb:apache2 op monitor interval="10s" primitive nova-network lsb:nova-network op monitor interval="60s"colocation vip_and_www inf: www viporder vip_and_www_order inf: vip wwwlocation compute-1 vip 200: compute-1location compute-2 vip 100: compute-2commit通过交互模式配置资源，最后必须commit，否则配置信息不会保存的，保存的配置信息文件在/var/lib/heartbeat/crm/cib.xml
注意：配置某个RA前，进入ra模式使用meta查看一下该RA的常用选项，及其语法规则，有的选项后面带单位s（秒），有的不带。另外，建议直接调高pacemaker群集默认的最小值。示例如：
crm(live)ra#meta ocf:heartbeat:Filesystemcrm(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
在把主控制节点宕机或者宕掉相关服务后，可以顺利切换到备控制节点，但是在主控制节点恢复后，从备控制节点再切回主控制节点时在本次实验环境下会有些问题，主要是数据库方面的。
关于本次切换的感想：
基本上实现了相关功能，因为在控制节点上安装了太多的服务，导致在服务管理时很不方便，也不容易排错，按照openstack官方推荐的部署模式，数据库、api、glance、消息队列等等都是分散在不同的服务器上的，按照这种模式使用heartbeat可以很容易的做切换，因为单台机器需要切换的资源都是单一的。数据库可以采用NDB集群或者双主配置，综合来看双主配置更有利于实施，只要保证不能同时更新双主数据库的数据就ok，如果使用主备模式数据库，从主切换到备以后，在备上做的修改并不能同步到主上，这样导致切回主数据库后遗漏了在备上修改的那一部分数据。这些切换也不是无缝切换的，在消息队列方面的问题还是比较多的。在不做二次开发，利用第三方开源软件基本上可以实现高可用性。
在参观过国内某提供云服务的供应商后，发现他们也是对openstack做二次开发，在高可用性方面也是通过heartbeat+pacemaker来实现的，在计算节点和vm实例的监控可以参照下面两篇文章:
http://my.oschina.net/guol/blog/105427http://my.oschina.net/guol/blog/105428这是<<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 commandAdvanced Commands: -D, 从CIB中删除一个资源 -F, 告诉集群这个资源失效 -R, -更新CIB从LRM -C, 从LRM中删除资源 -P, --reprobe (Advanced) Re-check for resources started outside of the CRMAdditional 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://zhaoqiang.blog.com/2010/09/29/heartbeat3-%E4%BD%BF%E7%94%A8/ http://blog.sina.com.cn/s/blog_8ace12de01011r80.html http://wangxiaoyu.blog.51cto.com/blog/922065/520923 http://sushan.blog.51cto.com/3532080/733484