双控制节点通过heartbeat+pacemaker监控相关服务,所以须在两台控制节点上先安装heartbeat软件,安装过程可参照:
http://my.oschina.net/guol/blog/90128
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
在把主控制节点宕机或者宕掉相关服务后,可以顺利切换到备控制节点,但是在主控制节点恢复后,从备控制节点再切回主控制节点时在本次实验环境下会有些问题,主要是数据库方面的。
关于本次切换的感想:
基本上实现了相关功能,因为在控制节点上安装了太多的服务,导致在服务管理时很不方便,也不容易排错,按照openstack官方推荐的部署模式,数据库、api、glance、消息队列等等都是分散在不同的服务器上的,按照这种模式使用heartbeat可以很容易的做切换,因为单台机器需要切换的资源都是单一的。数据库可以采用NDB集群或者双主配置,综合来看双主配置更有利于实施,只要保证不能同时更新双主数据库的数据就ok,如果使用主备模式数据库,从主切换到备以后,在备上做的修改并不能同步到主上,这样导致切回主数据库后遗漏了在备上修改的那一部分数据。这些切换也不是无缝切换的,在消息队列方面的问题还是比较多的。在不做二次开发,利用第三方开源软件基本上可以实现高可用性。
在参观过国内某提供云服务的供应商后,发现他们也是对openstack做二次开发,在高可用性方面也是通过heartbeat+pacemaker来实现的,在计算节点和vm实例的监控可以参照下面两篇文章:
http://my.oschina.net/guol/blog/105427 http://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 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://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