変更履歴
- 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コマンドの概要と書式を以下に示します。
| 概要 | リソースIDおよびリソースエージェント(RA)を指定し、クラスタ内で使用するリソースを定義します。 リソースの起動、監視、停止それぞれの制御時のタイムアウトおよびそれぞれの制御が失敗したときの挙動も指定します。 |
|
|---|---|---|
| 書式 |
primitive リソースID RA名 [meta リソースの動作設定…] [params RAに渡すパラメータ…] [op start|stop|monitor オペレーション時の設定…] |
|
| 設定項目 | リソースID | リソースの名前を任意の英数字で定義します。クラスタ内で一意でなければなりません。CRMファイルの他の箇所でこのリソースを示す場合やcrm_monコマンドでの表示等にも使用します。 |
| RA名 | 使用するRAの種類とファイル名を「:」で区切った記法で指定します。よく使用するパターンは以下です。
ocf:～は「:」で区切られた3つの記述の1,2番目でRAの種別を、3番目がRAのファイル名を示します。 |
|
| リソースの動作設定 | リソースの故障時等の動作を個別に設定します。 前回ご紹介したrsc_defaultsコマンドで指定できるresource-stickinessやmigration-thresholdパラメータを使用できます。 |
|
| RAに渡すパラメータ | RAがリソースの制御のためにパラメータを必要とする場合、「パラメータ名=”値”」の形式でここで指定します。 例えばファイルシステムをマウント・監視するリソース(ocf:heartbeat:Filesystem)の場合、ファイルシステムタイプ、マウントポイント、対象デバイスといったような情報をパラメータで与えます。 Dummy RAのように、動作にパラメータを必要としないRAの場合、記述は必要ありません。 crmコマンドに”ra info RA名”と引数を付与すると、当該RAのパラメータを含む、簡単なマニュアルが表示されます。この表示も参考にしてください。 |
|
| オペレーション時の設定 | リソースの起動(start)、停止(stop)、監視(monitor)の各オペレーション時のタイムアウト等を「設定=”値”」の形式で設定します。よく使用するのは以下の設定です。
|
|
以下の部分は、リソース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で指定します。 | |
| クローンリソース動作設定 |
クローンリソースの動作に関する設定を「設定名=”値”」という書式で記述します。 以下のような設定が可能です。
|
|
以下の部分は、リソース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以外のエラーコードを返すこと。
Comments are closed 
