Pacemaker 1.1 Configuration Explained – (10)高度なリソースタイプ

(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リソースのプロパティーを以下のように設定できます。

フィールド

説明

id

グループの一意な名前

グループオプション

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リソースにオプションを付与できます。

フィールド

説明

id

クローンの一意な名前

クローンオプション

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

フィールド

デフォルト

説明

clone-max

クラスタ内のノード数

起動するリソースの数

lone-max-node

1

1つのノードで起動できるリソースのコピーの数

clone-min

1

リソースを実行可能にするのを許可する前に、少なくともこの数のクローンインスタンスが実行可能であることが必要

notify

true

クローンの停止または起動する際、その前にすべてのコピーに通知し、成功後に再度通知する。指定できる値はfalse, true

globally-unique

false

個々のクローンのコピーが異なった挙動を行うかどうか。指定できる値はfalse, true

orderd

false

コピーを並列でなく順次起動するかどうか。指定できる値はfalse, true

interleave

false

クローンがオーダー制約で他のクローンに依存している場合に、他のクローンのすべてのインスタンスが起動するのを待つのではなく、他のクローンのローカルインスタンスが起動していれば起動するようにするかどうか。指定できる値はfalse, true

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

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_type

指定できる値 : pre, post

OCF_RESKEY_CRM_meta_notify_operation

指定できる値 : start, stop

OCF_RESKEY_CRM_meta_notify_start_resource

起動するリソース

OCF_RESKEY_CRM_meta_notify_stop_resource

停止するリソース

OCF_RESKEY_CRM_meta_notify_active_resource

動作中のリソース

OCF_RESKEY_CRM_meta_notify_inactive_resource

停止しているリソース

OCF_RESKEY_CRM_meta_notify_start_uname

リソースが起動するノード

OCF_RESKEY_CRM_meta_notify_stop_uname

リソースが停止するノード

OCF_RESKEY_CRM_meta_notify_active_uname

リソースが動作中のノード

変数は対で渡されます。例えば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リソースの一種で、ロールと呼ばれる２つの状態のうちのどちらかになることができます。ロールは通常マスターとスレーブと呼ばれます。起動した際には、最初に必ずスレーブ状態になります。

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

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

フィールド

説明

id

マルチステートリソース名

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

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

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

 

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

フィールド

デフォルト

説明

master-max

1

リソースのコピーのうちマスターになれる数

master-node-max

1

リソースのコピーのうち、1つのノードでマスターになれる数

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

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

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

マスターには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制約

フィールド

デフォルト

説明

rsc-role

started

rscオプションで指定したリソースのロールの指定をする追加の属性。指定できる値は:　Started, Master, Slave

with-rsc-role

started

with-rscオプションで指定したリソースのロールの指定をする追加の属性。指定できる値は:　Started, Master, Slave

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

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

フィールド

デフォルト

説明

role

started

セット内のすべてのメンバーがそうであるべきロール。指定できる値は: Starrted, Master, Slave

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

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

フィールド

デフォルト

説明

action

first-actionの値

セット内のすべてのメンバーに適用されるアクション。指定できる値は: start, stop, promote, demote

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

通常の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リターンコードが示すロールの状態

monitorのリターンコード

説明

OCF_NOT_RUNNING

停止

OCF_SUCCESS

動作中(Slave)

OCF_RUNNING_MASTER

動作中(Master)

OCF_FAILED_MASTER

失敗(Master)

Other

失敗(Slave)

マルチステートの通知

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

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

Variable

Description

OCF_RESKEY_CRM_meta_notify_type

指定できる値:pre,post

OCF_RESKEY_CRM_meta_notify_operation

指定できる値:start, stop

OCF_RESKEY_CRM_meta_notify_active_resource

動作中のリソース

OCF_RESKEY_CRM_meta_notify_inactive_resource

停止中のリソース

OCF_RESKEY_CRM_meta_notify_master_resource

Masterモードで動作中のリソース

OCF_RESKEY_CRM_meta_notify_slave_resource

Slaveモードで動作中のリソース

OCF_RESKEY_CRM_meta_notify_start_resource

起動するリソース

OCF_RESKEY_CRM_meta_notify_stop_resource

停止するリソース

OCF_RESKEY_CRM_meta_notify_promote_resource

昇格するリソース

OCF_RESKEY_CRM_meta_notify_demote_resource

降格するリソース

OCF_RESKEY_CRM_meta_notify_start_uname

リソースの起動するノード

OCF_RESKEY_CRM_meta_notify_stop_uname

リソースの停止するノード

OCF_RESKEY_CRM_meta_notify_promote_uname

リソースの昇格するノード

OCF_RESKEY_CRM_meta_notify_demote_uname

リソースの降格するノード

OCF_RESKEY_CRM_meta_notify_active_uname

リソースが動作中のノード

OCF_RESKEY_CRM_meta_notify_master_uname

Masterモードでリソースが動作中のノード

OCF_RESKEY_CRM_meta_notify_slave_uname

Slaveモードでリソースが動作中のノード

 

バンドル – 隔離環境

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>

 

バンドルのプロパティー

フィールド

説明

id

バンドルのユニークな名前(必須)

description

任意の文(Pacemakerでは使用されません)

Docker/rktプロパティー

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

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

フィールド

デフォルト

説明

image

  

イメージのタグ(必須)

replicas

masterの数。なければ1

起動するインスタンスの数の正の値

replicas-per-host

1

1つのノードで動作することが許可されているコンテナの数の正の値

masters

0

正の値であればコンテナサービスをマルチステートサービスとして扱い、マスターノードで複数レプリカがサービスを起動できる

network

  

指定した場合にはdocker run/rkt runコマンドにネットワーク設定として渡される

run-command

バンドルがprimitiveを含んでいる場合は/usr/sbin/pacemaker_remoted、それ以外の場合にはなし

起動する際にコンテナ内で実行される(“PID 1”)。バンドルにprimitiveがある場合はこのコマンドはpacemaker_remotedを起動する必要がある(例えばスクリプト内で他の動作を行わせることも可能だが)。

options

  

docker run/rkt runコマンドに渡す追加のコマンド

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

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

フィールド

デフォルト

説明

ip-range-start

  

指定した場合にはocf:heartbeat:IPaddr2リソースエージェントを各コンテナインスタンスに作成しIPアドレスを、replicasの数まで連続した値で起動する。このアドレスはホストネットワークからコンテナ内のサービスにアクセスするのに使用されるが、コンテナ自体の内部からは不可視である。IPv4のみサポートされている。

host-netmask

32

ip-range-startを指定した場合、IPアドレスはこのネットマスクで作成される。

host-interface

  

ip-range-startを指定した場合にIPアドレスが作成されるインターフェース(デフォルトではIPアドレスから決定される)。

control-port

  

バンドルにprimitiveが含まれていた場合にはコンテナ内部のPacemaker Remoteの通信用に指定したTCPポート番号が使用される。これはコンテナイメージのPCMK_remote_port環境変数に優先します。ip-range-startを指定していなくてもprimitiveに対して指定すること(この場合にはreplicas-per-hostは1であることが必要)、またはすでにデフォルトポートでリスンしているPacemaker Remoteノードでバンドルを動作させることができる。

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

 

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

フィールド

デフォルト

説明

id

  

ポートマッピングのユニークな名前(必須)

port

  

(ip-range-startを指定した場合には、そのコンテナのIPアドレスの)ホストネットワークのこのポート番号へのコネクションをコンテナネットワークにフォワードする。port-mapping内ではport番号かrangeを指定する必要がある。

internal-port

portの値

portとこの値を指定すると、ホストのネットワークのportへのコネクションがコンテナネットワークのここで指定したポートにフォワードされる。

range

  

(ip-range-startを指定した場合には、そのコンテナのIPアドレスの)ホストネットワークのこのポート番号の範囲(最初のポートから最後のポート)へのコネクションをコンテナネットワークの同じ範囲のポート番号にフォワードする。

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

 

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

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

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

フィールド

デフォルト

説明

id

  

ストレージマッピングのユニークな名前(必須)

source-dir

  

コンテナにマッピングするホストファイルシステムの絶対パス。storage-mapping内には1つのsource-dirとsource-dir-rootが必要。

source-dir-root

  

コンテナにマッピングするホストファイルシステムのパスの開始点であり、ここには各コンテナインスタンス用のものとは異なるサブディレクトリを使用する。サブディレクトリ名はバンドルホストネームと同じものを使用する。

target-dir

  

ホストのストレージがマッピングされるコンテナ内のパス(必須)

options

  

ストレージをマッピングする際のファイルシステムのマウントオプション

注記：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ノードで動作できます。