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

■例題
フェイルオーバークラスタの解説として間違っているものを選びなさい。

1. フェイルオーバークラスタは障害発生時にサービスを継続させる目的を持つ
2. クラスタを構成するノードは相互に監視を行う
3. ノード間の相互監視はネットワークを経由して行う
4. 障害から保護するサービスの種類によって、障害発生時の処理が異なる

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

フェイルオーバークラスタは、複数のノードでクラスタを構成し、ノード間で相互に死活監視を行います。監視対象となっているサービスが障害によってサービス継続できなくなったと判断された場合、そのサービスを別のノード上に移行させるなどの処理を行って、サービスを継続可能にします。

フェイルオーバークラスタのノード間の死活監視は、もちろんネットワークを経由した相互監視が基本となります。ネットワーク監視の経路が1つだけの場合、この経路の障害が発生すると即座に相互監視が不可能となってしまうので（単一障害点・SPOF）、監視経路を複数用意し、経路障害による誤検知を無くすような設計が必要になります。

その他の死活監視の手法の一つとして、SANやNASといったストレージを使った「投票ディスク方式」があります。各ノードから書き込むことができるストレージ領域に、各ノードが書き込みを行います。書き込みが行われないノードが居た場合、そのノードは障害が発生して書き込みができない、つまりサービス継続が不可能な状態になっていると判断できるわけです。

ネットワーク監視だけでは、ネットワーク通信の機能そのものに障害が発生すると、経路を冗長化しておいてもノード障害時には意味を成さない場合があるので、複数の手法による経路の確保も、お互いがお互いを認識し合えない、いわゆる「スプリットブレイン」の状態防止に繋がります。

システム停止の時間を極力短くしたいサービスを構築する際には、フェイルオーバークラスタの構成を検討してみてください。

■例題作成者
株式会社びぎねっと　代表取締役社長　宮原徹氏

※上記の解説とその内容については、例題作成者の監修です。