test

Sun Cluster の概念 (Solaris OS 版)

定足数および定足数デバイス

ここでは、次の内容について説明します。

注 –

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

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

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

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

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

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

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

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

定足投票数について

scstat -q コマンドを使って、以下の情報を調べます。

このコマンドの詳細については、scstat(1M) のマニュアルページを参照してください。

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

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

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

定足数デバイスは、次の 2 つの条件のうちの 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 ユーティリティで設定できます。

定足数の構成について

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

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

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

以下の要件を守る必要があります。要件を守らないと、クラスタの可用性が損なわれる場合があります。

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

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

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

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

推奨される定足数の構成

望ましくない定足数の構成例については、「望ましくない定足数の構成」を参照してください。

2 ノード構成の定足数

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

図 3–2 2 ノード構成

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

2 ノード構成よりも大きい定足数

定足数デバイスを持たない 2 ノードより大きいクラスタを構成することもできます。ただし、この場合、クラスタ内の過半数のノードなしにクラスタを開始できません。

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

変則的な定足数の構成

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

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

図 3–3 変則的な構成

図 : ノード A-D。QD1-4 に接続したノード A/B。QD4 に接続したノード C。QD4 に接続したノード D。 合計投票数 = 10。定足数に必要な投票数 = 6.

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

推奨される定足数の構成例については、「推奨される定足数の構成」を参照してください。

図 : 構成 1: QD1/2 に接続したノード A/B。構成 2: QD1/2 に接続したノード A- D。構成 3: QD1/2 に接続したノード A-C。QD2 に接続したノード C。