Heartbeat的切换策略-积分统计方法
Saturday, March 29th, 2008
在V2的Heartbeat中，为了将资源的监控和切换结合起来，同时支持多节点集群，Heartbeat提供了一种积分策略来控制各个资源在集群中各节点之间的切换策略。通过该积分机制，计算出各节点的的总分数，得分最高者将成为active状态来管理某个（或某组）资源。
如果在CIB的配置文件中不做出任何配置的话，那么每一个资源的初始分数（resource-stickiness）都会是默认的0，而且每一个资源在每次失败之后所减掉的分数（resource-failure-stickiness）也是0。如此的话，一个资源不论他失败多少次，heartbeat都只是执行restart操作，不会进行节点切换。一般来说，resource-stickiness的值都是正数，resource-failure-stickiness的值都是负数。另外还有一个特殊值那就是正无穷大（INFINITY）和负无穷大（-INFINITY）。如果节点的分数为负分，那么不管什么情况发生，该节点都不会接管资源（冷备节点）。随着资源的各种状态的发生，在各节点上面的分数就会发生变化，随着分数的变化，一旦某节点的分数大于当前运行该资源的节点的分数之后，heartbeat就会做出切换动作，现在运行该资源的节点将释放资源，分数高出的节点将接管该资源。
在CIB的配置中，可以给每个资源定义一个分数，通过resource-stickiness来设置，同样也可以设置一个失败后丢失的分数，通过resource-failure-stickiness来设置。如下：
<primitive id=”mysql_db” class=”ocf” type=”mysql” provider=”heartbeat”>
<meta_attributes id=”mysql_db_meta_attr”>
<attributes>
<nvpair name=”resource_stickiness” id=”mysql_db_meta_attr_1″ value=”100″/>
<nvpair name=”resource_failure_stickiness” id=”mysql_db_meta_attr_2″ value=”-100″/>
</attributes>
</meta_attributes>
…
<primitive />
上面的配置就是给mysql_db这个resource配置了两个分数，成功运行的时候所得到的分数（resource_stickiness）和运行失败会丢失的分数（resource_failure_stickiness），两项分数值一样多，成功则得100分，失败则-100分。
除了可以通过给每个资源单独设置两项的分数之外，也可以将所有的resource设置成相同的分数，如下：
<configuration>
<crm_config>
<cluster_property_set id=”cib-bootstrap-options”>
<attributes>
…
<nvpair id=”default-resource-failure-stickiness” name=”default-resource-failure-stickiness” value=”-100″/>
<nvpair id=”default-resource-stickiness” name=”default-resource-stickiness” value=”100″/>
…
</attributes>
</cluster_property_set>
</crm_config>
…
在这个配置中，就是给所有资源设置了两个默认的分数，省去单独每个资源都设置的麻烦。当然，如果在设置了这个default分数之后，同时也给部分或者全部资源也设置了这两个分数的话，将取单独设置的各个资源设置的分数而不取默认分数。
除了资源的分数之外，节点自身同样也有分数。节点分数可以如下设置：
…
<constraints>
<rsc_location id=”rsc_location_group_mysql” rsc=”group_mysql”>
<rule id=”mysql1_group_mysql” score=”200″>
<expression id=”mysql1_group_mysql_expr” attribute=”#uname” operation=”eq” value=”mysql1″/>
</rule>
<rule id=”mysql2_group_mysql” score=”150″>
<expression id=”mysql2_group_mysql_expr” attribute=”#uname” operation=”eq” value=”mysql2″/>
</rule>
</rsc_location>
</constraints>
…
注意这里节点分数的设置是放在configuration配置项里面的constraints配置项下的，通过rule来设置。这里是通过节点主机名来匹配的（实际上heartbeat的很多配置中对主机名都是很敏感的）。这里的value值就是节点的主机名，rule里面的score就是一个节点的分数。
通过上面的配置，我们可以作出如下计算：
a、在最开始，两边同时启动heartbeat的话，两边都没有开始运行这个resource，resource本身没有分数，那么仅仅计算节点的分数：
mysql1的分数：node+resource+failcount*failure=200+0+(0*(-100))=200
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat会做出选择在mysql1上面运行mysql_db这个资源，然后mysql1的分数发生变化了，因为有资源自身的分数加入了：
mysql1的分数：node+resource+failcount*failure=200+100+(0*(-100))=300
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
b、过了一段时间，heartbeat的monitor发现mysql_db这个资源crash（或者其他问题）了，分数马上会发生变化，如下：
mysql1的分数：node+resource+failcount*failure=200+100+(1*(-100))=200
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
heartbeat发现mysql1节点的分数还是比mysql2的高，那么资源不发生迁移，将执行restart类操作。
c、继续运行一段时间发现又有问题（或者是b后面restart没有起来）了，分数又发生变化了：
mysql1的分数：node+resource+failcount*failure=200+100+(2*(-100))=100
mysql2的分数：node+resource+failcount*failure=150+0+(0*(-100))=150
这时候heartbeat发现mysql2节点比mysql1节点的分数高了，资源将发生迁移切换，mysql1释mysql_db相关资源，mysql2接管相关资源，并在mysql2上运行mysql_db这个资源。这时候，节点的分数又会发生变化如下：
mysql1的分数：node+resource+failcount*failure=200+0+(2*(-100))=0
mysql2的分数：node+resource+failcount*failure=150+100+(0*(-100))=250
这时候如果在mysql2上面三次出现问题，那么mysql2的分数将变成-50，又比mysql1少了，资源将迁移回mysql1，mysql1的分数将变成100，而mysql2的分数将变成-150，因为又少了资源所有者的那100分。到这里，mysql2节点的分数已经是负数了。heartbeat还有一个规则，就是资源永远都不会迁移到一个分数分数是负数的节点上面去。也就是说从这以后，mysql1节点上面不管mysql_db这个资源失败多少次，不管这个资源出现什么问题，都不会迁移回mysql2节点了。一个节点的分数会在该节点的heartbeat重启之后被重置为初始状态。或者通过相关命令来对集群中某个节点的某个资源或者资源组来重置或者查看其failcount，如下：
crm_failcount -G -U mysql1 -r mysql_db #将查看mysql1节点上面的mysql_db这个资源的failcount
crm_failcount -D -U mysql1 -r mysql_db #将重置mysql1节点上面的mysql_db这个资源的failcount
当然，在实际应用中，我们一般都是将某一些互相关联的资源放到一起组成一个资源组，一旦资源组中某资源有问题的时候，需要迁移整个资源组的资源。这个和上面针对单个资源的情况实际上没有太多区别，只需要将上面mysql_db的设置换到资源组即可，如下：
[...]
Heartbeat V2 模块分析
Saturday, March 29th, 2008
一、heartbeat模块：
整个Heartbeat软件的通信模块，各个节点之间的任何通信都是通过这个模块完成。这个模块会根据不同类型的通信启动不同的事件handler，当监听到不同类型的通信请求后会分给不同的handler来处理。这个从整个Heartbeat的启动日志中看出来。
二、CRM：cluster resource manager
从这个名字就可以看出这个模块基本上就是v2的heartbeat的一个只会中心，整个系统的一个大脑了，他主要负责整个系统的各种资源的当前配置信息，以及各个资源的调度。也就是根据各资源的配置信息，以及当前的运行状况来决定每一个资源（或者资源组）到底该在哪个节点运行。不过这些事情并不是他直接去做的，而是通过调度其他的一些模块来进行。
他通过heartbeat模块来进行节点之间的通信，调度节点之间的工作协调。随时将通过heartbeat模块收集到的各个成员节点的基本信息转交给CCM某块来更新整个集群的membership信息。他指挥LRM（local resource manager）对当前节点的各资源执行各种相应的操作（如start、stop、restart和monitor等等），同时也接收LRM在进行各种操作的反馈信息并作出相应的决策再指挥后续工作。另外CRM模块还负责将各个模块反馈回来的各种信息通过调用设定的日志记录程序记录到日志文件中。
三、LRM：local resource manager
LRM是整个Heartbeat系统中直接操作所管理的各个资源的一个模块，负责对资源的监控，启动，停止或者重启等操作。这个模块目前好像支持有四种类型的资源代理（resource agent）：heartbeat自身的，ocf（open cluster framework），lsb（linux standard base，其实就是linux下标准的init脚本），还有一种就是stonith。stonith这种我还不是太清楚是一个什么类型的。
四种类型的resource agent中的前三种所调用的脚本分别存如下路径：
heartbeat：/etc/ha.d/resource.d/
ocf:/usr/lib/resource.d/heartbeat/
lsb:/etc/init.d/
LRM就是通过调用以上路径下面的各种脚本来实现对资源的各种操作。每一种类型的脚本都可以由用户自定义，只要支持各类型的标准即可。实际上这里的标准就是接受一个标准的调用命令和参数格式，同时返回符合标准的值即可。至于脚本中的各种操作时如何的LRM并不care。
四、PE：CRM Policy Engine
他主要负责将CRM发过来的一些信息按照配置文件中的各种设置来进行计算，分析。然后将结果信息按照某种固定的格式通过CRM提交给TE（Transition engine）去分析出后续需要采取的相应的action。PE需要计算分析的信息主要是当前有哪些节点，各节点的状况，当前管理有哪些资源，各资源当前在哪一个节点，在各个节点的状态如何等等。
五、TE：Transition engine
主要工作是分析PE的计算结果，然后根据配置信息转换成后续所需的相应操作。个人感觉PE和TE组合成一个类似于规则引擎实现的功能，而且PE和TE这两个模块只有在处于active的节点被启动。另外PE和TE并不直接通信，而都是通过Heartbeat的指挥中心CRM来传达信息的。
六、CIB：cluster information base
CIB在系统中充当的是当前集群中各资源原始配置以及之后动态变化了的状态，统计信息收集分发中心，是一个不断更新的信息库。当他收集到任何资源的变化，以及节点统计信息的变化后，都会集成整合到一起组成当前集群最新的信息，并分发到集群各个节点。分发动作并不是自己和各个节点通信，同样也是通过heartbeat模块来做的。
CIB收集整理并汇总出来的信息是以一个xml格式保存起来的。实际上Heartbeat v2的资源配置文件也就是从haresources迁移到了一个叫cib.xml文件里面。该文件实际上就是CIB的信息库文件。在运行过程中，CIB可能会常读取并修改该文件的内容，以保证信息的更新。
七、CCM：consensus cluster membership
CCM的最主要工作就是管理集群中各个节点的成员以及各成员之间的关系。他让集群中各个节点有效的组织称一个整体，保持着稳定的连接。heartbeat模块所担当的只是一个通信工具，而CCM是通过这个通信工具来将各个成员连接到一起成为一个整体。
八、LOGD：logging daemon（non-blocking）
一个无阻塞的日志记录程序，主要负责接收CRM从各个其他模块所收集的相关信息，然后记录到指定额度日志文件中。当logd接收到日志信息后会立刻返回给CRM反馈。并不是一定要等到将所有信息记录到文件后再返回，日志信息的记录实际上是一个异步的操作。
九、APPHBD：application heartbeat daemon
apphbd模块实际上是给各个模块中可能需要用到的计时用的服务，是通过watchdog来实现的。这个模块具体的细节我还不是太清楚。
十、RMD：recovery manager daemon
主要功能是进程恢复管理，接受从apphbd所通知的某个（或者某些）进程异常退出或者失败或者hang住后的恢复请求。RMD在接受到请求后会作出restart（如果需要可能会有kill）操作。
