構文上のショートカットクラスタを利用するうえで頻繁に必要になる要素として複数のリソースを一まとめにするリソースセットがあります。これは同じ場所でリソースを順番に起動して、停止する時にはその逆の順番で行うといった操作が行えます。この動作は、groupを使用して設定します。type="exim"/></group>上記の例ではリソースは2つだけですが、group内に記載できるリソース数に制限はありません。groupには以下の効果があります。リソースは記載された順に起動する(Public-IP→Email)リソースの停止する順番は記載順の逆(Email→Public-IP)リソースがどのノードでも起動することができない場合は、後続リソースも起動できません。Public-IPが起動できなければ、Emailも起動しないしかし、Emailが起動できない場合にはPublic-IPは影響を受けないグループプロパティーgroupリソースのプロパティーを以下のように設定できます。is-managedプロパティーを継承します。グループインスタンス属性groupにはインスタンス属性がありません。groupの対象に行われた設定はgroupの子にも引き継がれます。グループの内容groupはクラスタリソースのみを記載することができます。groupリソースの子を参照したい場合には、そのidを記載してください。制約条件の中でgroupの子を参照することは可能であり、通常group自身から参照することは適切な方法です。then="shortcut"/></constraints>グループスティッキネスstickinessはリソースが現在のノードに留まろうとする度合いを示しますが、groupでは付加的なものになります。group内のアクティブなリソースがgroup全体のstickinessの値に影響します。resource-stikkinessが100で、group内に7つのリソースがあり、そのうち5つがアクティブだった場合にはその時のgroupのstickinessの値は500になります。複数ホストでリソースをアクティブにcloneは当初複数ノードでIPアドレスのリソースを起動し、クラスタ間で負荷分散することを目的にしていました。分散ロックマネージャーやフェンシング機能、OCF2を管理するためにも有用です。リソースエージェントが対応していればどのようなリソースでもクローンすることができます。cloneリソースには次の3種類があります。uniqueStatefulAnonyumousクローンはもっとも単純なもので、どこでもリソースが同じように起動します。マシンあたりcloneリソースのコピーは1つだけ起動できます。uniqueクローンは個別のエンティティです。あるマシンで動作するcloneは別のマシーンで動作するcloneと同じではありませんし、同じマシンで動作する2つのcloneも同じではありません。Statefulクローンについては後述します。以下のようにcloneリソースにオプションを付与できます。is-managedです。起動するリソースの数lone-max-node11つのノードで起動できるリソースのコピーの数clone-min1リソースを実行可能にするのを許可する前に、少なくともこの数のクローンインスタンスが実行可能であることが必要notifytrueクローンの停止または起動する際、その前にすべてのコピーに通知し、成功後に再度通知する。trueglobally-uniquefalse個々のクローンのコピーが異なった挙動を行うかどうか。trueorderdfalseコピーを並列でなく順次起動するかどうか。trueinterleavefalseクローンがオーダー制約で他のクローンに依存している場合に、他のクローンのすべてのインスタンスが起動するのを待つのではなく、他のクローンのローカルインスタンスが起動していれば起動するようにするかどうか。trueクローンインスタンス属性cloneにはインスタンス属性がありません。cloneの子には継承されます。クローンコンテンツcloneは1つのprimitiveまたはgroupリソースを含んでいる必要があります。注意:cloneの子は参照してはいけません。その必要があるような場合には別の構成を考えてください。通常、cloneはアクティブなクラスタノードあたり1つのコピーを持ちます。ない場合には、位置制約を使用してクラスタがどのノードにコピーをアサインするかを設定します。制約条件は、cloneのIDが使用されているのでなければprimitiveリソースと同じように記載します。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が値として使用されます。uniqueクローンの場合には、他に動作できるノードがあるにも関わらず、1つのノードで複数のクローンが動作する状態になる場合があります。一度スタンバイモードにしてアクティブに戻すケースが典型的でしょう。このような場合には一時的にresource-stickinessを0にして、ノードが移動した後で1に戻すのがよいでしょう。クローンリソースエージェントの要件Anonymousクローンは、通常のリソースエージェントであれば追加で何も必要としません。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アクションが実装されている必要があります。実装されていれば、通知アクションには追加のコンテキストと組み合わせて現在の状態とこれから行われる処理を判別するための追加の変数が渡されます。stopOCF_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で起動することを示すのは以下のようになります。複数モードのあるリソースマルチステートリソースはcloneリソースの一種で、ロールと呼ばれる2つの状態のうちのどちらかになることができます。ロールは通常マスターとスレーブと呼ばれます。起動した際には、最初に必ずスレーブ状態になります。マルチステートプロパティーマルチステートリソースのプロパティーフィールド説明idマルチステートリソース名マルチステートオプションオプションはprimitiveリソースから次のものを継承します。is-managedオプションはcloneリソースから次のものを継承します。interleaveマルチステートリソース特有の設定オプションフィールドデフォルト説明master-max1リソースのコピーのうちマスターになれる数master-node-max1リソースのコピーのうち、1つのノードでマスターになれる数マルチステートインスタンス属性マルチステートリソースはインスタンス属性を持ちません。ここで何かを設定した場合にはマスターの子に継承されます。マルチステートのコンテンツマスターにはprimitiveリソースかgroupリソースが含まれている必要があります。注意:マスターの子の名前を参照することはできません。通常のモニター処理では、マルチステートリソースに対しては十分ではありません。リソースが動作しているかどうかだけではなく、意図したロールになっているかどうかを確認する必要があるためです。そこで、2つのモニターを設定します。1つはスレーブ状態を監視し、もう1つはrole=”master”と設定してマスターのロールを監視します。すべてのモニター動作が異なるインターバルであることが必要です。Pacemakerはリソースと間隔によってしか区別することができません。そのためもしマスター/スレーブリソースが同じ間隔であった場合には正しい結果を得ることができません。多くの場合、マルチステートリソースはアクティブなノードに1つのコピーを持ちます。ない場合にはどのノードを選好してコピーをアサインするかlocation制約で指定することができます。制約においてはマスターのIDを使用することを除いてはprimitiveリソースの場合と同じです。マルチステートリソースの制約を行う際には、cloneと同様に扱うことができます。order制約のfist-actionおよび/またはthen-actionフィールドにpromoteまたはdemoteを設定できること、またcolocation制約にはrsc-roleやwith-rsc-roleフィールドなどが含まれる点が異なります。マルチステートリソースでの追加のcolocation制約フィールドデフォルト説明rsc-rolestartedrscオプションで指定したリソースのロールの指定をする追加の属性。Slavewith-rsc-rolestartedwith-rscオプションで指定したリソースのロールの指定をする追加の属性。setオプションフィールドデフォルト説明rolestartedセット内のすべてのメンバーがそうであるべきロール。setオプションフィールドデフォルト説明actionfirst-actionの値セット内のすべてのメンバーに適用されるアクション。demoteマルチステートのスティッキネス通常のcloneリソースと同様のstikinessになります。(10.2.6のクローンスティッキネスを参照)昇格するリソースインスタンス起動処理ではリソースエージェントはcrm_masterユーティティを呼び出します。このユーティリティはホストとリソースを検出して昇格時にこれを考慮します。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)マルチステートの通知クローンと同様、通知アクションが実装されている必要があります。通知アクションは多くの追加変数を渡し、これらによって現在とこれから移行するクラスタ状態の計算が行われます。隔離環境Pacemaker(1.1.17以降)では、インフラに対して隔離環境を組み込むための構文を用意しています。現在サポートしている隔離環境はDockerとrktコンテナです。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イメージのタグ(必須)replicasmasterの数。バンドルにprimitiveがある場合はこのコマンドはpacemaker_remotedを起動する必要がある(例えばスクリプト内で他の動作を行わせることも可能だが)。runコマンドに渡す追加のコマンドバンドルのネットワークプロパティーバンドルには<network>要素で組み込むことができます。使用できるネットワークプロパティーは以下です。フィールドデフォルト説明ip-range-start指定した場合にはocf:heartbeat:IPaddr2リソースエージェントを各コンテナインスタンスに作成しIPアドレスを、replicasの数まで連続した値で起動する。このアドレスはホストネットワークからコンテナ内のサービスにアクセスするのに使用されるが、コンテナ自体の内部からは不可視である。IPv4のみサポートされている。host-netmask32ip-range-startを指定した場合、IPアドレスはこのネットマスクで作成される。host-interfaceip-range-startを指定した場合にIPアドレスが作成されるインターフェース(デフォルトではIPアドレスから決定される)。Remoteの通信用に指定したTCPポート番号が使用される。これはコンテナイメージのPCMK_remote_port環境変数に優先します。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-portportの値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はホスト上にすでにソースディレクトリがなくなっていた場合の挙動は定義しません。そのような場合にはコンテナまたはリソースエージェントがそのソースディレクトリを作成することが求められています。target-dir=/var/logと同等のものをコンテナにマッピングするためこれのパスをstorage-mappingに設定する必要はありません。重要:PCMK_authkey_location環境変数はクラスタ内のすべてのノードの/etc/pacemaker/authkeyのデフォルト以外のものは指定すべきではありません。バンドルプリミティブバンドルにはオプションで1つの<primitive>リソースを持たせることができます。インスタンス属性、メタ属性の定義ができます。Remoteデーモンがコンテナイメージ内にあり、最低1つのip-rante-startまたはcontrol-portがバンドル内に設定されている必要があります。Remoteを通じてプリミティブリソースを監視・管理します。Remoteと通信するためにアクセス可能なネットワーク環境が必要です。Dockerオプションの—net=noneはprimitiveで使用するべきではありません。デフォルト(コンテナ内の個別のネットワークを使用する)ではip-rante-startと組み合わせて使用します。場合には、一意のcontrol-portをバンドルごとに指定する必要があります。すべてのファイアウォールでcontrol-portへのアクセスを許可する必要があります。バンドルノード属性バンドルにprimitiveがある場合、プリミティブのリソースエージェントはmasterスコアなどノード属性を指定したいケースがあるでしょう。コンテナの場合にはどのノードが属性を持つか明確ではありません。バンドルメタ属性バンドルに設定するすべてのメタ属性は、バンドルのプリミティブと、Pacemakerがプリミティブ用に作成したすべてのリソースに継承されます。バンドルの制約バンドルが管理されていない間、またはクラスタがメンテナンスモードの時にPacemakerを再起動するとバンドルの障害が発生することがあります。バンドルはクローンできず、グループに含めることができません。これはバンドルのプリミティブと、Pacemakerがプリミティブ用に作成したすべてのリソースでも同様です。バンドルのプリミティブはインスタンス属性、ユーティリティ属性、オペレーションを持つことができますが、バンドル自体はそれらを持つことができません。Remoteノードで動作できます。コメントをキャンセル次回のコメントで使用するためブラウザーに自分の名前、メールアドレス、サイトを保存する。