334.3 フェイルオーバークラスタ

今回は304試験の試験範囲から「334.3 フェイルオーバークラスタ」についての例題を解いてみます。

■トピックの概要
このトピックの内容は以下の通りです。

＜334.3 フェイルオーバークラスタ＞
重要度     6

＜説明＞
Pacemaker クラスタのインストール、設定、保守およびトラブルシュートの経験。 Corosyncの使用を含む。 Corosync 2.x の Pacemaker 1.1.
    
＜主要な知識範囲＞
・Pacemaker アーキテクチャとコンポーネント (CIB, CRMd, PEngine, LRMd, DC, STONITHd).
・Pacemaker クラスタ設定
・リソースクラス (OCF, LSB, Systemd, Upstart, Service, STONITH, Nagios).
・リソースのルールと制約 (location, order, colocation).
・高度なリソース機能 (templates, groups, clone resources, multi-state resources).
・pcs を使用した Pacemaker の管理
・crmshを使用した Pacemaker の管理
・Pacemakerと使用するcorosyncの設定と管理
・他のクラスタエンジンの認知 (OpenAIS, Heartbeat, CMAN).

＜重要なファイル、用語、ユーティリティ＞
・pcs
・crm
・crm_mon
・crm_verify
・crm_simulate
・crm_shadow
・crm_resource
・crm_attribute
・crm_node
・crm_standby
・cibadmin
・corosync.conf
・authkey
・corosync-cfgtool
・corosync-cmapctl
・corosync-quorumtool
・stonith_admin

■例題
Pacemakerの設定の説明として適切なものを選択してください。

1.「colocation」には、順序制約を定義できる
2.「location」には、配置制約を定義できる
3.「order」には、同居制約を定義できる
4.「position」には、位置制約を定義できる

※この例題は実際の試験問題とは異なります。
 

Pacemakerは、多種多様なリソースを定義して、サービスとして扱うことができます。
Pacemakerとして、リソースの最小単位はprimitiveという設定で、設定可能です。

しかしprimitiveを定義しただけでは、どのリソースがどのノードで起動するか決められていないため、予期せぬ動作をします。

具体的には、PacemakerでIPアドレスとWEBサービスを管理する場合に、どちらも同じノードで稼働しなければならないのに、別々のノードで稼働してしまうような例です。

Pacemakerでは、このような状況に対応するために、制約を定義してリソース同士の関係性や稼働するノードを決めることができます。

colocationは、指定した複数のノードが同一ノードで動作するための制約（同居制約）を記載する設定項目です。
locationは、リソースを配置するノードを決めるための制約（配置制約）を記載する設定項目です。
orderは、リソースの起動順（順序制約）を記載する設定項目です。

なおpositionという設定項目は存在しません。

Pacemakerを使ってリソースを管理する場合、上記の制約を組み合わせて、意図したリソースが意図したノードで稼働するように設定する必要があります。
実際に設定を行って、動きを確認しておきましょう。

■例題作成者
株式会社デージーネット　ソリューション開発部　　　　森 彰吾 氏