Check

変更履歴

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

■はじめに

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

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

早速、前回記事に引き続き、CRM設定ファイルを解読していきましょう。

前回は、例の設定ファイルが制御している以下7項目のうち、上から2項目のからくりを読み解きました。

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

※2013.1.22 リソース名をCRM設定とは異なる「dummyN」などと記載していましたが、「resourceN」の誤りでした。修正しました。すみません。

今回は、3,4番目および5番目の一部(下線部)を読み解きます。

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

### Group Configuration ###
group grp \
    resource1 \
    resource2

### Clone Configuration ###
clone clnResource \
    resource3

### Primitive Configuration ###
primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource2 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

primitive resource3 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

この箇所ではgroup, clone, primitiveの3コマンドを使用し、どんなリソースを使用するかを定義しています。

■primitiveでリソースを定義

primitiveコマンドはクラスタ内で使用したい個々のリソースの定義を行います。

primitiveコマンドの概要と書式を以下に示します。

 # crm ra info ocf:heartbeat:Filesystem
 RAの簡易説明...

以下の部分は、リソースIDがresource1で、/usr/lib/ocf/resource.d/heartbeat/Dummy をRAとするリソースを定義していることになります。
開始・停止のタイムアウトは300秒、監視のタイムアウトは60秒です。
開始および監視に失敗したときはリソース再起動、停止に失敗したときはクラスタのそれ以後の動作を中止します。

primitive resource1 ocf:heartbeat:Dummy \
    op start interval="0s" timeout="300s" on-fail="restart" \
    op monitor interval="10s" timeout="60s" on-fail="restart" \
    op stop interval="0s" timeout="300s" on-fail="block"

resource2, 3 についても同様です。

■groupでリソースをひとまとめに

groupは、primitiveで定義した個々のリソースをグループ化します。
グループ化したリソースに対しては、以下の制御が行われます。

• 常に同一サーバで起動する。
• groupコマンドに指定した順にリソースを起動する。またその逆順に停止する。

グループ化は、あるサービスを提供するのに、複数のリソースを同時に使用しなければならない場合に使用します。
例えば、データベースをクラスタ化する場合、データベースそのものの他に、共有ディスクや、アクティブ側のデータベースへアクセスするためのIPアドレスなどを同時に起動しなければなりません。
しかも、共有ディスクはデータベースより先に起動(マウント)しなければなりません(さもないとデータファイルがなくデータベースを起動できないでしょう)。

groupコマンドの書式は以下です。

以下部分は、リソースID resource1およびresource2をグループ化しています。グループIDはgrpです。

### Group Configuration ###
group grp \
    resource1 \
    resource2

これにより、resource1とresource2は常に同じノードで起動し、resource1 → resource2 の順で起動し、その逆順で停止します。

■cloneで複数ノードへリソース複製

cloneは、primitiveで定義した個々のリソースをクローン化します。
クローン化したリソースは、通常のリソースと異なり、複数のノード上で同時に起動します。リソースが複製（クローン）され、複数ノードへ配置されるイメージです。

例えば、ノードのネットワーク疎通を確認するリソース(Pacemaker-1.0系の場合「ocf:pacemaker:pingd」、1.1系の場合「ocf:pacemaker:ping」)を使用する場合、アクティブ側ノードはもちろん、スタンバイ側ノードでもいつでもサービスが提供できるよう、常にアクティブ側と同じようにネットワーク疎通を確認しておく必要があります。
このようなときのためにcloneは用意されています。

cloneコマンドの書式は以下です。

以下の部分は、リソースID resource3をクローン化しています。クローンリソースIDはclnResourceです。
clone-max, clone-node-maxは指定していないため、全ノード(pm01,pm02)で1つずつresource3リソースが起動します。

### Clone Configuration ###
clone clnResource \
    resource3

さぁ、以上で、3,4番目および5番目の一部の制御が理解できました。

• 3. dummy1, dummy2という名前のリソースをgrpという名前のgroup(グループ)にします。
• →primitiveでdummy1, dummy2を定義し、groupでグループ化しています。
• 4. dummy3という名前のリソースをclnDummyという名前のclone(クローン)リソースとし、両マシンで起動します。
• →cloneコマンドでクローンリソースを定義しています。clone-maxを指定していないので両(全)ノードで起動します(デフォルト)。
• 5. dummy1,2,3のリソースは、必ずdummy3(clnDummy)→dummy1→dummy2の順で起動します。
• →dummy1→dummy2の順はこれらがgroupのためです。(dummy3の起動順のからくりは次回説明します。)

次ページでこれらの動作を実験で確認します。

コラム LSBって？
LSBはLinux Standard Baseと呼ばれる、Linuxの内部構造の仕様です。
PacemakerがinitスクリプトをRAとする場合、このLSBに準拠していることを前提に制御をおこないます。
具体的には以下を前提としています。

「start」「stop」「status」の３つのメソッドが定義されていること。
「start」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
サービスが停止している場合：サービスを起動し0を返す。
サービスが(すでに)起動している場合：0を返す。
「stop」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
サービスが(すでに)停止している場合：0を返す。
サービスが起動している場合：サービスを停止し、0を返す。
「status」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
サービスが停止している場合：3を返す。
サービスが起動している場合：0を返す。
それぞれ失敗した場合は、0および3以外のエラーコードを返すこと。

独自のRAを作成する場合も、この仕様に準拠する必要があります。詳細は公式マニュアルを参照してください。