3 ノード以上のクラスタの障害防護

2 ノードのクラスタで使用される SCSI-2 予約モデルで問題なのは、SCSI 予約がホストに固有であるという点です。共有デバイスに予約要求を発行した場合、事実上、ホストは、障害があるかどうかに関係なく、そのデバイスにアクセスできる別のすべてのノードを締め出します。その結果、OPS などの共有ディスク環境で 3 つ以上のノードが多重ホストディスクに接続されていると、この予約モデルは破綻します。

たとえば、3 ノードのクラスタでノードの 1 つが停止すると、残り 2 つのノードは再構成します。しかし、残りのノードは SCSI 予約要求を発行して、障害ノードから土台の共有デバイスを保護することはできません。これは、SCSI 予約要求を発行すると、一方の残りのノードも締め出されるためです。しかし、予約をしないと、障害ノードが稼動し、そのクラスタビューが最新でなくなっているにもかかわらず、共有デバイスに入出力要求を発行する可能性があります。

すべてのクラスタノードから直接、アクセス可能な記憶装置を持つ 4 ノードのクラスタを考えてみます。ノードの 1 つが停止し、残り 3 つのノードが再構成しても、残りのノードは SCSI 予約要求を発行して、障害ノードから実際の共有デバイスを保護することはできません。これは、予約することによって、正当なクラスタメンバーの一部もデバイスに対して入出力要求を発行できなくなるためです。しかし、予約をしないと、障害ノードが稼動し、そのクラスタビューが最新でなくなっているにもかかわらず、共有デバイスに入出力要求を発行するという危険性があります。

次に、票割れが発生したときの問題を考えてみます。4 ノードのクラスタでは、さまざまなインターコネクト障害が考えられます。ここでは、パーティションの内部の各メンバーは互いに通信でき、パーティションの外部のクラスタノードとは通信できない、一群のクラスタノード全体を 1 つのパーティションと定義します。インターコネクト障害が発生すると、それぞれが 2 ノードで構成される 2 つのパーティション、あるいは 3 ノードと 1 ノードの 2 つのパーティションが形成される状況が考えられます。あるいは、4 ノードのクラスタが、ノードが 1 つずつの 4 つのパーティションになる可能性もあります。このどの状況でも、Sun Cluster は、残すパーティションと終了するパーティションについて、矛盾のない合意を得ようとします。

例 1: それぞれが 2 ノードで構成される 2 つのパーティションが形成された場合。2 ノードのクラスタにおける 1 対 1 の票割れのときと同様、どちらのパーティションの CMM も、残すパーティションと終了するパーティションを決定するための定足数は得られません。データの完全性と高可用性を実現するには、両方のパーティションを残すか、両方のパーティションを停止します。ノード 2 つのクラスタのときと同様、この問題は外部のデバイス (定足数ディスク) によって決定される可能性があります。それぞれのパーティション内の指名されたノードは、指定された定足数デバイスの予約を争うことができ、いずれかのパーティションが予約に成功します。そして、SCSI-2 予約の性質上、定足数デバイスの予約に成功したノードは同じパーティション内のもう一方のノードがデバイスにアクセスできないようにします。定足数デバイスには両方のノードに有用なデータが含まれており、このモデルは理想的ではありません。

例 2: 3 ノードと 1 ノードの 2 つのパーティションが形成された場合。過半数のパーティションが十分な定足数を得ているとしても、ここで最も重要な問題は、単独で分離されたノードには別の 3 つのノードに何が起きたのか分からないということです。3 つのノードが有効なクラスタを形成している場合は、この単独ノードは停止できます。しかし、3 つのノードが実際に障害を起こしていることも考えられます。この場合、単独で切り離されたノードは動作し続け、可用性を維持する必要があります。完全に通信手段が失われていて、調停する外部デバイスが存在しない場合は、決定することは不可能です。構成済みの外部定足数デバイスの予約を争うと、結果的に例 1 よりもさらに悪い状況になります。過半数パーティションのノードの 1 つが定足数デバイスを予約した場合、そのノードは、同じパーティション内の別の 2 つのノードがその定足数デバイスにアクセスできないようにします。しかし、さらに悪いことに、単独で分離されたノードが予約に成功した場合は、正常な可能性のある 3 つのノードがクラスタから失われる可能性があります。ここでもまた、ディスク予約による解決は適切に機能しません。

ディスク予約手法を利用できない場合もまた、インターコネクト障害や操作エラーが発生したときに、それぞれが分離された専用のパーティション内に複数の独立したクラスタが形成されやすくなります。上記の例 2 を考えてください。CMM または外部エンティティが何らかの方法で、過半数パーティションの 3 つのノードが留まり、単独で分離されたノードが終了するよう決定し、後で管理者が、インターコネクトを修復することなく終了されたノードを起動しようとしたと仮定します。単独ノードは依然として、どの残りのメンバーとも通信できないため、クラスタ内の唯一のノードと考えて、定足数デバイスを予約しようとします。事実上、低速デバイスの予約はないので、この試みは成功し、単独のノードは、自身を唯一のメンバーとする独立したクラスタを形成します。

つまり、すべてのノードから直接、アクセス可能な記憶装置を持つ 3 ノードまたは 4 ノードのクラスタに対して、単純な定足数予約手法は利用できません。次の 3 つの問題を解決するには、新しい手法が必要です。

1. 3 ノードまたは 4 ノードのクラスタにおける票割れ状態をすべて解決する方法

2. 障害ノードから共有デバイスを障害防護する方法

3. 分離されたパーティションが複数の独立したクラスタを形成するのを防ぐ方法

3 ノードまたは 4 ノードのクラスタにおける票割れ状態を解決するには、 手動介入段階の操作エラーによってクラスタの完全性が損なわれる可能性があることに注意しながら、発見的な手法と手動介入を組み合わせます。「定足数デバイス (VxVM)」では、3 ノード以上のクラスタについて、クラスタパーティションが発生した場合の処置を決定するために指定できるポリシーについて説明しました。干渉主義のポリシーを選択した場合、すべてのパーティションの CMM は、各パーティションのすべてのクラスタ動作を一時停止して、有効なクラスタを形成し続けるパーティションと終了するパーティションについて、オペレータからの入力を待ちます。この場合、特定の 1 つのパーティションを残して、別のすべてのパーティションを終了させる作業は管理者が行います。複数のパーティションが有効なクラスタを形成できるようにすると、データ破壊が発生する可能性があります。

事前決定的なポリシーを選択した場合は、優先するノード (クラスタ内の最大または最小のノード ID を持つノード) が要求され、票割れ状態が発生すると、優先ノードを含むパーティションが自動的に新しいクラスタになります (可能な場合のみ)。この場合、別のすべてのパーティションは、手動で終了する必要があります。2 ノードのクラスタの場合、選択された定足数デバイスは、票割れが発生したときに同数になるのを防ぐ目的にのみ使用されます。票割れ状態は、4 ノードのクラスタでも発生することがあります。4 ノードのクラスタで票割れが発生すると、2 つのクラスタメンバーだけアクティブになります。ここでも定足数デバイスは 1 つの役割を果たしますが、その働きは限られたものです。

パーティションを残すように選択した後で問題になるのは、終了しているはずの別のパーティションからどのようにデータを効果的に保護するかということです。別のすべてのパーティションを終了しようとしても、パーティションを終了するコマンドがすぐには正しく実行されない可能性があります。効果的な障害防護機能がないと、終了要求を処理する前に、停止したノードが再稼動し、共有デバイスに保留中の入出力要求を発行する危険性が常に伴います。この場合、障害ノードは、パーティション内に有効なクラスタが形成される前にリセットされます。

障害ノードが再稼動して、多重ホストディスクに入出力要求を発行するのを防ぐには、残りのノードの 1 つが障害ノードを強制的に終了させ、端末集配信装置またはシステムサービスプロセッサ (Sun Enterprise 10000 システムの場合) によって、そのノードを OpenBoot PROM モードにして、オペレーティングシステムの停止イメージを終了します。OpenBoot PROM のプロンプトに対して go と入力することによって、誤ってシステムの動作が再開されるのを防止します。残りのクラスタメンバーは、クラスタの再構成プロセスに進む前に終了処理からの肯定応答を待ちます。

終了コマンドに対する応答がない場合は、パワーシーケンサ (存在する場合) が動作して、障害ノードの電源が入れ直されます。この動作に失敗した場合、システムは次のメッセージを表示して、クラスタの再構成を続行するための情報の入力を求めます。

/opt/SUNWcluster/bin/scadmin continuepartition localnode clustername
¥007*** ISSUE ABORTPARTITION OR CONTINUEPARTITION ***
You must ensure that the unreachable node no longer has access to the 
shared data. You may allow the proposed cluster to form after you have 
ensured that the unreachable node has aborted or is down.
Proposed cluster partition: 

残りのノード上で scadmin continuepartition コマンドを発行する前に、必ず、障害ノードを正しく終了させてください。

パーティション化されて、分離され、終了されたノードは、最終的には起動します。何らかの誤りで、管理者がインターコネクトを修復することなくそのノードをクラスタに結合させようとした場合は、そのノードが既存のクラスタと通信できないときに、独自の有効なクラスタパーティションを形成するのを防ぐ必要があります。

3 ノードと 1 ノードの 2 つのパーティションが形成されていると仮定します。この場合は、過半数パーティションの指定されたノードは分離されたノードを終了し、3 つのノードはそれら専用のパーティション内に有効なクラスタを形成します。その後、管理者が startcluster(1M) コマンドを実行して、確認を求められたときに肯定的な応答をすると、分離されたノードは、起動後に独自のクラスタを形成しようとします。分離されたノードは自身がクラスタ内の唯一のノードであると判断するため、定足数デバイスの予約を試み、実際にその試みに成功します。これは、有効なパーティション内に 3 つのノードがあり、そのどれも、別のノードを締め出すことなしに定足数デバイスを予約できないためです。

この問題を解決するために、Sun Cluster 2.2 はノードロックを使用します。この場合、クラスタメンバーシップ内の指定されたクラスタは、クラスタの再構成の一環として、端末集配信装置の未使用ポートに対する telnet(1) セッションを開き、クラスタのメンバーである間、そのセッションを継続します。このノードがメンバーシップから切り離されようとすると、ノードロックは、残りのクラスタメンバーの 1 つに渡されます。上記の例で、分離されたノードが独自のクラスタを形成しようとする場合、そのノードはノードロックの取得を試み、失敗します。これは、別のパーティション内のメンバーシップノードの 1 つがノードロックを保持しているためです。有効なクラスタメンバーの 1 つが何らかの理由でノードロックを取得できなかった場合、そのことが重大なエラーとはみなされることはありませんが、ただちに対応する必要があるエラーとして記録されます。ロック機能は、クラスタの運用に不可欠な機能ではなく、安全上の機能とみなされ、ロック機能に問題が発生しても、危機的なエラーとはみなされません。ロックにおける障害を素早く検出するために、Sun Cluster フレームワーク内のプロセスは、端末集配信装置がクラスタノードからアクセスできるかどうかを監視します。