変更履歴

  • 2013.9.19 初版制定

  • 2016.3.23 Pacemaker-1.1に対応

■はじめに

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

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

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

 

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

    1. STONITHは無効です。(その１で読み解き済み)
    1. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その１で読み解き済み)
    1. resource1, resource2という名前のリソースをgrpという名前のgroup(グループ)にします。
    1. resource3という名前のリソースをclnResourceという名前のclone(クローン)リソースとし、両マシンで起動します。
    1. resource1,2,3のリソースは、必ずresource3(clnResource)→resource1→resource2の順で起動します。
    1. grpはどちらか片方のマシンで起動します。両マシンが稼働可能な状態の場合、pm01を優先します。
    1. 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コマンドの概要と書式を以下に示します。

概要 リソースIDおよびリソースエージェント(RA)を指定し、クラスタ内で使用するリソースを定義します。 リソースの起動、監視、停止それぞれの制御時のタイムアウトおよびそれぞれの制御が失敗したときの挙動も指定します。
書式 primitive リソースID RA名     [meta リソースの動作設定...]     [params RAに渡すパラメータ...]     [op start|stop|monitor オペレーション時の設定...]
設定項目 リソースID リソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
CRMファイルの他の箇所でこのリソースを示す場合やcrm_monコマンドでの表示等にも使用します。
RA名 使用するRAの種類とファイル名を「:」で区切った記法で指定します。よく使用するパターンは以下です。
ocf:heartbeat:RAファイル名
/usr/lib/ocf/resource.d/heartbeat/RAファイル名※　に配置されたスクリプトをRAとして使用します。
ocf:pacemaker:RAファイル名
/usr/lib/ocf/resource.d/pacemaker/RAファイル名※　に配置されたスクリプトをRAとして使用します。
lsb:initスクリプト名
/etc/init.d/initスクリプト名　に配置されたスクリプトをRAとして使用します。 Linuxに付属のinitスクリプトをRAとして使用することができます。 ただし、initスクリプトがLSBと呼ばれる仕様に準拠している必要があります。
stonith:プラグインファイル名(パス)
STONITH機能を使用する場合、STONITHの方法に応じた専用のプラグインを指定します。 /usr/lib64/stonith/プラグイン名※　に配置されたプログラムを使用します。
ocf:～は「:」で区切られた3つの記述の1,2番目でRAの種別を、3番目がRAのファイル名を示します。 lsb:～およびstonith:～は、「:」で区切られた1番目でRAの種別を、2番目がスクリプト/プログラムのファイル名です。 ※Pacemakerをインストールすると、このディレクトリに様々なRA、プラグインが配置されます。
リソースの動作設定 リソースの故障時等の動作を個別に設定します。 前回ご紹介したrsc_defaultsコマンドで指定できるresource-stickinessやmigration-thresholdパラメータを使用できます。
RAに渡すパラメータ RAがリソースの制御のためにパラメータを必要とする場合、「パラメータ名="値"」の形式でここで指定します。 例えばファイルシステムをマウント・監視するリソース(ocf:heartbeat:Filesystem)の場合、ファイルシステムタイプ、マウントポイント、対象デバイスといったような情報をパラメータで与えます。 Dummy RAのように、動作にパラメータを必要としないRAの場合、記述は必要ありません。 crmコマンドに"ra info RA名"と引数を付与すると、当該RAのパラメータを含む、簡単なマニュアルが表示されます。この表示も参考にしてください。 
 # crm ra info ocf:heartbeat:Filesystem
 RAの簡易説明...
オペレーション時の設定 リソースの起動(start)、停止(stop)、監視(monitor)の各オペレーション時のタイムアウト等を「設定="値"」の形式で設定します。よく使用するのは以下の設定です。
interval
オペレーションの間隔を秒で指定します。開始、停止のように繰り返さないオペレーションの場合、0を指定します。
timeout
オペレーションが完了するのを待つ最大時間を秒で指定します。この時間を過ぎてもオペレーションが成功しない場合、失敗とみなします。
on-fail
オペレーションが失敗した場合の動作を指定します。 よく使用するのは以下の動作です。
  • block ：それ以降のあらゆるクラスタ動作をそのままの状態で中止します。
  • restart：このリソースの再起動（停止→起動）を試みます。他のノードへ再配置される場合があります。再起動に失敗した場合、再起動を繰り返し試みます。
  • fence ：STONITH機能を使用して、対象ノードの強制停止を試みます。当該リソースは他のノードへ再配置されます。STONITH機能が無効の場合、指定することはできません。
  • ignore ：オペレーションの失敗を無視し、このリソースに対する動作以外のクラスタ動作を継続します。
  • stop ：このリソースの停止を試みます。他のノードへの再配置はされません。停止に失敗した場合、停止を繰り返し試みます。

以下の部分は、リソース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コマンドの書式は以下です。

書式 group グループID リソースID...
設定項目 グループID グループの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
リソースID グループ化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。

以下部分は、リソース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コマンドの書式は以下です。

書式 clone クローンリソースID リソースID...     [meta クローンリソース動作設定...]
設定項目 クローンリソースID クローンリソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。
リソースID クローン化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。
クローンリソース動作設定 クローンリソースの動作に関する設定を「設定名="値"」という書式で記述します。 以下のような設定が可能です。
  • clone-max :クラスタ全体で、いくつリソースを起動するかを指定します。デフォルトはクラスタに含まれるノード数です(つまり全ノードで当該リソースが起動します)。
  • clone-node-max:1ノードで当該リソースがいくつ起動するかを指定します。デフォルトは1です。

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

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

 

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

    1. dummy1, dummy2という名前のリソースをgrpという名前のgroup(グループ)にします。
    • →primitiveでdummy1, dummy2を定義し、groupでグループ化しています。
    1. dummy3という名前のリソースをclnDummyという名前のclone(クローン)リソースとし、両マシンで起動します。
    • →cloneコマンドでクローンリソースを定義しています。clone-maxを指定していないので両(全)ノードで起動します(デフォルト)。
    1. 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を作成する場合も、この仕様に準拠する必要があります。詳細は公式マニュアルを参照してください。

■実験1 グループにリソースを追加してみる

グループにリソースを追加してみます。起動順がどうなるかにも注目です。

手順1)

例のCRMに以下の設定を加えて、リソース(resource4)を追加します。

primitive resource4 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コマンドを以下のように書き換え、resource4をgrpに追加します。

group grp \
    resource4 \
    resource1 \
    resource2

手順2)

修正したCRMファイルをPacemakerに反映します。 前回記事2ページ目の手順2～4を実行します。

crm_mon -rfAの実行結果が以下のようになればOKです。

～略～
Online: [ pm01 pm02 ]

Full list of resources:

 Resource Group: grp
     resource4  (ocf::heartbeat:Dummy): Started pm01  ★
     resource1  (ocf::heartbeat:Dummy): Started pm01
     resource2  (ocf::heartbeat:Dummy): Started pm01
 Clone Set: clnResource
     Started: [ pm01 pm02 ]

Node Attributes:
* Node pm01:
    + pm02-eth1                         : up
    + pm02-eth2                         : up
* Node pm02:
    + pm01-eth1                         : up
    + pm01-eth2                         : up

Migration summary:
* Node pm01:
* Node pm02:

★部分で、resource4がgrpに新たに加わったことがわかります。

手順3)

ログで、リソースの起動の順序を確認します。 Pacemakerのログは/var/log/ha-log に出力されます。※ pm01のha-logを以下のようにgrepすると、pm01でのリソースの起動処理の開始のみをフィルタリングできます。 Pacemaker-1.0系と1.1系でログの形式が異なるため、それぞれの場合を示します。

Pacemaker-1.0系の場合

# grep -e "lrmd.*rsc:.*start" /var/log/ha-log
Oct  7 11:51:04 pm01 lrmd: [2400]: info: rsc:resource3:1 start[6] (pid 2483)
Oct  7 11:51:14 pm01 lrmd: [2400]: info: rsc:resource4 start[8] (pid 2495)  ★1
Oct  7 11:51:21 pm01 lrmd: [2400]: info: rsc:resource1 start[10] (pid 2505) ★2
Oct  7 11:51:29 pm01 lrmd: [2400]: info: rsc:resource2 start[12] (pid 2522) ★3

Pacemaker-1.1系の場合

# grep -e "Operation .*_start_" /var/log/ha-log
Mar 23 14:35:35 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource3_start_0: ok ～略～
Mar 23 14:35:37 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource4_start_0: ok ～略～ ★1
Mar 23 14:35:39 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource1_start_0: ok ～略～ ★2
Mar 23 14:35:43 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource2_start_0: ok ～略～ ★3

★1,2,3より、grpのメンバーは、resource4 → resource1 → resource2 と、定義した順に起動していることが確認できます。 resource3 が真っ先に起動したことも読み取れますが、そのからくりは次回以降で説明します。

※ha-logはそれぞれのノードで出力され、それぞれ当該ノードでのイベントのみ記録しています。

■実験２ グループのうち１つを故障させてみる

グループのうち１つを故障させてみます。他のグループメンバがどうなるかに注目です。

手順1)

前回記事2ページ目の手順2～4を実行し、Pacemakerを起動します。 CRMファイルは実験1のものを使用します。

手順2)

pm01(resource1が稼働しているノード)で以下コマンドを実行し、resource1を故障させます。

[root@pm01 ~]# rm -f /var/run/resource-agents/Dummy-resource1.state

crm_mon -rfAの実行結果が以下のように落ち着けばOKです。

～略～
Online: [ pm01 pm02 ]

Full list of resources:

 Resource Group: grp
     resource4  (ocf::heartbeat:Dummy): Started pm02　★1
     resource1  (ocf::heartbeat:Dummy): Started pm02　★2
     resource2  (ocf::heartbeat:Dummy): Started pm02　★3
 Clone Set: clnResource
     Started: [ pm01 pm02 ]

Node Attributes:
* Node pm01:
    + pm02-eth1                         : up
    + pm02-eth2                         : up
* Node pm02:
    + pm01-eth1                         : up
    + pm01-eth2                         : up

Migration summary:
* Node pm01:
   resource1: migration-threshold=1 fail-count=1
* Node pm02:

Failed actions:
    resource1_monitor_10000 (node=pm01, call=11, rc=7, status=complete): not running　★4

resource1の故障(★4)に伴い、groupのメンバであるresource2,4もpm02にF/Oしました。(★1,2,3)

手順3)

crm_mon -rfAコマンドの表示が落ち着いたら、F/Oのためにpm01側で行われたリソース停止の順番をログで確認します。 pm01のha-logを以下のようにgrepし、リソースの停止・監視(故障検知)のみをフィルタリングします。

Pacemaker-1.0系の場合

# grep -e "lrmd.*rsc:.*stop" /var/log/ha-log
Oct  7 12:34:53 pm01 lrmd: [5211]: info: rsc:resource2 stop[14] (pid 5409)　★1
Oct  7 12:34:56 pm01 lrmd: [5211]: info: rsc:resource1 stop[15] (pid 5418)　★2
Oct  7 12:35:00 pm01 lrmd: [5211]: info: rsc:resource4 stop[16] (pid 5425)　★3

Pacemaker-1.1系の場合

# grep -e "Operation .*_stop_" /var/log/ha-log
Mar 23 14:39:32 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource2_stop_0: ok ～略～ ★1
Mar 23 14:39:34 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource1_stop_0: ok ～略～ ★2
Mar 23 14:39:36 pm01 crmd[21705]:  notice: process_lrm_event: Operation resource4_stop_0: ok ～略～ ★3

★1,2,3より、resource2 → resource1 → resource4の順で停止していることが確認できます。

■実験３ op要素のmonitorのintervalを0にし故障させてみる

op要素のmonitorのintervalを「0s」と変更し、故障させてみます。F/Oするでしょうか？

手順1)

先ほど修正したCRMファイルのprimitive resource1部分を以下のように修正します。 (「op monitor～」のintervalを「0s」と変更します。)

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

手順2)

修正したCRMファイルをPacemakerに反映します。 前回記事2ページ目の手順2～4を実行します。

手順3)

pm01で以下コマンドを実行し、resource1を故障させます。

[root@pm01 ~]# rm -f /var/run/resource-agents/Dummy-resource1.state

～略～
Online: [ pm01 pm02 ]

Full list of resources:

 Resource Group: grp
     resource4  (ocf::heartbeat:Dummy): Started pm01
     resource1  (ocf::heartbeat:Dummy): Started pm01
     resource2  (ocf::heartbeat:Dummy): Started pm01
 Clone Set: clnResource
     Started: [ pm01 pm02 ]

Node Attributes:
* Node pm01:
    + pm02-eth1                         : up
    + pm02-eth2                         : up
* Node pm02:
    + pm01-eth1                         : up
    + pm01-eth2                         : up

Migration summary:
* Node pm01:
* Node pm02:

先ほどとは違い、crm_mon -rfAの表示に変化はなく、故障が検知されておらず、F/Oもしないことがわかります。 これはop monitor行のintervalを「0s」としたことで、resource1に対する監視(monitor)オペレーションが実行されなくなり故障を検知しなくなったためです。

   

今回はCRM設定ファイルの中間部分、リソース定義を読み解きました。 次回は、いよいよCRMファイルの残りの部分を読み解き、CRMファイルの全貌が明らかになります。 次回もおつきあいいただければ幸いです。