test

Sun Cluster の概念 (Solaris OS 版)

定足数と定足数デバイス

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

注 –

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

クラスタノードはデータとリソースを共有しており、複数のアクティブなパーティションがあるとデータが壊れる恐れがあるのでクラスタは決して複数のアクティブなパーティションに一度に分割しないでください。クラスタメンバーシップモニター (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 章「定足数の管理」で説明されている手順に従って行います。

障害による影響の防止について

クラスタの主要な問題は、クラスタがパーティション分割される (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 ユーティリティーを起動することで設定できます。

定足数の構成について

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

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

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

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 ノードより大きな構成での定足数

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

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

変則的な定足数の構成

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

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

図 3–3 変則的な構成

図 : NodeA-D。Node A/B は QD1-4 に接続。NodeC は QD4 に接続。NodeD は QD4 に接続。合計投票 = 10。定足数に必要な投票 = 6。

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

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

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