pacemaker规则详解

译文原网址为：http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/s-rules-location.html

使用规则来决定资源的位置

如果最外层的约束规则求值结果为false，集群则会视为该规则无效。当最外层的约束规则计算为true时，与规则相关联的资源的分数将会被更新，并选择资源在哪个节点运行。

如果上面的解释你听起来很熟悉，那是应为你已经使用了一个相对比较简单的规则语法来创建约束规则了。
例子：防止myApacheRsc运行在节点c001n03上

<rsc_location id="dont-run-apache-on-c001n03" rsc="myApacheRsc" score="-INFINITY" node="c001n03"/>

这天约束规则可以写的更加冗余：

  <rsc_location id="dont-run-apache-on-c001n03" rsc="myApacheRsc">         <rule id="dont-run-apache-rule" score="-INFINITY">                <expression id="dont-run-apache-expr" attribute="#uname" operation="eq" value="c00n03"/>         </rule>  </rsc_location>

使用扩展形式的优点是可以在添加额外的配置项目到这个规则中。例如限制这个规则在一天的特定时间或者一周中的某天（这个在随后的章节中讨论）。同样可以允许我们匹配节点的其他属性而不单单只是匹配节点的名字。如果我们估计每个机器的CPU电源配置如加入的节点小节：

  <nodes>         <node id="uuid1" uname="c001n01" type="normal">                <instance_attributes id="uuid1-custom_attrs">                       <nvpair id="uuid1-cpu_mips" name="cpu_mips" value="1234"/>                </instance_attributes>         </node>         <node id="uuid2" uname="c001n02" type="normal">                <instance_attributes id="uuid2-custom_attrs">                       <nvpair id="uuid2-cpu_mips" name="cpu_mips" value="5678"/>                </instance_attributes>         </node></nodes>

然后我们可以创建一条规则防止资源在动力不足的机器去上运行：

<rule id="need-more-power-rule" score="-INFINITY">  <expression id=" need-more-power-expr" attribute="cpu_mips" operation="lt" value="3000"/></rule

使用sorce-attribute来代替score

当使用score-attribute来替代score时，按照规则匹配每个节点的得分根据其命名节点属性的值而进行不同的调整。根据上述实例，如果一个规则使用了“score-attribute=”cpu_mips”，c001n01将优先级运行资源的值增加到1234，而c001n02的优先级增加到5678

使用规则来控制资源选项

通常一些集群节点会与该集群的其他节点会稍微不太一样，这些差异（以二进制命名的位置或网络接口的名称）要求资源根据托管的机器进行不同的配置。通过为资源定义多个instance_attributes对象并向每个对象添加一个规则，我们可以轻松处理这些特殊情况。在下列实例当中，mySpecialRsc将会使用eth1和port9999，当这个资源运行在节点一时，运行在节点二时使用eth2和port8888，其余的节点将会默认使用eth0和端口9999.

例子：基于不同的节点名称来定义不同的资源选项。

<primitive id="mySpecialRsc" class="ocf" type="Special" provider="me">       <instance_attributes id="special-node1" score="3">              <rule id="node1-special-case" score="INFINITY" >                   <expression id="node1-special-case-expr" attribute="#uname" operation="eq" value="node1"/>              </rule>              <nvpair id="node1-interface" name="interface" value="eth1"/>       </instance_attributes>       <instance_attributes id="special-node2" score="2" >              <rule id="node2-special-case" score="INFINITY">                   <expression id="node2-special-case-expr" attribute="#uname" operation="eq" value="node2"/>              </rule>              <nvpair id="node2-interface" name="interface" value="eth2"/>              <nvpair id="node2-port" name="port" value="8888"/>       </instance_attributes>       <instance_attributes id="defaults" score="1" >              <nvpair id="default-interface" name="interface" value="eth0"/>              <nvpair id="default-port" name="port" value="9999"/>       </instance_attributes>  </primitive>

对instance_attributes对象进行评估的顺序由其分数（从最高到最低）确定。 如果没有提供，分数默认为零，并且按照列出的顺序处理具有相等分数的对象。 如果instance_attributes对象没有规则或有一个计算结果为true的规则，那么对于任何参数，资源还没有值，资源将使用由instance_attributes对象定义的参数值。

使用规则来控制集群选项

控制集群选项的实现方式与在不同节点上指定不同资源选项的方式大致相同。有一些不一样的是这些事集群的选项，一个不能（或者说不能节点不工作）使用基于属性的表达方式。以下示例说明如何在工作时间之内和之外设置不同的资源粘性值。 这样就可以让资源自动回到最喜欢的主机，但在理论上这样做并不会干扰业务活动。

示例，设置 resource-stickiness=INFINITY 在周一到周五的早上九点到下午六点，然后设置resource-stickiness=0在其余剩下的时间里。

<rsc_defaults>    <meta_attributes id="core-hours" score="2">        <rule id="core-hour-rule" score="0">            <date_expression id="nine-to-five-Mon-to-Fri" operation="date_spec">                <date_spec id="nine-to-five-Mon-to-Fri-spec" hours="9-17" weekdays="1-5"/>            </date_expression>        </rule>        <nvpair id="core-stickiness" name="resource-stickiness" value="INFINITY"/>    </meta_attributes>    <meta_attributes id="after-hours" score="1" >        <nvpair id="after-stickiness" name="resource-stickiness" value="0"/>    </meta_attributes></rsc_defaults>

确保基于时间生效的规则

pacemaker是事件驱动系统。因此，除非发生某些事情（如资源故障货配置更改），否则不会重新计算资源运行的最佳位置。这可能意味着不会强制执行只允许资源X在上午九点至下午五点之间运行的位置约束。

如果你要依赖基于时间的规则，则必须设置cluster-recheck-interval选项。这将告诉集群定期重新计算集群的理想状态。例如，如果您将cluster-recheck-interval=5m，则在九点到九点零五分之间会注意集群需要启动资源X，而在17点到17点05之间将魂意识到他需要被停止。请注意，实际的启动和停止操作的时间取悦于首先需要执行的操作。