Sun Cluster ソフトウェアが定足数デバイスとしてサポートする特定のデバイスの一覧については、Sun のサービスプロバイダにお問い合わせください。
クラスタノードはデータとリソースを共有しており、複数のアクティブなパーティションがあるとデータが壊れる恐れがあるのでクラスタは決して複数のアクティブなパーティションに一度に分割しないでください。クラスタメンバーシップモニター (CMM) および定足数アルゴリズムにより、たとえクラスタ接続がパーティション分割されている場合でも、いつでも同じクラスタのインスタンスが 1 つだけは動作していることが保証されます。
CMM の詳細については、『Sun Cluster の概要 (Solaris OS 版)』の「クラスタメンバーシップ」を参照してください。
クラスタパーティションからは次の 2 種類の問題が生じます。
Split brain は、ノード間のクラスタ接続が失われ、クラスタがサブクラスタにパーティション分割されるときに起きます。1 つのパーティションのノードが他のパーティションのノードと通信できないため、それぞれのパーティションは、それが唯一のパーティションであると認識します。
amnesia は、停止したクラスタが、停止時よりも古いクラスタ構成データに基づいて再起動されたときに発生します。この問題は、最後に機能したクラスタパーティションではないノード上のクラスタを起動するときに起きる場合があります。
Sun Cluster ソフトウェアは、split brain と amnesia を次の操作により回避します。
各ノードに 1 つの投票を割り当てる
動作中のクラスタの過半数の投票を管理する
過半数の投票数を持つパーティションは、定足数を獲得し、動作可能になります。この過半数の投票メカニズムにより、クラスタ内に 3 つ以上のノードが構成されているときに split brain と amnesia を防ぐことができます。ただし、クラスタ内に 3 つ以上のノードが構成されている場合、ノードの投票数を数えるだけでは十分ではありません。しかし、2 ノードクラスタでは過半数が 2 であるため、このような 2 ノードクラスタがパーティション分割された場合、いずれかのパーティションが定足数を獲得するために外部投票が必要です。この外部投票は、定足数デバイスにより提供されます。
scstat -q コマンドを使って、以下の情報を調べます。
構成済み投票数
現在の投票数
定足数に必要な投票数
このコマンドの詳細については、scstat(1M) のマニュアルページを参照してください。
ノードおよび定足数デバイスの両方がクラスタへの投票に数えられ、定足数を満たすことができます。
ノードが起動してクラスタメンバーになると、投票数は 1 となります。
ノードがインストールされているときは、投票数は 0 となります。
システム管理者がノードを保守状態にすると、投票数は 0 となります。
定足数デバイスは、デバイスに伴なう投票数に基づいて、投票に数えられます。定足数デバイスを構成すると、Sun Cluster ソフトウェアは定足数デバイスに投票数 N-1 を割り当てます。ここで N は、定足数デバイスに伴なう投票数となります。たとえば、投票数がゼロ以外の2 つのノードに接続された定足数デバイスの投票数は 1 (2-1) になります。
定足数デバイスは、次の 2 つの条件のうちの 1 つを満たす場合に投票に数えられます。
定足数デバイスに現在接続されている 1 つ以上のノードがクラスタメンバーである。
定足数デバイスに現在接続されている 1 つ以上のノードが起動中で、そのノードは定足数デバイスを所有する最後のクラスタパーティションのメンバーであった。
定足数デバイスは、クラスタのインストール中に構成するか、後で『Sun Cluster のシステム管理 (Solaris OS 版)』の「定足数の管理」に記載された手順に従って構成します。
クラスタの主要な問題は、クラスタがパーティション分割される (sprit-brain と呼ばれる) 原因となる障害です。この障害が発生すると、一部のノードが通信できなくなるため、個々のノードまたはノードの一部が、個々のクラスタまたはクラスタの一部を形成しようとします。各部分、つまりパーティションは、多重ホストデバイスに対して単独のアクセスと所有権を持つものと誤って認識します。そのため、複数のノードがディスクに書き込もうとすると、データが破壊される可能性があります。
障害による影響の防止機能では、多重ホストデバイスへのノードのアクセスを、ディスクへのアクセスを物理的に防止することによって制限します。障害が発生するかパーティション分割され、ノードがクラスタから切り離されると、障害による影響の防止機能によって、ノードがディスクにアクセスできなくなります。現在のメンバーノードだけが、ディスクへのアクセス権を持つため、データの完全性が保たれます。
ディスクデバイスサービスは、多重ホストデバイスを使用するサービスに対して、フェイルオーバー機能を提供します。現在、ディスクデバイスグループの主ノード (所有者) として機能しているクラスタメンバーに障害が発生するか、またはこのメンバーに到達できなくなると、新しい主ノードが選択されて、ディスクデバイスグループへのアクセスが可能になり、わずかな割り込みだけで処理が続行されます。このプロセス中、古い主ノードは、新しい主ノードが起動される前に、デバイスへのアクセスを放棄しなければなりません。ただし、あるメンバーがクラスタから切り離されて到達不能になると、クラスタはそのノードに対して、主ノードであったデバイスを解放するように通知できません。したがって、存続するメンバーが、障害の発生したメンバーから広域デバイスを制御してアクセスできるようにする手段が必要です。
SunPlex システムは、SCSI ディスク予約を使用して、障害による影響の防止機能を実装します。SCSI 予約を使用すると、障害が発生したノードは、多重ホストデバイスから阻止されて、これらのディスクへのアクセスが防止されます。
SCSI-2 ディスク予約は、ある形式の予約をサポートしています。これは、ディスクに接続されたすべてのノードへのアクセスを付与するか (予約が設定されていない場合)、または単一ノード (予約を保持するノード) へのアクセスを制限するものです。
クラスタメンバーは、別のノードがクラスタインターコネクトを介して通信していないことを検出すると、障害による影響の防止手順を開始して、そのノードが共有ディスクへアクセスするのを防止します。この障害による影響の防止機能が実行される場合、通常、阻止されるノードは、そのコンソールに「reservation conflict」(予約の衝突) というメッセージを表示して停止します。
予約の衝突は、ノードがクラスタメンバーではなくなったことが検出された後で、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 ベースのシステムで構成されている場合は、OpenBootTM PROM (OBP) プロンプトのままになります。どちらのアクションをとるかは、auto-boot? パラメータの設定に依存します。auto-boot? は、SPARC ベースのクラスタでは OpenBoot PROM ok プロンプトから、eeprom(1M) で設定できます。または、x86 ベースのクラスタでは、BIOS のブート後に任意で実行する SCSI ユーティリティで設定できます。
次に、定足数の構成について示します。
定足数デバイスには、ユーザーデータを含むことができます。
N 個の定足数デバイスが、それぞれ 1 から N 個のノードと N+1 ノードの 1 つに接続される N+1 構成では、1 から N のどのノードで障害が起きた場合でも、また、N/ 2 個のノードに障害が発生した場合でも、クラスタは影響を受けません。この可用性は、定足数デバイスが正しく機能していることを前提にしています。
1 つの定足数デバイスがすべてのノードに接続されている N ノード構成では、 N- 1 ノードのいずれかに障害が起きてもクラスタは影響を受けません。この可用性は、定足数デバイスが正しく機能していることを前提にしています。
1 つの定足数デバイスがすべてのノードに接続している N ノード構成では、すべてのクラスタノードが使用できる場合、定足数デバイスに障害が起きてもクラスタは影響を受けません。
望ましくない定足数の構成例については、「望ましくない定足数の構成」 を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。
以下の要件を守る必要があります。要件を守らないと、クラスタの可用性が損なわれる場合があります。
Sun Cluster ソフトウェアがご使用のデバイスを定足数デバイスとしてサポートしていることを確認します。
Sun Cluster ソフトウェアが定足数デバイスとしてサポートしているデバイスのリストについては、Sun のサービスプロバイダにお問い合わせください。
Sun Cluster ソフトウェアは、次の 2 種類の定足数デバイスをサポートしています。
SCSI-3 PGR 予約に対応した多重ホスト共有ディスク
SCSI-2 予約に対応した二重ホスト共有ディスク
2– ノード構成では、1 つのノードに障害が起きてももう 1 つのノードが動作を継続できるように 1 つ以上の定足数デバイスを構成する必要があります。図 3–2 を参照してください。
望ましくない定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。
以下の情報を使用して、ご使用のトポロジに最適な定足数の構成を評価してください。
クラスタの全ノードに接続できるデバイスがありますか。
ある場合は、そのデバイスを 1 つの定足数デバイスとして構成してください。この構成は最適な構成なので、別の定足数デバイスを構成する必要はありません。
この要件を無視して別の定足数デバイスを追加すると、追加した定足数デバイスによってクラスタの可用性が低下します。
ない場合は、1 つまたは複数のデュアルポートデバイスを構成してください。
定足数デバイスにより提供される投票の合計数が、ノードにより提供される投票の合計数より必ず少なくなるようにします。少なくなければ、すべてのノードが機能していても、すべてのディスクを使用できない場合にクラスタを形成できません。
特定の環境によっては、ニーズに合うよう全体的なクラスタの可用性を低くした方が望ましい場合があります。このような場合には、このベストプラクティスを無視できます。ただし、このベストプラクティスを守らないと、全体の可用性が低下します。たとえば、「変則的な定足数の構成」に記載されるような構成では、クラスタの可用性が低下し、定足数の投票がノードの投票を上回ります。クラスタには、ノード A とノード B の間の共有ストレージへのアクセスが失われると、クラスタ全体に障害が起きるという特性があります。
このベストプラクティスの例外については、「変則的な定足数の構成」を参照してください。
記憶装置へのアクセスを共有するノードのすべてのペア間で定足数デバイスを指定します。この定足数の構成により、障害防護プロセスが高速化されます。「2 ノード構成よりも大きい定足数」を参照してください。
ノードを追加したり、ノードに障害が発生すると、定足数デバイスの再構成は少し遅くなります。従って、必要以上の定足数デバイスを追加しないでください。
望ましくない定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。
望ましくない定足数の構成例については、「望ましくない定足数の構成」を参照してください。
2 ノードのクラスタを形成するには、2 つの定足投票数が必要です。これらの 2 つの投票数は、2 つのクラスタノード、または 1 つのノードと 1 つの定足数デバイスのどちらかによるものです。
定足数デバイスを持たない 2 ノードより大きいクラスタを構成することもできます。ただし、この場合、クラスタ内の過半数のノードなしにクラスタを開始できません。
図 3–3 は、ノード A および ノード B でミッションクリティカルなアプリケーション (Oracle データベースなど) を実行していることを前提としています。ノード A とノード B を使用できず、共有データにアクセスできない場合、クラスタ全体を停止させる必要がある場合があります。停止させない場合、この構成は高可用性を提供できないため、最適な構成とはなりません。
この例外に関するベストプラクティスについては、「定足数デバイスのベストプラクティスの順守」を参照してください。
推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。