(8)ルール

ルールを使用することでより柔軟な設定を行う事ができるようになります。

例えば業務時間中にはresource-stickinessを自動フェイルバックしないように設定しておき、業務影響のない時間帯にはフェイルバックするように設定する、などです。

ルールのプロパティー

ノード属性式

ノード属性式では、ノードに定義した属性に基づいてリソースの制御を行います。

ノード属性式のプロパティー一覧：

また、他に各ノードごとに特別なノード属性を設定することができます。

ノード組み込み属性の一覧：

時間および日付の式

名前から予想がつく通り、date_expressionはリソースまたはクラスタオプションを現在の日付や時間によって制御するものです。任意でdate_specやdurationといったオプションを付けることもできます。

data_expressionの一覧：

※ここでは時刻を扱っているため、eqやneq、lteなどの一般的な比較演算子は、1秒の間しか使えないため採用していません。

日時指定

date_specはcronのような使い方をするために用います。各フィールドには1つの数字または1つの数字の範囲を指定します。デフォルト値は設定されておらず、指定のないフィールドは無視されます。

例えばmonthdays=”1”であれば毎月1日、hours=”09-17”であれば午前9時から午後5時までの間すべてを示します。weekday=”1,2”や、weekdays=”1-2,5-6”のように複数を設定することは現状ではできません。

期間

operationでin_rangeを指定する際にendを指定しない場合には、これを計算するのにdurationが使用されます。data_specオブジェクトでも同様のフィールドがあり、これは制限はありません。durationは19monthまでです。date_specを使用している場合には、指定のないフィールドは無視されます。

以下の設定の場合、現在が2017年であればTrueになります。

<rule id="rule1">
   <date_expression id="date_expr1" start="2017-001" operation="in_range">
    <duration years="1"/>
   </date_expression>
</rule>

上記とdata_specを使用しても上記と同じ効果を持つ設定が行えます。

<rule id="rule2">
   <date_expression id="date_expr2" operation="date_spec">
    <date_spec years="2017"/>
   </date_expression>
</rule>

リソースの位置を決定するためのルール

ルールを使用して位置制約を行うことができます。falseの場合には制約条件がないものとして扱われ、trueの場合には、どのノードでリソースを実行するかのスコア計算に影響します。

以下はノードがc001n03の場合にmnApacheRscリソースを起動しないという設定です。

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

他のプロパティーを使った位置制約

位置制約はノード名だけでなく、CPU性能によっても可能です。

以下のような設定を行えば、CPU性能が3000MIPSより低いノードではリソースを起動しないという制約条件を設けることができます。

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

スコアの代わりにスコア属性を使用する

スコア(score)の代わりにスコア属性(score-attribute)を使用すると、ruleに合致した各ノードは、ノード属性のスコアに応じてスコアが与えられます。

例えば以下のようなscore-attributeのあるノードセクションの設定を使用していた場合には、

<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>

score-attribute=”cpu_mips”を使用するruleを使用していれば、c001n01は1234、一方c001n02は5678が選好性に加算されます。

リソースオプション制御のルール

クラスタノード間で、バイナリのパスやNICの名称が異なる場合があるかと思います。そのような場合にはinstance_attributeを使用することができます。

以下の例では、mySpecialRscというruleで、node1の時にはeth1で9999ポートを使用し、node2ではポート8888を使用、それ以外のノードでは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にruleが設定されていないか、またはtrueになるruleがない場合は、その時点ではパラメータに値は与えられず、リソースによってinstance_attributesが決定するパラメータの値が与えられます。

例えば上記の例の設定でリソースがnode1にあった場合には、次のようになります。

1. special-node1が最もスコアが高い3なので最初に評価されます。ruleがtrueと評価され、interfaceがeth1になります。
2. 次にspecial-node2がスコア2なので評価されます。しかしruleがfalseなので無視されます。
3. defaultがスコア1なので最後に評価されます。ここではruleがありません。interfaceはすでに定義されているのでここでの指定は無視され、まだ定義されていないprotについてはここでの9999が定義されます。

クラスターオプション制御のルール

クラスターオプションの制御は異なるノードの異なるリソースオプションの定義と同様に行えます。ただしクラスターオプションでは属性に基づいた定義は行えません (そうするべきでもありません) 。

以下の例では異なるresource-stickiness値を営業時間内と外で設定しています。業務影響を与えずに、リソースがそれぞれの適切なホストに自動的に戻ることが(理論上)可能になります。

<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-16" 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クラスタはイベント駆動型のシステムです。そのためリソースの障害や設定の変更など、何らかが起きるまではリソースの適切な場所の計算は行われません。そのため、何もイベントが発生しなければ設定した時間が過ぎてもリソース移動は起きません。

ruleを使用して時間になったらある動作をさせたい場合には、クラスターオプションのcluster-recheck-intervalの指定が必要です(デフォルト15分)。本オプションは指定の時間毎に適切なリソース配置場所の計算を行うものです。

例えばcluster-recheck-interval=”5m”に設定すれば、09:00から09:05の間にリソース配置の再計算が行われ、リソース移動が行われることなります。