動かして理解するPacemaker ~CRM設定編~ その3


変更履歴

  • 2013.9.19 初版制定
  • 2016.3.24 Pacemaker-1.1に対応

■はじめに

Linux-HA Japanをご覧の皆さんこんにちは。Linux-HA Japanの中の人、ひがしと申しますm(_ _)m

「動かして理解するPacemaker ~CRM設定編~ その3」ということで、前々回前回の続きです。

今回で、例の設定ファイルが制御している以下7項目をすべて読み解くことになります。3回に渡ったCRM設定編は今回で最後となります。

  • 1. STONITHは無効です。(その1で読み解き済み)
  • 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その1で読み解き済み)
  • 3. resource1, resource2という名前のリソースをgrpという名前のgroup(グループ)にします。(その2で読み解き済み)
  • 4. resource3という名前のリソースをclnResourceという名前のclone(クローン)リソースとし、両マシンで起動します。(その2で読み解き済み)
  • 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。(一部その2で読み解き済み)
  • 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。
  • 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。

※前回、前々回の記事でリソース名をCRM設定とは異なる「dummy1」などと記載していましたが、「resource1」の誤りでした。すみません。

 

今回注目するのは以下の部分です。

### Resource Location ###
location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

### Resource Colocation ###
colocation rsc_colocation-1 INFINITY: grp clnResource

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

この箇所ではlocation, colocation, orderの3つのコマンドを使用しています。

この3つはいずれもリソースに対し「制約」を設定するためのコマンドです。

「制約」を使用すると、リソースが起動する際の以下3つの条件を設定することができ、それぞれがコマンドに対応しています。

  • location →場所:どのノードで起動するか?
  • colocation→同居:どのリソースと一緒に起動するか?
  • order   →順序:どのリソースの前/後に起動するか?

早速、この3コマンドの説明を、と言いたいところですが、その前に制約を理解するのに重要な概念があります。
それは「スコア値」です。

詳細は後ほど説明しますが、制約の3コマンドはいずれもあるルールに対しスコア値を設定するものです。
なので、まずはスコア値の説明からしたいと思います。

■スコア値の大きいノードでリソースは起動する

スコア値は、リソースをどのノードで起動するかの優先度を示す値です。
ノードを起動したり、リソースを追加したり、故障が発生したり、とクラスタの状態に変化があった場合にPacemakerが自動的に(再)計算します。

Pacemakerは算出したスコア値を比較し、最も大きな値のノードでリソースを起動します。
算出したスコア値が負の値場合、そのノードでそのリソースを起動することはできません。

スコア値は以下の範囲のいずれかになります。

-INFINITY < 負の値 < 0 < 正の値 < INFINITY

「-INFINITY(マイナス無限大)」と「INFINITY(無限大)」は特殊な値で、前者は「禁止」、後者は「強制」を示します。
それぞれ他の値との演算結果は以下のように定義されています

  • 他の値 + INFINITY = INFINITY
  • 他の値 – INFINITY = -INFINITY
  • INFINITY – INFINITY = -INFINITY

1,2番目の演算結果はなんとなくわかりますが、3番目の演算結果はちょっと不思議な気がします。
数学的に言えば∞-∞は不定です。が、クラスタのリソースが起動するかどうかが不定となっては不便です。
-INIFNITYは典型的には故障が発生したノードに付与されます。もしINIFINITY – INFINITYが不定だと、後述の制約コマンドでINFINITYを付与したノードで故障が発生した場合、リソースが起動するかどうかが不定になってしまいます。
これを避け、故障したノードでは起動しない、と判断するため-INFINITYを優先しているのです。

スコア値は基本的にはPacemakerがクラスタの状況に応じ自動的に算出しますが、後述の「制約」により特定に場合のスコア値をユーザが決める(Pacemakerに与える)ことができます。
「制約」を上手に活用しスコア値を操作することで、リソースの起動をユーザの意のままに操ることができるのです。

■locationで起動するノードを制約

locationは起動するノードを制約するコマンドです。
そのノードの状態を評価し、それにマッチした場合のスコア値を定義することで設定します。

locationの概要と代表的な書式は以下のようになります。

概要 論理演算式を満たした場合のスコア値を指定することで、リソースが起動するノードを制約します。
論理演算式では主に「ノード名」と「属性値」を評価できます。
rule~の行を複数記述することで1リソースに複数の評価式およびスコアを設定することができます。
書式 location <制約のID> <リソースID> \
  rule <スコア値>: <ノード状態の評価式> [and|or <ノード状態の評価式>...] [\]
  [rule ...]
設定項目 制約のID この制約を一意に識別するためのIDを付与します。英数字から成るクラスタ内で一意の任意の文字列を指定します。
リソースID 制約の対象となるリソースをリソースIDで指定します。rule~の行を複数記述することで1リソースに複数のスコア値を設定することができます。
スコア値 右側の論理演算式が真の場合のスコア値を指定します。
ノード状態の評価式 ノード状態の評価式は主に「ノード名の評価」および「属性値の評価」「属性値の有無」の3パターンをよく使用します※。
記法はそれぞれ以下のような形です。

#uname <演算子> <値>
ノード名と<値>を、<演算子>で比較・評価します。
「#uname」という記述はそのノードのノード名に展開され評価されます。
<値>には任意の英数字を比較対象として指定することができます。
<属性値名> <演算子> <値>
<属性値名>で指定した属性値と<値>を、<演算子>で比較・評価します。
<値>には任意の英数字を比較対象として指定することができます。
defined|not_defined <属性値名>
<属性値名>で指定した属性値が定義されているかどうかを評価します。
definedは当該属性値が定義されているときに真、not_definedは定義されていないときに真となります。

※日付も評価することができますが、ここでは説明を省略します。知りたい方はCRM-CLI公式マニュアル(日本語版)参照をしてください。

<演算子>には以下を使用することができます。

  • lt : 左辺が右辺より小さい場合に真となる
  • gt : 左辺が右辺より大きい場合に真となる
  • lte: 左辺が右辺より小さいか等しい場合に真となる
  • gte: 左辺が右辺より大きいか等しい場合に真となる
  • eq : 左辺と右辺が等しい場合に真となる
  • ne : 左辺と右辺が等しくない場合に真となる

なお、andおよびorを使用し、複数の論理演算式の結果を統合することができます。

評価式の中で登場する属性値とは、Pacemakerが保持している値で、ノード毎にリソースの状態や、クラスタの状態を表します。
状況に応じて値が変化することで、そのノードの状態を知ることができます。
典型的にはリソースエージェントがリソースの状態をリアルタイムに示すために使用します。
例えばネットワーク疎通を確認するリソース(ocf:pacemaker:pingd)は、ネットワークが疎通している場合、指定した属性値に値を加算し、疎通していないと値を減算します。属性値は監視の度にリアルタイムに変化するため、この属性値を見ることで、今現在ネットワークが疎通しているのかを確認できるようになっています。

なお、crm_monコマンドに-Aオプションをつけると、属性値を表示させることができます。





以下の部分は、グループgrpに対し、ノードpm01での起動にはスコア200を、ノードpm02での起動にはスコア100を指定しています。
つまり、grpの起動ノードとしてpm01を優先するよう制約しています。

location rsc_location-1 grp \
    rule 200: #uname eq pm01 \
    rule 100: #uname eq pm02

これで、以下の項目が読み解けました。

  • 6. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。

■colocationで同居するリソースを制約

colocationは指定した(複数の)リソースが同一ノードで起動することに対しスコア値を設定します。

colocationの概要と代表的な書式は以下のようになります。

概要 あるリソースと、別のリソースが同一ノードに存在することに対しスコア値を設定します。
書式 colocation <制約のID> <スコア値>: <リソースID>[:<ロール>] <リソースID>[:<ロール>] [<リソースID>[:<ロール>]] …
設定項目 制約のID この制約を一意に識別するためのIDを付与します。英数字から成るクラスタ内で一意の任意の文字列を指定します。
スコア値 右側に記述したリソースを同居させることに対するスコア値を指定します。
典型的にはINFINITYを指定し同居を強制、または-INFINITYを指定し別ノードでの起動を強制します。
リソースID 制約の対象となるリソースをリソースIDで指定します。
左側のリソース起動時に右側のリソースが同一ノードに存在することに対しスコア値を設定します。
リソースIDを記述する順序で意味合いが若干変わることに注意してください。
なお、「:<ロール>」とロールを記述することもできます。ロールはmsコマンドでリソースを定義した場合に必要となる概念です。MasterやSlave等のリソース状態を指します。msコマンドについては今回の記事では対象としていないため詳細説明は省略します。

以下の部分は、グループgrpの起動時に、clnResourceが同じノードで起動する(している)ことを強制しています。

colocation rsc_colocation-1 INFINITY: grp clnResource

これで、以下の項目が読み解けました。

  • 7. resource3(clnResource)が起動していないノードではresource1およびresource2(grp)は起動しません。


■orderで順序を制約

orderは指定した(複数の)リソースのアクションを行う順序に対しスコア値を設定します。

orderの概要と代表的な書式は以下のようになります。

概要 指定した(複数の)リソースのアクションを行う順序に対しスコア値を設定します。
アクションには、起動、停止、昇格等が含まれます。
書式 order <制約のID> <スコア値>: <リソースID>[:<アクション>] <リソースID>[:<アクション>] …
[symmetrical=true|false]
設定項目 制約のID この制約を一意に識別するためのIDを付与します。英数字から成るクラスタ内で一意の任意の文字列を指定します。
スコア値 この制約に対するスコア値を指定します。
0より大きい値を指定すると、左側のリソースが状態変化した場合、右側のリソースにも影響(停止や起動を実行)します(Mandatory Ordering)。
0を指定すると、左側のリソースのアクション実行時以外の状態変化が右側のリソースに影響しません。(Advisory Ordering)
ちょっと難しい言い回しになりましたが、0とINFINITYを設定した場合、以下のようなイメージになると理解すればよいでしょう。

  • 0 :なるべく、左→右の順に<アクション>する
  • INFINITY:絶対に、左→右の順に<アクション>しなければならない
リソースID 制約の対象となるリソースをリソースIDで指定します。
左側のリソース起動時に右側のリソースが同一ノードに存在することに対しスコア値を設定します。
リソースIDを記述する順序で意味合いが若干変わることに注意してください。
アクション アクションは対象となるリソースを起動(start)、停止(stop)、昇格(promote)、降格(demote)のうち、どれを実行する場合の制約かを指定します。
指定しない場合デフォルトはstartです。
※昇格(promote)および降格(demote)はmsコマンドでリソースを定義した場合に必要となる概念です。msコマンドについては今回の記事では対象としていないため詳細説明は省略します。
symmetrical symmetricalはこの制約の逆順の制約を自動的に設定するかどうかをtrue(=する)またはfalse(=しない)で指定します。
例えば、「起動をA→Bの順で行う」という制約に対し、「停止はB→Aの順で行う」という逆の制約を自動的に設定できます。
指定しない場合デフォルトはtrueです。

以下の部分は、clnResource→grpの順に起動することを示しています。
スコア値は0のため、起動後のclnResourceの状態変化はgrpに影響しません。
symmetricalをfalseにしているため停止順は不定です。

### Resource Order ###
order rsc_order-1 0: clnResource grp symmetrical=false

これで以下の項目が読み解けました。

  • 5. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。




お気づきの方もいるかもしれませんが、前回ご紹介したgroupコマンドも、同居と順序を指定するものでした。
例えば、「group grp1 resource1 resource2」は「resource1と2は必ず同居し」、「resource1→resource2の順序で起動」を定義します。

groupは、colocationとorderを組み合わせて再現することができます。



次頁で、今回わかったことを応用した実験をしてみましょう。

Pages: 1 2 3 4

Comments are closed.