定足数と定足数デバイス

クラスタノードはデータとリソースを共有するため、クラスタが同時にアクティブになる独立したパーティションに分割されないようにすることが重要です。 CMM では、クラスタインターコネクトがパーティション分割されていても、ある時点で動作するクラスタは常に 1 つだけです。

クラスタのパーティション分割によって起こる問題には split-brain と amnesia があります。 split-brain は、ノード間のクラスタインターコネクトが失われ、クラスタがサブクラスタに分割されて、各サブクラスタが自分が唯一のパーティションであると思い込んだ場合に生じます。 この場合、個々のパーティションはそれ自体が唯一のパーティションであるとみなしますが、その原因は、クラスタノード間の通信が阻害されたことにあります。 amnesia の問題は、停止したクラスタが、停止時よりも古いクラスタデータに基づいて再起動されたときに発生します。 たとえば、フレームワークデータの複数のバージョンがディスクに格納されている状態で、クラスタが新たに起動されたときに最新バージョンが使用できないと、このような問題が起こる可能性があります。

split-brain と amnesia の問題は、各ノードに 1 票を与え、過半数の投票がないとクラスタが動作しないようにすることで防止できます。 過半数の投票を得たパーティションは「定足数 (quorum)」を獲得し、アクティブになります。 この過半数投票の仕組みは、クラスタに 3 つ以上のノードがある限り正しく機能します。 しかし、2 ノードクラスタでは過半数が 2 であるため、 このようなクラスタが分割されると、各パーティションが定足数を得るには外部の票が必要になります。 この外部からの投票は、「定足数デバイス (quorum device)」によって行われます。 定足数デバイスは、2 つのノードで共有されている任意のディスクにすることができます。 定足数デバイスとして使用されるディスクには、ユーザーデータを格納できます。

定足数アルゴリズムは動的に動作します。 クラスタイベントによってその計算が発生した場合、計算結果はクラスタの存続期間中、変化し続けます。

定足数投票数

クラスタノードと定足数デバイスはどちらも、定足数を確立するために投票します。 デフォルトにより、クラスタノードは、起動してクラスタメンバーになると、定足数投票数 (quorum vote count) を 1 つ獲得します。 またノードは、たとえばノードのインストール中や管理者がノードを保守状態にしたときには、投票数は 0 になります。

定足数デバイスは、デバイスへのノード接続の数に基づいて投票数を獲得します。 定足数デバイスは、設定されると、最大投票数 N-1 を獲得します。この場合、N は、投票数がゼロ以外で、定足数デバイスへのポートを持つノードの数を示します。 たとえば、2 つのノードに接続された、投票数がゼロ以外の定足数デバイスの投票数は 1 (2-1) になります。

定足数デバイスは、クラスタのインストール中、または『Sun Cluster のシステム管理』で説明している手順を使用して後で構成します。

---

注 –

定足数デバイスは、現在接続されている少なくとも 1 つのノードがクラスタメンバーである場合にのみ、投票数を獲得します。 また、クラスタの起動中、定足数デバイスは、現在接続されている少なくとも 1 つのノードが起動中で、その停止時に最も最近起動されたクラスタのメンバーであった場合にのみ投票数を獲得します。

---

定足数の構成

定足数 (quorum) の構成は、クラスタ内のノードの数によって異なります。

• 2 ノードクラスタ – 2 ノード クラスタを形成するには、定足数の投票数が 2 つ必要です。 これらの 2 つの投票数は、2 つのクラスタノード、または 1 つのノードと 1 つの定足数デバイスのどちらかによるものです。 ただし、2 ノードクラスタでは、一方のノードに障害が発生したときに単一ノードで処理を続行できるように、1 つの定足数デバイスが構成されなければなりません。

• 3 以上のノードのクラスタ – ディスクストレージの格納装置アクセスを共有するあらゆるノードペア間で、定足数デバイスを指定する必要があります。 たとえば、図 3–2 のような 3 ノードクラスタがあるとします。 この場合、ノード A とノード B が同じディスク格納装置へのアクセスを共有し、ノード B とノード C は別のディスク格納装置へのアクセスを共有します。 この構成では、合計 5 つの投票数があります。3 つはノードによるもの、2 つはノード間で共有される定足数デバイスによるものです。 クラスタを形成するには、過半数の投票数 (この場合は 3 票) が必要です。

  Sun Cluster ソフトウェアでは定足数デバイスを、ディスク格納装置へのアクセスを共有するすべてのノードペア間で指定する必要はなく、実際にそのような指定は行われません。 ただし、N+1 構成が 2 ノードクラスタに縮小し、両方のディスク格納装置にアクセスできるノードでも障害が発生した場合、必要な定足数投票数を得ることができます。 すべてのペア間で定足数デバイスを構成すると、残りのノードはクラスタとして動作を継続することができます。

  各構成の例については、図 3–2 を参照してください。

図 3–2 定足数デバイス構成の例

定足数のガイドライン

定足数デバイスを設定するときは、次のガイドラインを使用してください。

• 同じ共有ディスク格納装置に接続されたすべてのノード間で定足数デバイスを確立します。 共有格納装置内に 1 つのディスクを定足数デバイスとして追加し、いずれかのノードに障害が生じたときに、他のノードが定足数を維持して、共有格納装置上のディスクデバイスグループをマスターできるようにします。

• 定足数デバイスは少なくとも 2 つのノードに接続する必要があります。

• 定足数デバイスとして、二重ポート定足数デバイスとして使用される、任意の SCSI-2 または SCSI-3 ディスクが使用できます。 3 つ以上のノードに接続されたディスクは、ディスクが定足数デバイスとして使用されるかどうかに関係なく、SCSI-3 持続的グループ予約 (PGR) をサポートしなければなりません。 詳細については、『Sun Cluster ソフトウェアのインストール (Solaris OS 版)』の計画に関する章を参照してください。

• 定足数デバイスとしてユーザーデータを含むディスクを使用できます。

障害による影響の防止

クラスタの主要な問題は、クラスタがパーティション分割される (sprit-brain と呼ばれる) 原因となる障害です。 この障害が発生すると、一部のノードが通信できなくなるため、個々のノードまたはノードの一部が、個々のクラスタまたはクラスタの一部を形成しようとします。 各部分、つまりパーティションは、多重ホストディスクに対して単独のアクセスと所有権を持つものと誤って認識します。 そのため、複数のノードがディスクに書き込もうとすると、データが破壊される可能性があります。

障害による影響の防止機能では、多重ホストディスクへのアクセスを物理的に防止することによって制限します。 障害が発生するかパーティション分割され、ノードがクラスタから切り離されると、障害による影響の防止機能によって、ノードがディスクにアクセスできなくなります。 現在のメンバーノードだけが、ディスクへのアクセス権を持つため、データの完全性が保たれます。

ディスクデバイスサービスは、多重ホストディスクを使用するサービスに対して、フェイルオーバー機能を提供します。 現在、ディスクデバイスグループの主ノード (所有者) として機能しているクラスタメンバーに障害が発生するか、またはこのメンバーに到達できなくなると、新しい主ノードが選択されて、ディスクデバイスグループへのアクセスが可能になり、わずかな割り込みだけで処理が続行されます。 このプロセス中、古い主ノードは、新しい主ノードが起動される前に、デバイスへのアクセスを放棄しなければなりません。 ただし、あるメンバーがクラスタから切り離されて到達不能になると、クラスタはそのノードに対して、主ノードであったデバイスを解放するように通知できません。 したがって、存続するメンバーが、障害の発生したメンバーから広域デバイスを制御してアクセスできるようにする手段が必要です。

SunPlex システムは、SCSI ディスク予約を使用して、障害による影響の防止機能を実装します。 SCSI 予約を使用すると、障害ノードが多重ホストディスクから「防御」され、これらのディスクにアクセスできなくなります。

SCSI-2 ディスク予約は、ある形式の予約をサポートしています。これは、ディスクに接続されたすべてのノードへのアクセスを付与するか (予約が設定されていない場合)、または単一ノード (予約を保持するノード) へのアクセスを制限するものです。

クラスタメンバーは、別のノードがクラスタインターコネクトを介して通信していないことを検出すると、障害による影響の防止手順を開始して、そのノードが共有ディスクへアクセスするのを防止します。 この障害に対する防御が発生すると、防御されたノードがパニック状態になり、「予約の衝突」メッセージがコンソールに表示されます。

予約の衝突は、ノードがクラスタメンバーではなくなったことが検出された後で、SCSI 予約がこのノードと他のノードの間で共有されるすべてのディスクに対して設定されると発生します。 阻止されるノードは阻止されていることを認識しない場合があり、共有ディスクのどれかにアクセスしようとして、予約を検出して停止します。

障害の影響を防止するフェイルファースト機構

異常のあるノードが再起動され、共有ストレージに書き込むのを防ぐクラスタフレームワークの機構をフェイルファーストといいます。

クラスタのメンバーである各ノードでは、定足数ディスクを含むアクセス可能な個々のディスクに対し ioctl (MHIOCENFAILFAST) が連続的に有効にされます。 この ioctl は特定のディスクドライバに対する命令です。ディスクが他のノードによって予約されているためにそのディスクにアクセスできないと、ノードは自らをパニックさせる (強制的に停止する) ことができます。

MHIOCENFAILFAST ioctl によって、ドライバはノードがディスクに対して行ったあらゆる読み書きについて、 Reservation_Conflict というエラーコードが戻っていないかどうかを調べます。 ioctl はバックグラウンドでディスクに対して周期的にテスト操作を行い、Reservation_Conflict がないか検査します。 Reservation_Conflict が返されると、フォアグラウンドとバックグラウンドのコントロールフローパスが両方ともパニックを発生します。

SCSI-2 ディスクの場合、予約は持続しません。つまり、ノードの再起動後は維持されません。 Persistent Group Reservation (PGR) 機能を備えた SCSI-3 ディスクの場合は、ディスクに予約情報が保管され、ノードの再起動後も維持されます。 フェイルファースト機構は、SCSI-2 ディスクでも SCSI-3 ディスクでも同じように機能します。

定足数を獲得できるパーティションに属していないノードが、クラスタ内の他のノードとの接続を失うと、そのノードは別のノードによってクラスタから強制的に切り離されます。 定足数を獲得できるパーティションのノードによって予約されている共有ディスクに、定足数をもたないノードからアクセスすると、ノードは予約衝突のエラーを受け取り、フェイルファースト機構に基づいてパニックを発生します。

パニック後、ノードは再起動してクラスタに再度加わろうとするか、またはクラスタが SPARC ベースのシステムで構成されている場合は、OpenBoot^TM PROM (OBP) プロンプトのままになります。 どちらのアクションをとるかは、auto-boot? パラメータの設定に依存します。 auto-boot? は、SPARC ベースのクラスタでは OpenBoot PROM ok プロンプトから、eeprom(1M) で設定できます。または、x86 ベースのクラスタでは、BIOS のブート後に任意で実行する SCSI ユーティリティで設定できます。