test

Sun Cluster の概念 (Solaris OS 版)

高可用性フレームワーク

SunPlex システムでは、ネットワークインタフェース、アプリケーションそのもの、ファイルシステム、および多重ホストデバイスなど、ユーザーとデータ間のパスにおけるすべてのコンポーネントの可用性が高くなっています。一般に、システムで単一 (ソフトウェアまたはハードウェア) の障害が発生してもあるクラスタコンポーネントが稼働し続けられる場合、そのコンポーネントは高可用性であると考えられます。

次の表は、SunPlex コンポーネントの障害の種類 (ハードウェアとソフトウェアの両方) と、高可用性フレームワークに組み込まれた回復の種類を示したものです。

表 3–1 SunPlex システムの障害の検出と回復のレベル

障害が発生したクラスタリソース 

ソフトウェアの回復 

ハードウェアの回復 

データサービス 

HA API、HA フレームワーク 

なし 

パブリックネットワークアダプタ 

IP ネットワークマルチパス 

複数のパブリックネットワークアダプタカード 

クラスタファイルシステム 

一次複製と二次複製 

多重ホストデバイス 

ミラー化された多重ホストデバイス 

ボリューム管理 (Solaris Volume Manager と VERITAS Volume Manager、SPARC ベースのクラスタに限って使用可能) 

ハードウェア RAID-5 (Sun StorEdgeTM A3x00 など)

広域デバイス 

一次複製と二次複製 

デバイス、クラスタトランスポート接続点への多重パス 

プライベートネットワーク 

HA トランスポートソフトウェア 

ハードウェアから独立した多重プライベートネットワーク 

ノード 

CMM、フェイルファーストドライバ 

複数ノード 

Sun Cluster ソフトウェアの高可用性フレームワークは、ノードの障害を素早く検出して、クラスタ内の残りのノードにあるフレームワークリソース用に新しい同等のサーバーを作成します。どの時点でもすべてのフレームワークリソースが使用できなくなることはありません。障害が発生したノードの影響を受けないフレームワークリソースは、回復中も完全に使用できます。さらに、障害が発生したノードのフレームワークリソースは、回復されると同時に使用可能になります。回復されたフレームワークリソースは、他のすべてのフレームワークリソースが回復するのを待機する必要はありません。

最も可用性の高いフレームワークリソースは、そのリソースを使用するアプリケーション (データサービス) に対して透過的に回復されます。フレームワークリソースのアクセス方式は、ノードの障害時にも完全に維持されます。アプリケーションは、フレームワークリソースサーバーが別のノードに移動したことを認識できないだけです。単一ノードの障害は、別ノードからのディスクに対する代替ハードウェアパスが存在するかぎり、ファイル、デバイス、およびディスクボリュームを使用する残りのノード上のプログラムに対して完全に透過的です。この例としては、複数ノードへのポートを持つ多重ホストデバイスの使用があります。

クラスタメンバーシップモニター (CMM)

データが破壊から保護されるように保証するには、すべてのノードが、クラスタメンバーシップに対して一定の同意に達していなければなりません。必要であれば、CMM は、障害に応じてクラスタサービス (アプリケーション) のクラスタ再構成を調整します。

CMM は、クラスタのトランスポート層から、他のノードへの接続に関する情報を受け取ります。CMM は、クラスタインターコネクトを使用して、再構成中に状態情報を交換します。

CMM は、クラスタメンバーシップの変更を検出すると、クラスタの同期化構成を実行します。これにより、クラスタリソースは、クラスタの新しいメンバーシップに基づいて再分配されます。

Sun Cluster ソフトウェアの以前のリリースとは異なり、CMM は完全にカーネルで実行されます。

クラスタが複数の独立したクラスタに分割されないように自身を防御する方法については、「障害による影響の防止について」を参照してください。

フェイルファーストメカニズム

CMM はノードで重大な問題を検出すると、クラスタフレームワークに依頼して、ノードを強制的に停止 (パニック) させ、クラスタメンバーシップからそのノードを取り除きます。この機構を「フェイルファースト」といいます。フェイルファーストでは、ノードは次の 2 つの方法で停止します。

クラスタデーモンが停止すると、ノードが強制的に停止させられ、次のようなメッセージがそのノードのコンソールに表示されます。


panic[cpu0]/thread=40e60: Failfast: Aborting because "pmfd" died 35 seconds ago.
409b8 cl_runtime:__0FZsc_syslog_msg_log_no_argsPviTCPCcTB+48 (70f900, 30, 70df54, 407acc, 0)
%l0-7: 1006c80 000000a 000000a 10093bc 406d3c80 7110340 0000000 4001 fbf0

パニック後、ノードは再起動してクラスタに再度加わろうとするか、またはクラスタが SPARC ベースのシステムで構成されている場合は、OpenBootTM PROM (OBP) プロンプトのままになります。どちらのアクションをとるかは、auto-boot? パラメータの設定に依存します。auto-boot? は OpenBoot PROM ok プロンプトから、 eeprom 1M で設定できます。

クラスタ構成レポジトリ (CCR)

CCR は、更新に 2 フェーズのコミットアルゴリズムを使用します。更新はすべてのクラスタメンバーで正常に終了しなければなりません。そうしないと、その更新はロールバックされます。CCR はクラスタインターコネクトを使用して、分散更新を適用します。

注意 – 注意 –

CCR はテキストファイルで構成されていますが、CCR ファイルを手作業で絶対に編集しないでください。各ファイルには、ノード間の一貫性を保証するための検査合計レコードが含まれています。CCR ファイルを手作業で更新すると、ノードまたはクラスタ全体の機能が停止する可能性があります。

CCR は、CMM に依存して、定足数 (quorum) が確立された場合にのみクラスタが実行されるように保証します。CCR は、クラスタ全体のデータの一貫性を確認し、必要に応じて回復を実行し、データへの更新を容易にします。