この節には、次のトピックが含まれます。
Sun Cluster ソフトウェアが定足数デバイスとしてサポートする特定のデバイスの一覧については、Sun のサービスプロバイダにお問い合わせください。
クラスタノードはデータとリソースを共有しており、複数のアクティブなパーティションがあるとデータが壊れる恐れがあるのでクラスタは決して複数のアクティブなパーティションに一度に分割しないでください。クラスタメンバーシップモニター (Cluster Membership Monitor、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 章「定足数の管理」で説明されている手順に従って行います。
次に、定足数の構成について示します。
定足数デバイスには、ユーザーデータを含むことができます。
N+1 の構成 (N 個の定足数デバイスがそれぞれ、1 から N までの Solaris ホストのうちの 1 つのホストと N+1 番目の Solaris ホストに接続されている構成) では、1 から N までのどの Solaris ホストで障害が発生しても、N/2 個のうちの任意の Solaris ホストに障害が発生しても、そのクラスタは影響を受けません。この可用性は、定足数デバイスが正しく機能していることを前提にしています。
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) デバイス。
定足数サーバーマシン上で動作する定足数サーバープロセス。
ディスクのフェンシングをオフに切り替え、ソフトウェア定足数を使用している場合は任意の共有ディスク。ソフトウェア定足数は、Sun が開発したプロトコルで、SCSI Persistent Group Reservations (PGR) の形成をエミュレートします。
SATA (Serial Advanced Technology Attachment) ディスクなど、SCSI に対応していないディスクを使用する場合は、フェンシングをオフにしてください。
レプリケートされたデバイスは定足数デバイスとして使用できません。
2 ホスト構成では、1 つのホストに障害が起きてももう 1 つのホストが動作を継続できるように、少なくとも 1 つの定足数デバイスを構成する必要があります。詳細は、図 3–2 を参照してください。
回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。
以下の情報を使用して、ご使用のトポロジに最適な定足数の構成を評価してください。
クラスタの全 Solaris ホストに接続できるデバイスがありますか。
ある場合は、そのデバイスを 1 つの定足数デバイスとして構成してください。この構成は最適な構成なので、別の定足数デバイスを構成する必要はありません。
この要件を無視して別の定足数デバイスを追加すると、追加した定足数デバイスによってクラスタの可用性が低下します。
ない場合は、1 つまたは複数のデュアルポートデバイスを構成してください。
定足数デバイスにより提供される投票の合計数が、ノードにより提供される投票の合計数より必ず少なくなるようにします。少なくなければ、すべてのノードが機能していても、すべてのディスクを使用できない場合、そのノードはクラスタを形成できません。
特定の環境によっては、自分のニーズに合うように、全体的なクラスタの可用性を低くした方が望ましい場合があります。このような場合には、このベストプラクティスを無視できます。ただし、このベストプラクティスを守らないと、全体の可用性が低下します。たとえば、「変則的な定足数の構成」に記載されている構成では、クラスタの可用性は低下し、 定足数の投票がノードの投票を上回ります。クラスタでは、Host A と Host B 間にある共有ストレージへのアクセスが失われると、クラスタ全体に障害が発生します。
このベストプラクティスの例外については、「変則的な定足数の構成」を参照してください。
記憶装置へのアクセスを共有するホストのすべてのペア間で定足数デバイスを指定します。この定足数の構成により、障害からの影響の防止プロセスが高速化されます。詳細は、「2 ホストより大きな構成での定足数」を参照してください。
ノードを追加したり、ノードに障害が発生すると、定足数デバイスの再構成は少し遅くなります。従って、必要以上の定足数デバイスを追加しないでください。
回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。
この節では、推奨される定足数の構成例を示します。回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。
2 ホストのクラスタを形成するには、2 つの定足投票数が必要です。これらの 2 つの投票数は、2 つのクラスタホスト、または 1 つのホストと 1 つの定足数デバイスのどちらかによるものです。
クラスタに 3 つ以上のホストが含まれている場合、定足数デバイスを持たない 1 つのホストに障害が発生してもクラスタはその影響を受けないので、定足数デバイスは必要ありません。ただし、このような条件下では、クラスタ内に過半数のホストがないとクラスタを起動できません。
3 つ以上のホストを含むクラスタに定足数デバイスを追加できます。ホストおよび定足数デバイスの投票数を含め、パーティションが定足投票数の過半数を獲得している場合、そのパーティションはクラスタとして存続できます。したがって、定足数デバイスを追加する場合は、定足数デバイスを構成するかどうか、および定足数デバイスの構成先を選択するときに、発生する可能性があるホストおよび定足数デバイスの障害を考慮するようにしてください。
図 3–3 では、Host A と Host B でミッションクリティカルなアプリケーション (Oracle データベースなど) を実行していると仮定します。Host A と Host B を使用できず、共有データにアクセスできない場合、クラスタ全体を停止させる必要がある場合があります。停止させない場合、この構成は高可用性を提供できないため、最適な構成とはなりません。
この例外に関するベストプラクティスについては、「定足数デバイスのベストプラクティスの順守」を参照してください。
この節では、回避すべき定足数の構成例を示します。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。