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。