1.简介
heartbeat和pacemaker都支持三种资源代理:传统的haresources脚本(/etc/ha.d/resource.d)、符合LSB规范的脚本(/etc/init.d)以及OCF脚本(/usr/lib/ocf/resource.d/heartbeat)。其中传统的haresources脚本是基于LSB脚本的,和LSB只有少许区别。
传统的资源代理适合于没有启用pacemaker的heartbeat,也适合于设置了class=heartbeat
的Pacemaker。pacemaker中,建议优先使用OCF类的资源代理,如果没有则应该使用LSB资源代理。
无论是heartbeat还是pacemaker,对于传统的资源代理脚本和LSB脚本都只会执行start/stop/status三个操作:
1.start操作
启动资源。在已启动的资源下再次启动时,不允许返回任何错误代码(非0)。只有当前机器会启动自身的资源,且只有在status显示未运行时才会启动。
2.stop操作
停止资源。必须要保证在已停止的资源上再次停止时不会出现错误,状态码也必须为0,否则集群会不断停止资源,最后重启操作系统。但是很多不符合LSB规范的脚本都会在已停止的状态下不允许再次停止。规范的LSB脚本是无所谓多次停止的,无论是start/stop/status都具有"幂等性"。
3.status操作
判断资源是否正在运行。
status操作必须能够正确地报告资源状态,在已运行的情况下必须输出"OK"或"running"关键字,且在未运行的情况下必须不能输出"OK"和"running"关键字。对于status操作,集群不关心它的退出状态码。
这听起来很不可思议,这是因为古老的linux发行版中的init脚本给出的退出状态码不可靠,而是信任"OK"或"running"关键字。
heartbeat在很多情况下都会调用status操作,比如在start资源前会执行status,在释放资源前也会执行status(也就是说先status,再stop,因为heartbeat不知道资源是否正处于running状态)。
在重复多次stop失败后,heartbeat也会执行一次status。如果status报告该资源仍在运行,heartbeat将会重启操作系统以保证资源能彻底停止。注意,该行为只在基于haresources的集群中才会执行,在CRM/Pacemaker集群中使用的是stomith。
2.符合LSB规范的脚本
LSB资源代理一般是在/etc/init.d目录下的,它们由OS或者软件自身提供。如果要结合heartbeat或者packmaker,这些LSB脚本必须符合LSB规范。
虽然许多LSB的提供者都声称它们提供的LSB脚本是符合LSB规范的,但实际上却并非如此,常见的问题有:
- 没有输出status的操作。
- start/stop/status操作没有分配符合规范的退出状态码。
- start的时候会返回错误信息。(这严重违反LSB规范)
- stop的时候会返回错误信息。(这严重违反LSB规范)
注意,合格的LSB资源代理是无法对其传递参数的(heartbeat或pacemaker会自动处理start/stop/status/restart等操作)。
要检查一个LSB脚本是否符合LSB规范,可以使用下面的步骤来检查:
- 在stop的状态下检查start操作:
/etc/init.d/SCRIPT start; echo $?
- 服务是否启动成功?
- 上面的命令打印结果是否为"0"?
- 在已运行的情况下检查status操作:
/etc/init.d/SCRIPT status; echo $?
- 是否接受status操作?
- status的结果是否意味着服务已经运行?
- 打印结果是否为"0"?
- 在已运行的情况下再次start:
/etc/init.d/SCRIPT start; echo $?
- 服务是否仍然运行?
- 打印结果是否为0?
- 在已运行的情况下检查stop操作:
/etc/init.d/SCRIPT stop; echo $?
- 服务是否停止?
- 打印结果是否为0?
- 在已停止的情况下检查status操作:
/etc/init.d/SCRIPT status; echo $?
- 是否接受status操作?
- status的结果是否意味着服务不在运行?
- 打印结果是否为"3"?
- 在已停止的情况下再次stop:
/etc/init.d/SCRIPT stop; echo $?
- 服务是否仍然停止?
- 打印结果是否为0?
也就是说,一个符合规范的LSB脚本,接受start/stop/status,且它们的执行结果具有"幂等性",运行状态下再次运行不会有任何区别,停止状态下继续停止不会有任何区别。且在停止状态下检查status时,退出状态码为3而不是0。
3.OCF资源代理
OCF脚本写法详细手册:http://www.linux-ha.org/doc/dev-guides/ra-dev-guide.html
OCF类的资源代理是在LSB的基础上进行扩展的脚本,它在/usr/lib/ocf/resource.d/heartbeat中。如果你自己定义ocf资源脚本,可以在resoruce.d目录下创建你自己的目录,再将ocf脚本放进去。例如,你写的ocf脚本名为myocf,你想放的目录是abc,那么资源的路径是/usr/lib/ocf/resource.d/abc/myocf
。
OCF支持传递参数。要传递参数,需要借助OCF_RESKEY_
开头的环境变量。例如,要传递IP参数,可以将其定义在OCF_RESKEY_ip
环境变量上。
OCF资源代理必须具备以下几种操作:
- start:启动资源,且启动成功的退出状态码为0,启动失败的状态码不为7(可以为任何非0和7的值)。
- stop:停止资源,且停止成功的退出状态码为0,退出失败的状态码不为7。
- monitor:监控资源的健康状况,相当于status。如果资源正在运行,退出状态码0,如果已停止,退出状态码为7,如果错误,状态码可为任何值。
- meta-data:使用XML格式提供资源的信息。退出状态码为0。
- validate-all:验证配置参数。如果参数有效,则退出状态码为0,无效则为2,如果资源未配置则退出码为6,找不到要运行的资源代理时推出状态码为5。
此外,如果pacemaker要实现cloned和multi-state资源的功能,则还需要求:
- promote:资源升级,将本地资源升级为master状态,退出状态码为0。
- demote:资源降级,将本地资源降级为slave状态,退出状态码为0。
- notify:集群用它来发送通知事件,告诉资源发生了什么事。退出状态码必须为0。