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


変更履歴

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

■はじめに

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

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

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

 

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

  • 1. STONITHは無効です。(その1で読み解き済み)
  • 2. 1回のリソース故障でF/Oします。自動フェイルバックはしません。(その1で読み解き済み)
  • 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コマンドの概要と書式を以下に示します。

概要 リソース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番目の一部の制御が理解できました。

  • 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」の3つのメソッドが定義されていること。
  • 「start」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • サービスが停止している場合:サービスを起動し0を返す。
    • サービスが(すでに)起動している場合:0を返す。
  • 「stop」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • サービスが(すでに)停止している場合:0を返す。
    • サービスが起動している場合:サービスを停止し、0を返す。
  • 「status」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。
    • サービスが停止している場合:3を返す。
    • サービスが起動している場合:0を返す。
  • それぞれ失敗した場合は、0および3以外のエラーコードを返すこと。
独自のRAを作成する場合も、この仕様に準拠する必要があります。詳細は公式マニュアルを参照してください。

Pages: 1 2

Comments are closed.