今回は、3,4番目および5番目の一部(下線部)を読み解きます。今回注目するのは以下の部分です。primitiveの3コマンドを使用し、どんなリソースを使用するかを定義しています。■primitiveでリソースを定義primitiveコマンドはクラスタ内で使用したい個々のリソースの定義を行います。primitiveコマンドの概要と書式を以下に示します。概要リソースIDおよびリソースエージェント(RA)を指定し、クラスタ内で使用するリソースを定義します。リソースの起動、監視、停止それぞれの制御時のタイムアウトおよびそれぞれの制御が失敗したときの挙動も指定します。リソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。CRMファイルの他の箇所でこのリソースを示す場合やcrm_monコマンドでの表示等にも使用します。使用するRAの種類とファイル名を「:」で区切った記法で指定します。使用するパターンは以下です。配置されたスクリプトをRAとして使用します。配置されたスクリプトをRAとして使用します。配置されたスクリプトをRAとして使用します。Linuxに付属のinitスクリプトをRAとして使用することができます。initスクリプトがLSBと呼ばれる仕様に準拠している必要があります。stonith:プラグインファイル名(パス)STONITH機能を使用する場合、STONITHの方法に応じた専用のプラグインを指定します。配置されたプログラムを使用します。ocf:~は「:」で区切られた3つの記述の1,2番目でRAの種別を、3番目がRAのファイル名を示します。lsb:~およびstonith:~は、「:」で区切られた1番目でRAの種別を、2番目がスクリプト/プログラムのファイル名です。※Pacemakerをインストールすると、このディレクトリに様々なRA、プラグインが配置されます。リソースの故障時等の動作を個別に設定します。前回ご紹介したrsc_defaultsコマンドで指定できるresource-stickinessやmigration-thresholdパラメータを使用できます。RAがリソースの制御のためにパラメータを必要とする場合、「パラメータ名=”値”」の形式でここで指定します。ファイルシステムをマウント・監視するリソース(ocf:heartbeat:Filesystem)の場合、ファイルシステムタイプ、マウントポイント、対象デバイスといったような情報をパラメータで与えます。RAのように、動作にパラメータを必要としないRAの場合、記述は必要ありません。RA名”と引数を付与すると、当該RAのパラメータを含む、簡単なマニュアルが表示されます。この表示も参考にしてください。リソースの起動(start)、停止(stop)、監視(monitor)の各オペレーション時のタイムアウト等を「設定=”値”」の形式で設定します。使用するのは以下の設定です。intervalオペレーションの間隔を秒で指定します。開始、停止のように繰り返さないオペレーションの場合、0を指定します。timeoutオペレーションが完了するのを待つ最大時間を秒で指定します。この時間を過ぎてもオペレーションが成功しない場合、失敗とみなします。on-failオペレーションが失敗した場合の動作を指定します。使用するのは以下の動作です。:それ以降のあらゆるクラスタ動作をそのままの状態で中止します。restart:このリソースの再起動(停止→起動)を試みます。他のノードへ再配置される場合があります。再起動に失敗した場合、再起動を繰り返し試みます。:STONITH機能を使用して、対象ノードの強制停止を試みます。当該リソースは他のノードへ再配置されます。STONITH機能が無効の場合、指定することはできません。:オペレーションの失敗を無視し、このリソースに対する動作以外のクラスタ動作を継続します。:このリソースの停止を試みます。他のノードへの再配置はされません。停止に失敗した場合、停止を繰り返し試みます。RAとするリソースを定義していることになります。開始・停止のタイムアウトは300秒、監視のタイムアウトは60秒です。開始および監視に失敗したときはリソース再起動、停止に失敗したときはクラスタのそれ以後の動作を中止します。■groupでリソースをひとまとめにgroupは、primitiveで定義した個々のリソースをグループ化します。グループ化したリソースに対しては、以下の制御が行われます。常に同一サーバで起動する。groupコマンドに指定した順にリソースを起動する。グループ化は、あるサービスを提供するのに、複数のリソースを同時に使用しなければならない場合に使用します。データベースをクラスタ化する場合、データベースそのものの他に、共有ディスクや、アクティブ側のデータベースへアクセスするためのIPアドレスなどを同時に起動しなければなりません。共有ディスクはデータベースより先に起動(マウント)しなければなりません(さもないとデータファイルがなくデータベースを起動できないでしょう)。groupコマンドの書式は以下です。グループの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。グループ化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。resource1およびresource2をグループ化しています。グループIDはgrpです。順で起動し、その逆順で停止します。■cloneで複数ノードへリソース複製cloneは、primitiveで定義した個々のリソースをクローン化します。クローン化したリソースは、通常のリソースと異なり、複数のノード上で同時に起動します。リソースが複製(クローン)され、複数ノードへ配置されるイメージです。ノードのネットワーク疎通を確認するリソース(Pacemaker-1.0系の場合「ocf:pacemaker:pingd」、1.1系の場合「ocf:pacemaker:ping」)を使用する場合、アクティブ側ノードはもちろん、スタンバイ側ノードでもいつでもサービスが提供できるよう、常にアクティブ側と同じようにネットワーク疎通を確認しておく必要があります。このようなときのためにcloneは用意されています。cloneコマンドの書式は以下です。クローンリソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。クローン化する対象リソースをprimitiveコマンドで定義したリソースIDで指定します。クローンリソースの動作に関する設定を「設定名=”値”」という書式で記述します。以下のような設定が可能です。:クラスタ全体で、いくつリソースを起動するかを指定します。デフォルトはクラスタに含まれるノード数です(つまり全ノードで当該リソースが起動します)。clone-node-max:1ノードで当該リソースがいくつ起動するかを指定します。resource3をクローン化しています。クローンリソースIDはclnResourceです。clone-node-maxは指定していないため、全ノード(pm01,pm02)で1つずつresource3リソースが起動します。resource3さぁ、以上で、3,4番目および5番目の一部の制御が理解できました。dummy2という名前のリソースをgrpという名前のgroup(グループ)にします。dummy2を定義し、groupでグループ化しています。dummy3という名前のリソースをclnDummyという名前のclone(クローン)リソースとし、両マシンで起動します。→cloneコマンドでクローンリソースを定義しています。clone-maxを指定していないので両(全)ノードで起動します(デフォルト)。dummy1,2,3のリソースは、必ずdummy3(clnDummy)→dummy1→dummy2の順で起動します。→dummy1→dummy2の順はこれらがgroupのためです。(dummy3の起動順のからくりは次回説明します。)次ページでこれらの動作を実験で確認します。Baseと呼ばれる、Linuxの内部構造の仕様です。PacemakerがinitスクリプトをRAとする場合、このLSBに準拠していることを前提に制御をおこないます。具体的には以下を前提としています。「start」「stop」「status」の3つのメソッドが定義されていること。「start」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。サービスが停止している場合:サービスを起動し0を返す。サービスが(すでに)起動している場合:0を返す。「stop」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。サービスが(すでに)停止している場合:0を返す。サービスが起動している場合:サービスを停止し、0を返す。「status」メソッドはサービス(リソース)の状態に応じ以下の動作および返り値を返すこと。サービスが停止している場合:3を返す。サービスが起動している場合:0を返す。それぞれ失敗した場合は、0および3以外のエラーコードを返すこと。独自のRAを作成する場合も、この仕様に準拠する必要があります。詳細は公式マニュアルを参照してください。