第2章 CMAN を使用したクラスター管理
クラスター管理とはクラスターの定足数とメンバーシップの管理を指します。Red Hat Enterprise Linux の High Availability Add-On でクラスター管理を行うのが CMAN (クラスターマネージャーの略) です。CMAN は分散型クラスターマネージャーのためそれぞれのクラスターノードで実行されます。クラスター管理はクラスター内の全ノードに分散されます。
CMAN は他のクラスターノードからのメッセージを監視することでメンバーシップを追跡します。クラスターメンバーシップに変化が生じると、クラスターマネージャーによって他のインフラストラクチャーコンポーネントに対して通知が送られ、各コンポーネントは変化に応じた動作をとることになります。一定時間内にメッセージを送信しないクラスターノードがあると、そのクラスターマネージャーはクラスターからそのノードを取り除き、他のクラスターインフラストラクチャーのコンポーネントにノードがメンバーではないことを通知します。他のクラスターインフラストラクチャーのコンポーネントはノードがクラスターのメンバーではなくなったという通知を受けると、それに応じて実行すべき動作を決定します。例えば、隔離機能の場合ならメンバーではなくなったノードの切断を行います。
CMAN ではクラスターノード数を監視することでクラスターの定足数を追跡します。半数以上のノードが正しく動作している場合、クラスターは定足数を獲得します。半数 (または半数以下) の場合は定足数に満たないためクラスターの全アクティビティが停止されます。同じクラスターの別々のインスタンスが同時に実行してしまう split-brain の発生を防ぐのがクラスター定足数です。split-brain 状態が発生すると、インスタンス同士が互いを認識できない状態でクラスターのリソースにアクセスするため、クラスターの整合性が失われることになります。
2.1. クラスター定足数
定足数とは CMAN で使用される投票アルゴリズムです。
クラスターが正しく機能するのは互いにメンバーの状態に関して一般的な同意がある場合のみです。大多数のノードが正しく動作し、他の動作中のメンバーと通信、同意している場合、定足数を獲得していると表現します。たとえば、13 台のノードを持つクラスターの場合、7 台以上のノードが通信を行っている場合にのみ定足数に達したと言います。13 台のうち 7 台が停止してしまうと定足数を失ってしまうためクラスターは正しく機能しなくなります。
split-brain の問題を防ぐには定足数を維持する必要があります。定足数を実施していなかった場合、上述の 13 台のノード上で通信エラーが発生すると、13 台のうちの 6 台と別の 6 台が別々に同じ共有ストレージで動作してしまような状態を招く可能性があります。通信エラーのため、2 つに分離されたクラスターの一部同士がディスク領域を上書きするためファイルシステムが破損します。定足数のルールを実施すると、片方のみが共有ストレージを使用するためデータの整合性を確保することができます。
定足数が split-brain 状態を防ぐわけではありませんが、定足数によりクラスター内で優先して動作させるノードが決定されます。split-brain が発生した場合には、複数のノードグループが同時に動作しないよう防ぎます。
定足数はクラスターノード間で行われるイーサネット経由のメッセージ通信で確定されます。オプションでイーサネットに加え 定足数ディスク も組み合わせたメッセージ通信で確定することもできます。イーサネット経由の定足数の場合、定足数とは単純に過半数になります (全ノード数の 50% + 1)。定足数ディスクを設定する場合は、定足数はユーザーが指定した条件になります。
注記
デフォルトでは各ノード 1 つずつ定足数投票数を獲得します。オプションで複数の投票数を獲得できるよう設定することもできます。
2.1.1. 定足数ディスク
定足数ディスクまた定足数パーティションとはクラスタープロジェクトのコンポーネントで使用するため設定したディスクの任意のセクションです。例を示しながらその目的を説明していきます。
ノード A とノード B があるとします。ノード A はノード B からクラスターマネージャーの「ハートビート」パケットのいくつかを取得できませんでした。ノード A ではパケットを受信できなかった理由は認識できませんが次のような可能性が考えられます。「ノード B に障害が発生した」、「ネットワークのスイッチまたはハブに障害が発生した」、「ノード A のネットワークアダプターに障害が発生した」、「単にノード B の使用率が非常に高いためパケットを送信できなかった」など。クラスターのサイズが非常に大規模な場合、システムの使用率が非常に高い場合、ネットワークが不安定な場合などに発生する可能性があります。
ノード A 側ではパケットを受信できなかった理由、また問題がノード A 自体にあるのかノード B の方にあるのかわかりません。特に 2 台のノードで構成されるクラスターの場合、互いに接続できなくなり、お互いに他方を隔離しようとすることがあるため問題となります。
このため、ノードの隔離を行う前に、接続できないように見えるノードが実際に動作しているかどうかを確認する別の方法を用意しておくのが適切です。定足数ディスクでこれを行うことができます。接続できなくなっているノードを隔離する前に、クラスターソフトウェアを使用すると、そのノードが定足数パーティションにデータの書き込みを行っているかどうかでノードが動作しているかどうかを判断することができます。
2 ノードシステムの場合、定足数ディスクはタイブレーカーとしても機能します。ノードに定足数ディスクおよびネットワークへのアクセスがある場合、2 票獲得としてカウントされます。
ネットワークまたは定足数ディスクに接続できなくなったノードは 1 票失うため、安全に隔離することができるということになります。
定足数ディスクのパラメータの設定方法については 『Cluster Administration (クラスターの管理)』 ガイドにある Conga と
ccs の管理に関する章を参照してください。
2.1.2. タイブレーカー
タイブレーカーは付加的な解決方法で、同数割れしてしまった場合に定足数に達しているかどうかを隔離を行う前にクラスターパーティションで決定できるようにする方法です。標準的なタイブレーカーの構成は ping ノードとも呼ばれる IP タイブレーカーです。
こうしたタイブレーカーを使用すると、ノード同士の監視に加えクラスター通信を行う際、同じパスの上流に位置するルーターも監視するようになります。2 ノードが互いに接続できなくなった場合、この上流のルーターに ping できるノードが存続することになります。一方、switch -loop などのように 2 ノードいずれも上流のルーターには ping できるのにノード同士の通信はできないため spllit-brain 状態に陥ってしまう場合も考えられます。このため、タイブレーカーを使用している場合でも、隔離機能が正しく設定されているか必ず確認することが重要になります。
さらに、(定足数ディスクと呼ばれることの多い) 共有パーティションから追加詳細が提供される別のタイプのタイブレーカーもあります。clumanager 1.2.x (Red Hat Cluster Suite 3) には、ネットワークがダウンした場合でも両方のノードが共有パーティション経由で通信し続けている限り操作を許可するディスクタイブレーカーが含まれていました。
QDisk (linux-cluster の一部) など、より複雑なスキームを持つタイブレーカーもあります。QDisk では任意の解決法を指定できます。各ノード自体にクラスターへの参加に適した状態であるかを判断させることができます。ただし、これは多くの場合、単純な IP タイブレーカーとして使用されます。詳細は qdisk(5) のマニュアルページをご覧ください。
CMAN にはいくつかの理由によりタイブレーカーは内蔵されていませんが API を使用すれば実装できます。API を使用すると定足数デバイスの登録と更新を行うことができます。サンプル使用例は QDisk のソースコードを参照してください。
以下のような場合、タイブレーカーが必要になるかもしれません。
- 2 ノード構成、フェンスデバイスが接続されクラスター通信で使用するパスとは別のネットワークパス上に配置している
- 2 ノード構成、隔離機能はファブリックレベルで設定 (とくに SCSI 予約の場合)。
ただし、クラスターにネットワークと隔離機能が正しく設定されている場合は、異常なケースを除き、タイブレーカーの使用はさらに複雑になるだけです。
