Pacemaker 1.1 Configuration Explained – (6)リソース制約


(6)リソース制約

 

スコア

Pacemakerのクラスタはスコアによって制御されます。スコアの増減によって、どのノードでリソースを実行するのかの判断が行われます。スコアはリソース・ノードごとに計算されます。例えば、もしリソースのスコアが負の値であれば、そのリソースは起動できません。クラスタでは、最も高い数値をもったノードでリソースを実行します。

 

INFINITY

PacemakerではINFINITYというスコアがあり、これは1,000,000に相当します。ただし、以下のように少々特殊な扱いになるので注意してください。

  • 任意のスコア + INFINITY = INFINITY
  • 任意のスコア – INFINITY = -INFINITY
  • INFINITY – INFINITY = -INFINITY

また、位置制約を行う事でリソースをどのノードで起動するか決定することができます。
位置制約をどのように設定するかには次の2つの方法があります。環境や要件に応じて使い分けてください。

  • オプトアウト・クラスタ

: デフォルトではすべてのリソースをどのノードでも起動することができる状態であり、位置制約によって起動することのできないノードを指定する方法。

  • オプトイン・クラスタ

 : デフォルトではすべてのリソースをどのノードでも起動することができない状態であり、位置制約によって起動することのできるノードを指定する方法。

 

ロケーション・プロパティー

位置制約のオプション表になります

オプション

デフォルト

説明

id

 

制約条件のユニークな名前

rsc

 

制約条件の対象になるリソースの名前

rsc-pattern

 

制約を行う対象のリソース名を正規表現でマッチングします。rscを指定しない場合は、正規表現がサブマッチを含んでおり、制約がルール(8章参照)で管理されている場合は、サブマッチがルールのスコア属性またはルールの属性に0%から9%参照されます。

node

 

ノード名

score

 

この値が正の値で大きいほど、このノードでの該当リソースの起動を優先します。負の値の場合はこのノードでの該当リソースの起動しないように優先します。(値に-INFINIFTYを設定した場合は、絶対に起動しなくなります)

resource-discovery

常に

Pacemakerがリソースの検出(リソースが起動しているかを調べる)をこのノード上で行うかどうかを設定するオプションです。通常は意図せず起動しているリソースを停止できるように、デフォルトのままにしておいてください。

無効にしたほうがよいケースには以下の2つのケースがあります。

(1)サービスがノードにインストールされていない場合:この場合はオートディスカバリーがエラーを返す事があります(適切なOCFリソースエージェントであればエラーにんはなりません。OCF以外のリソースエージェントの時に注意が必要です)。

(2)ペースメーカーリモートを使用している場合:多数のノードを使用している場合には、検出を行うノードを制限することでパフォーマンスが向上します。

always: 常にこのノードでリソースの検出を行います。

never: このノードでリソースの検出を行いません。必須ではありませんが、通常、本オプションは-INFINITYと一緒に使用します。

exclusive: このノード(と他のexclusiveを設定したノード)でのみリソースの検出を行います。複数のノードで同一のリソースに複数の位置制約をexclusiveとともに設定することで、リソース検出機能のみが使用するノードのサブセットを作成することができます。つまり、あるリソースについて1つまたはそれ以上のノードでexclusiveを設定すると、そのリソースはそれらノードのサブセット内にのみ配置されます。

注意:resource-discoveryをneverまたはexclusiveに設定すると、Pacemakerは意図せずに起動しているサービスの停止や検出を行わなくなります。そのため、システム管理者はノード上でそのサービスが起動しないようにするなどの対策を考慮するようにしてください。

 

非対称な「オプトイン」クラスタ

オプトイン・クラスタを作成するには、デフォルトでどのノードでもリソースが起動しないように設定してください。

次にノードでリソースを起動させていきます。以下の例はWebserverはsles-1を、Databaseはsles-2を優先し、これらに障害が発生した場合にはsles-3にフェイルオーバする設定です。

 

左右対称な「オプトアウト」クラスタ

オプトアウト・クラスタを作成するには、デフォルトでどのノードでもリソースが起動できるようにしておきます。

そしてリソースの制約を追加していきます。以下の例は、前項の「オプトイン」クラスタと同様の設定です。

 

2ノードが同じスコアだった場合

2つのノードが同じスコアだった場合でも、クラスタは1つのノードを選択します。この選択はランダムに思えるかもしれませんが、ある程度は予測可能です。

例えば上記の場合にはWebserverはsles-1で、Databaseはsles-2で起動します。Webserverに関しては、ノード名のuname順に従ってsles-1を選択します。Databaseについては、Pacemakerはリソースをできるだけクラスタにまんべんなく配置しようとするためsles-2を選択します。

もし、この他にも要因があれば、それらも考慮してリソースを起動するノードの選択が行われます。

 

どのリソースをStart/Stopするかの順番を決める

order制約を使用することで、リソースの起動順序を設定することができます。

重要 : order制約はリソースの起動順序にのみ影響します。もし同じノードで既定の順序でリソースを起動させたい場合には、colocation(6.4項参照)あるいはgroup(10.1項参照)オプションも併用する必要があります。

 

orderのプロパティ一覧

オプション

デフォルト

説明

id

 

制約のユニークな名前

first

 

thenリソースが依存するリソースの名前

then

 

依存するリソースの名前

first-action

start

firstリソースがthenリソースのために開始するthen-actionの動作より前に完了していなければならない動作。start, stop, promote, demoteが選択できます。

then-action

first-actionの値

firstリソースのfirst-actionの動作が完了した後でのみ実行できるthenリソースの動作。start, stop, promote, demoteが選択できます。

kind

 

制約をどのように行うか。以下が選択できます。

Optional: 優先するのみです。両ノードが指定した動作を実行しているときのみ適用します。firstリソースでの状態変化はthenリソースに影響しません。

Mandatory: 常に制約を行います。firstリソースでfirst-actionが実行されなければ、then-actionは実行されません。firstが再起動すると、thenは(起動していれば)先に停止して、また後で起動します。

Serialize: リソースでstop/startの2つの動作が行われないことを保証します。firstとthenはどちらからでも起動できますが、一方が起動する時にはもう一方では起動が完了している必要があります。一般的にはリソースの起動に負荷がかかる場合に使用されます。

symmetrical

TRUE

TRUEの場合、制約を逆の場合にも適用します。(例: Bの次にAを起動する場合、Aが停止してからBが停止する)

 

リソースを他のリソースと関連させる設定(colocation)

colocation制約は、リソースを他のリソースの位置に依存関係を持たせるものです。

colocationにはノードにアサインされているリソースに影響するという重要な側面があります。Bがどこにあるか分からないのにAをBに対して関連させられないでしょう。

そのため、AをBに対してcolocation設定するのか、BをAに対してcolocation設定するのか考慮する必要があります。

より詳しいcolocationの説明は、Colocation Explainedを参照してください。

 

Colocationプロパティー一覧

オプション

説明

id

制約条件のユニークな名前

rsc

with-rscに依存して配置されるリソースの名前

with-rsc

colocationの対象となるリソース名。クラスタは最初にこのリソースをどこに配置するのかを決定してから、rscのリソースの配置を決定することになる。

score

正の値を設定すると同じノードで起動し、負の値を設定すると別のノードで起動するようになります。+または-INFINITYを設定すると絶対的な条件になります。

 

強制的な位置制約

+/-INFINITYのスコアを使用することで強制的な位置制約を設定することができます。

 

例えば上記の場合にはAリソースは必ずBリソースが起動しているノードで起動します。もしBリソースが起動できない場合には、Aリソースは起動することができません。なお、Aが起動しているかどうかはBには影響しません。

逆に上記のように-INFINITYを設定した場合には、AはBと同じノードで起動することができません。したがって、もしクラスタ内に利用できるサーバが1台しかなく、そこでBが起動していた場合には、Aは起動することができなくなります。

 

優先的な位置制約

前項ではINFINITYを使用した絶対的な条件を説明しましたが、-INFINITYよりも大きく、INFINITYよりも小さい範囲でスコアを設定すれば「優先する」といった度合いで設定が行えます。

例:

 

crmshでの構文

Pacemakerをcrmコマンドを使って使用している場合には、以下の順序でオプション名を省略した構文でcolocationの設定を行うことができます。

 

リソースセット

リソースセットを使用すると、1つの制約条件で複数のリソースを制御することができます。リソースセットはlocaton制約、order制約、colocation制約、またticket制約の構文中で使用できます。

リソースセットには以下のプロパティーがあります。

オプション

デフォルト

説明

id

 

リソースセットのユニークな名前

sequential

true

セット内のリソースが順番通りに動作するかどうかを指定します。orderとcolocationの中でのみ有効です。

require-all

true

orderでリソースセットの次のリソースに進む前に、セット内のソースがすべてアクティブであるかどうかを指定します。現在は1つだけでも起動していれば後続に進みますが、同時に2つ以上のリソースが起動中であれば、それらが起動し終わるまで待ちます(この動作は将来変更する可能性があります)。orderの中でのみ有効です(1.1.7以降)。

role

 

制約の効果を特定のロールに限定します。location, colocation, ticketの中でのみ有効です。

action

 

制約の効果を特定の動作に限定します。order中でのみ有効です。

score

 

高度な使用方法です。制約中で特定のスコアのみ使用します。

 

リソースの順番を設定する

orderセットは、以下のように、一連のリソースを順番通りに起動したい場合に使用するのが一般的です。

crmを使用する場合は以下の構文です。

 

Orderセット

リソースセットを使用すると前項の設定を以下のように記載できます。

メンテナンスの観点からはこちらのほうが望ましいでしょう。

crmを使用する場合は以下の構文になります。

 

複数のセットの順番を制御する

構文を拡張して、リソースセット間に依存関係を持たせることができます。各リソースセットは順番通りにもそうでないようにも設定できます。下の例ではAとBが並列で起動し、AとBの両方が起動してからCとDが並列に起動するという設定になっています。

どちらかのセット、あるいは両セットのリソースを内部で順序通りに動作するよう制御することも可能です。これはsequential=”true”で設定します。また、設定できるセット数に制限はありません。

上記は以下のような順序で起動します。

 

論理和(OR)リソースセット

ここまでに説明してきたものは「AND」条件のものでした。前項は3つのリソースセットがあり、 (A and B) then (C) then (D) then (E and F)という流れになっていました。

一方で、AまたはBがしたらCの起動に進みたい「OR」条件を用いた設定にしたい場合にはどのように設定すればよいでしょうか。つまり、(A or B) then (C) then (D) then (E and F)という流れにしたい場合です。

この場合には、require=allオプションをfalseに変更することでOR論理を使用することができます。(require-allオプションはデフォルトではfalseになっているので、OR論理を使用したい場合には明示的な指定が必要です。)

以下、例になります。

 

リソースのcolocationセット

colocation設定したリソースのセットを作成する方法です。

1つ目の方法としては、10.1の「グループ」を使用する方法があります。ただし、この場合には常に正しい状態を制御することができません。

2つ目の方法としては、個々の制約条件を設定していくという方法があります。ただし、この方法はリソースや制約条件の組み合わせの数が増えていくと、以下の例のように制約条件の数も増大するという欠点があります。

 

上記の記述をより簡潔にするために、colocation制約の中でリソースセットを使用する方法があります。

例えば以下の場合、もしBが起動しない場合にはC、Bも起動しないという事になります。

 

また、リソースセットではroleを指定することもできます。sequention=falseも合わせて以下のような設定も可能です。

また、リソースセットではroleを指定することもできます。sequention=falseも合わせて以下のような設定も可能です。

コメントを残す

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

*