Pacemaker 1.1 Configuration Explained – (8)ルール


(8)ルール

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

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

ルールのプロパティー

フィールド

デフォルト

説明

id

 

ルールのユニークな名前(必須)

role

Started

リソースが特定のroleの場合にのみルールを適用する。設定可能な値はStarted, Slave, Master。role=”Master”のルールはクローンインスタンスの最初の場所を指定することはできず、また昇格するアクティブなノードにのみ影響する。

score

 

ルールがTrueの場合に適用するスコア。ロケーション制約内にあるルールの場合にのみ使用できる。

score-attribute

 

ルールがTrueの場合にノード属性として探し、スコアとして使用する。ロケーション制約内にあるルールの場合にのみ使用できる。

boolean-op

and

複数の式がある場合の、それらの組み合わせ方。指定できる値はandor

 

ノード属性式

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

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

フィールド

デフォルト

説明

id

 

表現のユニークな名前(必須)

attribute

 

確認するノード属性(必須)

type

string

値をどのように確認するか。指定できる値はstring, integer, version

operation

 

実施する比較方法。指定できる値は

lt:ノードのattributevalueよりも小さい場合にTrue

gt: ノードのattributevalueよりも大きい場合にTrue

lte: ノードのattributevalueよりも小さい、または同じ場合にTrue

gte: ノードのattributevalueよりも大きいまたは同じ場合にTrue

eq: ノードのattributevalueと同じ場合にTrue

ne: ノードのattributevalueと異なる場合にTrue

defined:ノードに名前付きattributeがある場合にTrue

not_defined: ノードに名前付きattributeがない場合にTrue

value

 

比較に使用するユーザ指定の値(必須)

value-source

literal

値の引き出し方。指定できる値は、

literal: valueをそのままの文字列として比較に使う

param:valueをリソースパラメータの名前として比較する(位置制約の内部でのみ有効)

meta:valueはリソースのメタ属性として比較を行います。(位置制約の内部でのみ有効)

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

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

名称

#uname

ノード名

#kind

ノードタイプ。指定できる値はcluster, remote, containerremoteは、ocf:pacemaker:remoteで作成するPacemaker Remoteのノード。containerはPacemaker Remoteのゲストノード。(この呼び方は少々レガシーで、現在よく使うリソース隔離に使われる「コンテナ」とは無関係)

 

時間および日付の式

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

data_expressionの一覧:

フィールド

説明

start

ISO8601規約に基づいた日時。

end

ISO8601規約に基づいた日時。

operation

状況に応じて現在の日時をstartとendの日時と比較する。指定できる値は、

gt:現在日時がstartよりも後であればtrue

lt:現在日時がendよりも前であればtrue

in_range:現在日時がstartより後でendよりも前であればtrue

date_spec:現在日時がdate_spec(後述)と一致した場合にtrue

※ここでは時刻を扱っているため、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”のように複数を設定することは現状ではできません。

フィールド

説明

id

オブジェクトのユニークな名前

hours

0-23の値

monthdays

1-31の値(年・月に依存)

weekdays

1-7の値(1=月曜…7=日曜)

yeardays

1-366の値(年に依存)

months

1-12の値

weeks

1-53の値(週・年に依存)

years

グレゴリオ暦カレンダーの年

weekyears

その週が始まる年。例:

moon

0-7の値(0は新月、4は満月)。※この機能は本当に使用できます。

 

期間

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

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

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

 

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

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

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

 

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

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

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

 

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

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

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

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

 

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

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

以下の例では、mySpecialRscというruleで、node1の時にはeth1で9999ポートを使用し、node2ではポート8888を使用、それ以外のノードではeth0で9999ポートをデフォルトで使用するという規定を行っています。

instance_attributes内の規則はスコアの高いものから低いものの順で決定されます。設定していない場合にはデフォルトでゼロが与えられ、スコアが同じ場合には記載された順に処理されます。

instance_attributesにruleが設定されていないか、またはtrueになるruleがない場合は、その時点ではパラメータに値は与えられず、リソースによってinstance_attributesが決定するパラメータの値が与えられます。

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

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

 

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

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

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

 

時間に基づくルールを確実に動作させる

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

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

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

コメントを残す

名前 *
メールアドレス *
ウェブサイト

*