(10)高度なリソースタイプ

グループ – 構文上のショートカット

クラスタを利用するうえで頻繁に必要になる要素として複数のリソースを一まとめにするリソースセットがあります。これは同じ場所でリソースを順番に起動して、停止する時にはその逆の順番で行うといった操作が行えます。

この動作は、groupを使用して設定します。

例：2つのprimitiveリソースのあるグループ

<group id="shortcut">
   <primitive id="Public-IP" class="ocf" type="IPaddr" provider="heartbeat">
    <instance_attributes id="params-public-ip">
       <nvpair id="public-ip-addr" name="ip" value="192.0.2.2"/>
    </instance_attributes>
   </primitive>
   <primitive id="Email" class="lsb" type="exim"/>
</group>

上記の例ではリソースは２つだけですが、group内に記載できるリソース数に制限はありません。

groupには以下の効果があります。

• リソースは記載された順に起動する(Public-IP→Email)
• リソースの停止する順番は記載順の逆(Email→Public-IP)

リソースがどのノードでも起動することができない場合は、後続リソースも起動できません。

• もしPublic-IPが起動できなければ、Emailも起動しない
• しかし、Emailが起動できない場合にはPublic-IPは影響を受けない

グループプロパティー

groupリソースのプロパティーを以下のように設定できます。

グループオプション

groupはprimitiveリソースからpriority, target-role, is-managedプロパティーを継承します。

グループインスタンス属性

groupにはインスタンス属性がありません。しかし、groupの対象に行われた設定はgroupの子にも引き継がれます。

グループの内容

groupはクラスタリソースのみを記載することができます。groupリソースの子を参照したい場合には、そのidを記載してください。

グループ制約

制約条件の中でgroupの子を参照することは可能であり、通常group自身から参照することは適切な方法です。

例：groupの関係する制約

<constraints>
    <rsc_location id="group-prefers-node1" rsc="shortcut" node="node1" score="500"/>
    <rsc_colocation id="webserver-with-group" rsc="Webserver" with-rsc="shortcut"/>
    <rsc_order id="start-group-then-webserver" first="Webserver" then="shortcut"/>
</constraints>

グループスティッキネス

stickinessはリソースが現在のノードに留まろうとする度合いを示しますが、groupでは付加的なものになります。group内のアクティブなリソースがgroup全体のstickinessの値に影響します。例えばdefault resource-stikkinessが100で、group内に7つのリソースがあり、そのうち5つがアクティブだった場合にはその時のgroupのstickinessの値は500になります。

クローン – 複数ホストでリソースをアクティブに

cloneは当初複数ノードでIPアドレスのリソースを起動し、クラスタ間で負荷分散することを目的にしていました。しかし、分散ロックマネージャーやフェンシング機能、OCF2を管理するためにも有用です。

リソースエージェントが対応していればどのようなリソースでもクローンすることができます。

cloneリソースには次の3種類があります。

• Anonymous
• Globally unique
• Stateful

Anonyumousクローンはもっとも単純なもので、どこでもリソースが同じように起動します。マシンあたりcloneリソースのコピーは１つだけ起動できます。

Globally uniqueクローンは個別のエンティティです。あるマシンで動作するcloneは別のマシーンで動作するcloneと同じではありませんし、同じマシンで動作する２つのcloneも同じではありません。

Statefulクローンについては後述します。

クローンプロパティー

以下のようにcloneリソースにオプションを付与できます。

クローンオプション

primitiveリソースから継承されるオプションは、priority, target-role, is-managedです。

クローンインスタンス属性

cloneにはインスタンス属性がありません。ただしcloneの子には継承されます。

クローンコンテンツ

cloneは1つのprimitiveまたはgroupリソースを含んでいる必要があります。

注意：cloneの子は参照してはいけません。もしその必要があるような場合には別の構成を考えてください。

クローンの制約条件

通常、cloneはアクティブなクラスタノードあたり1つのコピーを持ちます。もしそうでない場合には、位置制約を使用してクラスタがどのノードにコピーをアサインするかを設定します。制約条件は、cloneのIDが使用されているのでなければprimitiveリソースと同じように記載します。

cloneを含む制約条件の例：

<constraints>
    <rsc_location id="clone-prefers-node1" rsc="apache-clone" node="node1" score="500"/>
    <rsc_colocation id="stats-with-clone" rsc="apache-stats" with="apache-clone"/>
    <rsc_order id="start-clone-then-stats" first="apache-clone" then="apache-stats"/>
</constraints>

cloneのorder制約については少々異なります。上記の例ではapache-statsは起動する必要のある全てのapache-cloneのコピーが起動するまで待ちます。1つもコピーが起動できない場合にのみapache-statsがアクティブになりません。また、apache-ststsが停止するまで、そのコピーは停止しません。

cloneを持つprimitiveまたはgroupリソースのコロケーションは、リソースがクローンのアクティブなコピーのあるマシン上で動作するということを意味します。クラスタは、どこでクローンが動作しているか、およびそのリソースの位置選好に基づいてコピーを選択します。

クローン間のコロケーションも可能です。クローンAを別のクローンBとコロケーションする場合、Aの配置場所として使えるものは、Bがアクティブな(またはアクティブになる)ノードに制限されます。

クローンスティッキネス

安定的な動作を行うために、デフォルトでは比較的クラスタ間移動が発生しない設定になっています。resource-stickinessを設定していない場合は1が値として使用されます。

注記：globally uniqueクローンの場合には、他に動作できるノードがあるにも関わらず、１つのノードで複数のクローンが動作する状態になる場合があります。一度スタンバイモードにしてアクティブに戻すケースが典型的でしょう。このような場合には一時的にresource-stickinessを0にして、ノードが移動した後で1に戻すのがよいでしょう。

クローンリソースエージェントの要件

Anonymousクローンは、通常のリソースエージェントであれば追加で何も必要としません。

globally uniqueクローンは通常のリソースエージェントに追加で必要な部分があります。特に、ノードで正確にそのインスタンスがアクティブな場合にのみ${OCF_SUCCESS}で応答する必要があります。それ以外のプローブは${OCF_NOT_RUNNING}(または失敗した場合には他のエラーコード)で応答しなければいけません。

個々のクローンはコロンの後に数字を付けて区別します。例：apache:2

リソースエージェントはOCF_RESKEY_CRM_meta_clone_max環境変数で何個のコピーがあるかを調べ、またOCF_RESKEY_CRM_meta_cloneでどのコピーであるかを調べます。

リソースエージェントは(OCF_RESKEY_CRM_meta_cloneに基づいて)何番目のインスタンスがアクティブであるかを予測するべきではありません。アクティブなコピーは常に連続した番号ではなく、また0から始まるわけでもありません。

クローン通知

通知を行うにはnotifyアクションが実装されている必要があります。実装されていれば、通知アクションには追加のコンテキストと組み合わせて現在の状態とこれから行われる処理を判別するための追加の変数が渡されます。

クローン通知アクションで与えられる環境変数

変数は対で渡されます。例えばOCF_RESKEY_CRM_meta_notify_start_resourceとOCF_RESKEY_CRM_meta_notify_start_unameは空白スペースで区切られた配列としてです。

OCF_RESKEY_CRM_meta_notify_inactive_resourceは非アクティブなリソースがどのノードにもないために、一致するuname変数が存在しないので例外です。

clone:0がsles-1で起動し、clone:2がsles-3で起動し、clone:3がsles-2で起動することを示すのは以下のようになります。

OCF_RESKEY_CRM_meta_notify_start_resource="clone:0 clone:2 clone:3"
OCF_RESKEY_CRM_meta_notify_start_uname="sles-1 sles-3 sles-2"

適切な通知環境変数の処理

通知前(stop):

動作中リソース:     $OCF_RESKEY_CRM_meta_notify_active_resource
停止中リソース:     $OCF_RESKEY_CRM_meta_notify_inactive_resource
起動するリソース: $OCF_RESKEY_CRM_meta_notify_start_resource
停止するリソース: $OCF_RESKEY_CRM_meta_notify_stop_resource

通知後(stop)/通知後(start):

動作中リソース:     $OCF_RESKEY_CRM_meta_notify_active_resource
     　　 　 　　        minus $OCF_RESKEY_CRM_meta_notify_stop_resource
停止中リソース:     $OCF_RESKEY_CRM_meta_notify_inactive_resource
    　　  　　　         plus $OCF_RESKEY_CRM_meta_notify_stop_resource
起動したリソース: $OCF_RESKEY_CRM_meta_notify_start_resource
停止したリソース: $OCF_RESKEY_CRM_meta_notify_stop_resource

通知後(start):
動作中リソース:  $OCF_RESKEY_CRM_meta_notify_active_resource
                                   minus $OCF_RESKEY_CRM_meta_notify_stop_resource
                                   plus $OCF_RESKEY_CRM_meta_notify_start_resource
停止中リソース:    $OCF_RESKEY_CRM_meta_notify_inactive_resource
                                   plus $OCF_RESKEY_CRM_meta_notify_stop_resource
                                    minus $OCF_RESKEY_CRM_meta_notify_start_resource
起動したリソース: $OCF_RESKEY_CRM_meta_notify_start_resource
停止したリソース: $OCF_RESKEY_CRM_meta_notify_stop_resource

マルチステート – 複数モードのあるリソース

マルチステートリソースはcloneリソースの一種で、ロールと呼ばれる２つの状態のうちのどちらかになることができます。ロールは通常マスターとスレーブと呼ばれます。起動した際には、最初に必ずスレーブ状態になります。

マルチステートプロパティー

マルチステートリソースのプロパティー

マルチステートオプション

オプションはprimitiveリソースから次のものを継承します。: priority, target-role, is-managed

オプションはcloneリソースから次のものを継承します。: clone-max, clone-node-max, notify, globally-unique, ordered, interleave

マルチステートリソース特有の設定オプション

マルチステートインスタンス属性

マルチステートリソースはインスタンス属性を持ちません。ただし、もしここで何かを設定した場合にはマスターの子に継承されます。

マルチステートのコンテンツ

マスターにはprimitiveリソースかgroupリソースが含まれている必要があります。

注意：マスターの子の名前を参照することはできません。

マルチステートリソースのモニター

通常のモニター処理では、マルチステートリソースに対しては十分ではありません。リソースが動作しているかどうかだけではなく、意図したロールになっているかどうかを確認する必要があるためです。

そこで、２つのモニターを設定します。1つはスレーブ状態を監視し、もう1つはrole=”master”と設定してマスターのロールを監視します。

例：

<master id="myMasterRsc">
   <primitive id="myRsc" class="ocf" type="myApp" provider="myCorp">
    <operations>
     <op id="public-ip-slave-check" name="monitor" interval="60"/>
     <op id="public-ip-master-check" name="monitor" interval="61" role="Master"/>
    </operations>
   </primitive>
</master>

重要 : すべてのモニター動作が異なるインターバルであることが必要です。Pacemakerはリソースと間隔によってしか区別することができません。そのためもしマスター/スレーブリソースが同じ間隔であった場合には正しい結果を得ることができません。

マルチステートの制約文

多くの場合、マルチステートリソースはアクティブなノードに1つのコピーを持ちます。そうでない場合にはどのノードを選好してコピーをアサインするかlocation制約で指定することができます。制約においてはマスターのIDを使用することを除いてはprimitiveリソースの場合と同じです。

マルチステートリソースの制約を行う際には、cloneと同様に扱うことができます。ただし、order制約のfist-actionおよび/またはthen-actionフィールドにpromoteまたはdemoteを設定できること、またcolocation制約にはrsc-roleやwith-rsc-roleフィールドなどが含まれる点が異なります。

マルチステートリソースでの追加のcolocation制約

colocation setでのマルチステートリソースを使用する

マルチステートリソースと関連するcolocation setオプション

order setでマルチステートリソースを使用する

マルチステートリソースと関連するorder setオプション

マルチステートのスティッキネス

通常のcloneリソースと同様のstikinessになります。(10.2.6のクローンスティッキネスを参照)

昇格するリソースインスタンス

起動処理ではリソースエージェントはcrm_masterユーティティを呼び出します。このユーティリティはホストとリソースを検出して昇格時にこれを考慮します。そしてmaster-max, master-node-maxと合わせて最も選好性が高いいスタンスを昇格させます。

マルチステートリソースエージェントの要件

マルチステートリソースはcloneリソースの拡張であるため、cloneリソースの同様の要件が必要です。またそれに加えてdemoteとpromoteの2つのアクションに対応している必要があります。startやstopのように、成功したら${OCF_SUCCESS}を返し、失敗したら関連するエラーコードを返すことが必要です。

どのような状態(state)にすることもできますが、ただし起動した際にはslaveの状態であり、それからどのインスタンスをmasterに昇格するかが判断されることになります。

また、cloneリソースの要件に加えて、エージェント自身の現在の状態(state)を正確に通知できることが必要です。クラスタはエージェントから通知される状態(state)とロールの情報に頼っており、クラスタからエージェントにそれらが通知されることはありません。

OCFリターンコードが示すロールの状態

マルチステートの通知

クローンと同様、通知アクションが実装されている必要があります。通知アクションは多くの追加変数を渡し、これらによって現在とこれから移行するクラスタ状態の計算が行われます。

マルチステート通知アクションの環境変数

バンドル – 隔離環境

Pacemaker(1.1.17以降)では、インフラに対して隔離環境を組み込むための構文を用意しています。それがバンドルです。現在サポートしている隔離環境はDockerとrktコンテナです。

コンテナ化したWebサーバの例

<bundle id="httpd-bundle">
   <docker image="pcmk:http" replicas="3"/>
   <network ip-range-start="192.168.122.131"
            host-netmask="24"
            host-interface="eth0">
      <port-mapping id="httpd-port" port="80"/>
   </network>
   <storage>
      <storage-mapping id="httpd-syslog"
                       source-dir="/dev/log"
                       target-dir="/dev/log"
                       options="rw"/>
      <storage-mapping id="httpd-root"
                       source-dir="/srv/html"
                       target-dir="/var/www/html"
                       options="rw"/>
      <storage-mapping id="httpd-logs"
                       source-dir-root="/var/log/pacemaker/bundles"
                       target-dir="/etc/httpd/logs"
                       options="rw"/>
   </storage>
   <primitive class="ocf" id="httpd" provider="heartbeat" type="apache"/>
</bundle>

バンドルのプロパティー

Docker/rktプロパティー

Pacemakerでバンドルを設定する前にdocker/rktとdocker/rktイメージをバンドルを動作させるすべてのノードにインストールしておく必要があります。また、Pacemakerはdockerコンテナ管理のためにocf:heartbeat:dockerを必要とします。rktコンテナの場合にはocf:heartbeat:rktが必要です。

バンドルのdocker/rkt要素のプロパティー

バンドルのネットワークプロパティー

バンドルには<network>要素で組み込むことができます。使用できるネットワークプロパティーは以下です。

注記: ip-range-startを使用すると、Pacemakerは自動的にコンテナ内の/etc/hostsに各レプリカと、それに対してアサインしたIPを記載します。レプリカはバンドルIDとダッシュ、0から始まる整数値で命名されます。例えばバンドルがhttpd-bundleでreplicas=2であれば、そのコンテナ名はhttpd-budle-0とhttpd-bundle-1になります。

また、<network>要素には<port-mapping>要素をオプションで追加することができます。

注記：バンドルにprimitiveが含まれている場合、Pacemakerは自動的にcontrol-portをマッピングするためport-mappingにポート番号を設定する必要はありません。

バンドルのストレージプロパティー

バンドルには<storage>要素をオプションで設定できます。<storage>要素にはそれ自体のプロパティーはありませんが、<storage-mapping>要素を設定することができます。

storage-mapping要素のプロパティー

注記：Pacemakerはホスト上にすでにソースディレクトリがなくなっていた場合の挙動は定義しません。しかしながら、そのような場合にはコンテナまたはリソースエージェントがそのソースディレクトリを作成することが求められています。

注記：バンドルにprimitiveが含まれている場合、Pacemakerは自動的にsource-dir=/etc/pacemaker/authkey target-dir=/etc/pacemaker/authkeyとsource-dir-root=/var/log/pacemaker/bundles target-dir=/var/logと同等のものをコンテナにマッピングするためこれのパスをstorage-mappingに設定する必要はありません。

重要：PCMK_authkey_location環境変数はクラスタ内のすべてのノードの/etc/pacemaker/authkeyのデフォルト以外のものは指定すべきではありません。

バンドルプリミティブ

バンドルにはオプションで1つの<primitive>リソースを持たせることができます。プリミティブには通常operations, インスタンス属性、メタ属性の定義ができます。

バンドルにプリミティブリソースがある場合、Pacemaker Remoteデーモンがコンテナイメージ内にあり、最低1つのip-rante-startまたはcontrol-portがバンドル内に設定されている必要があります。Pacemakerはocf:pacemaker:remoteリソースをコネクション用に作成してコンテナ内でPacemaker Remoteを起動し、Pacemaker Remoteを通じてプリミティブリソースを監視・管理します。

重要：バンドル内にprimitiveのあるコンテナでは、クラスタノードのPacemakerがコンテナ内のPacemaker Remoteと通信するためにアクセス可能なネットワーク環境が必要です。例えばDockerオプションの—net=noneはprimitiveで使用するべきではありません。デフォルト(コンテナ内の個別のネットワークを使用する)ではip-rante-startと組み合わせて使用します。Dockerオプションの—net=hostを使用する (コンテナがホストネットワークを共有する) 場合には、一意のcontrol-portをバンドルごとに指定する必要があります。また、すべてのファイアウォールでcontrol-portへのアクセスを許可する必要があります。

バンドルノード属性

バンドルにprimitiveがある場合、プリミティブのリソースエージェントはmasterスコアなどノード属性を指定したいケースがあるでしょう。しかしながら、コンテナの場合にはどのノードが属性を持つか明確ではありません。

バンドルメタ属性

バンドルに設定するすべてのメタ属性は、バンドルのプリミティブと、Pacemakerがプリミティブ用に作成したすべてのリソースに継承されます。

バンドルの制約

バンドルが管理されていない間、またはクラスタがメンテナンスモードの時にPacemakerを再起動するとバンドルの障害が発生することがあります。

バンドルはクローンできず、グループに含めることができません。これはバンドルのプリミティブと、Pacemakerがプリミティブ用に作成したすべてのリソースでも同様です。

バンドルのプリミティブはインスタンス属性、ユーティリティ属性、オペレーションを持つことができますが、バンドル自体はそれらを持つことができません。

プリミティブを持つバンドルは、バンドルが個別のcontrol-portを持っている場合にのみ、Pacemaker Remoteノードで動作できます。