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