test

Sun Cluster の概念 (Solaris OS 版)

定足数と定足数デバイス

この節には、次のトピックが含まれます。

注 –

Sun Cluster ソフトウェアが定足数デバイスとしてサポートする特定のデバイスの一覧については、Sun のサービスプロバイダにお問い合わせください。

クラスタノードはデータとリソースを共有しており、複数のアクティブなパーティションがあるとデータが壊れる恐れがあるのでクラスタは決して複数のアクティブなパーティションに一度に分割しないでください。クラスタメンバーシップモニター (Cluster Membership Monitor、CMM) および定足数アルゴリズムにより、たとえクラスタ接続がパーティション分割されている場合でも、いつでも同じクラスタのインスタンスが 1 つだけは動作していることが保証されます。

定足数と CMM の概要については、『Sun Cluster の概要 (Solaris OS 版)』の「クラスタメンバーシップ」を参照してください。

クラスタのパーティション分割からは、次の 2 種類の問題が発生します。

Split brain は、ノード間のクラスタ接続が失われ、クラスタがサブクラスタにパーティション分割されるときに起きます。あるパーティションのノードはほかのパーティションのノードと通信できないため、各パーティションは自分が唯一のパーティションであると認識します。

amnesia は、停止したクラスタが、停止時よりも古いクラスタ構成データに基づいて再起動されたときに発生します。この問題は、最後に機能していたクラスタパーティションにないノード上のクラスタを起動するときに起きる可能性があります。

Sun Cluster ソフトウェアは、split brain と amnesia を次の操作により回避します。

過半数の投票数を持つパーティションは、定足数を獲得し、動作可能になります。この過半数の投票メカニズムにより、クラスタ内に 3 つ以上のノードが構成されているときに split brain と amnesia を防ぐことができます。ただし、クラスタ内に 3 つ以上のノードが構成されている場合、ノードの投票数を数えるだけでは十分ではありません。しかし、2 ホストクラスタでは過半数が 2 であるため、このような 2 ホストクラスタがパーティション分割された場合、いずれかのパーティションが定足数を獲得するために外部投票が必要です。この外部からの投票は「定足数デバイス」によって行われます。

定足数投票数について

clquorum show コマンドを使って、次の情報を調べます。

詳細は、 cluster(1CL) のマニュアルページを参照してください。

ノードおよび定足数デバイスの両方がクラスタへの投票に数えられ、定足数を満たすことができます。

ノードは、ノードの状態に応じて投票に数えられます。

定足数デバイスは、デバイスに伴う投票数に基づいて、投票に数えられます。定足数デバイスを構成するとき、Sun Cluster ソフトウェアは定足数デバイスに N-1 の投票数を割り当てます (N は定足数デバイスに伴う投票数)。たとえば、2 つのノードに接続された、投票数がゼロ以外の定足数デバイスの投票数は 1 (2-1) になります。

定足数デバイスは、次の 2 つの条件のうちの 1 つを満たす場合に投票に数えられます。

定足数デバイスの構成は、クラスタをインストールするときに行うか、あるいはあとで、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 6 章「定足数の管理」で説明されている手順に従って行います。

定足数の構成について

次に、定足数の構成について示します。

回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

定足数デバイス要件の順守

Sun Cluster ソフトウェアがご使用のデバイスを定足数デバイスとしてサポートしていることを確認します。この要件を無視すると、クラスタの可用性が損なわれる場合があります。

注 –

Sun Cluster ソフトウェアが定足数デバイスとしてサポートする特定のデバイスの一覧については、Sun のサービスプロバイダにお問い合わせください。

Sun Cluster ソフトウェアは、次の種類の定足数デバイスをサポートしています。

注 –

レプリケートされたデバイスは定足数デバイスとして使用できません。

2 ホスト構成では、1 つのホストに障害が起きてももう 1 つのホストが動作を継続できるように、少なくとも 1 つの定足数デバイスを構成する必要があります。詳細は、図 3–2 を参照してください。

回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

定足数デバイスのベストプラクティスの順守

以下の情報を使用して、ご使用のトポロジに最適な定足数の構成を評価してください。

回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

推奨される定足数の構成

この節では、推奨される定足数の構成例を示します。回避すべき定足数の構成例については、「望ましくない定足数の構成」を参照してください。

2 ホスト構成の定足数

2 ホストのクラスタを形成するには、2 つの定足投票数が必要です。これらの 2 つの投票数は、2 つのクラスタホスト、または 1 つのホストと 1 つの定足数デバイスのどちらかによるものです。

図 3–2 2 ホスト構成

図: 2 つのホストに接続された 1 つの定足数デバイスを持つホスト A およびホスト B を示しています。

2 ホストより大きな構成での定足数

クラスタに 3 つ以上のホストが含まれている場合、定足数デバイスを持たない 1 つのホストに障害が発生してもクラスタはその影響を受けないので、定足数デバイスは必要ありません。ただし、このような条件下では、クラスタ内に過半数のホストがないとクラスタを起動できません。

3 つ以上のホストを含むクラスタに定足数デバイスを追加できます。ホストおよび定足数デバイスの投票数を含め、パーティションが定足投票数の過半数を獲得している場合、そのパーティションはクラスタとして存続できます。したがって、定足数デバイスを追加する場合は、定足数デバイスを構成するかどうか、および定足数デバイスの構成先を選択するときに、発生する可能性があるホストおよび定足数デバイスの障害を考慮するようにしてください。

図: 構成 1: HostA-D。A/B が (->) QD1 に接続。C/D -> QD2。構成 2: HostA-C。A/C -> QD1。B/C -> QD2。構成 3: HostA-C -> 1 つの QD。

変則的な定足数の構成

図 3–3 では、Host A と Host B でミッションクリティカルなアプリケーション (Oracle データベースなど) を実行していると仮定します。Host A と Host B を使用できず、共有データにアクセスできない場合、クラスタ全体を停止させる必要がある場合があります。停止させない場合、この構成は高可用性を提供できないため、最適な構成とはなりません。

この例外に関するベストプラクティスについては、「定足数デバイスのベストプラクティスの順守」を参照してください。

図 3–3 変則的な構成

図: HostA-D。Host A/B は QD1-4 に接続。HostC は QD4 に接続。HostD は QD4 に接続。合計投票数 = 10。定足数に必要な投票数 = 6。

望ましくない定足数の構成

この節では、回避すべき定足数の構成例を示します。推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

図: 構成 1: HostA-B。A/B は -> QD1/2 に接続。構成 2: HostA-D。A/B -> QD1/2。構成 3: HostA-C。A/B-> QD1/2 & C -> QD2。