高可用性フレームワーク

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

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

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

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

ゾーンメンバーシップ

また、Sun Cluster ソフトウェアはゾーンがいつ起動または停止するかを検出することによって、ゾーンメンバーシップを追跡します。こうした変化も再構成の原因となります。再構成によって、クラスタ内のノード間にクラスタリソースを再配置できます。

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

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

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

CMM は、クラスタメンバーシップの変更を検出すると、それに合わせてクラスタを構成します。このような同期構成では、クラスタの新しいメンバーシップに基づいて、クラスタリソースが再配布されることがあります。

フェイルファースト機構

「フェイルファースト」機構では、グローバルクラスタ投票ノードまたはグローバルクラスタ非投票ノードのいずれかにおける重大な問題が検出されます。フェイルファーストで問題が検出されたときに、Sun Cluster が取る措置は、問題が投票ノードで発生するか非投票ノードで発生するかによって異なります。

重大な問題が投票ノードで発生した場合、Sun Cluster は強制的にノードを停止させます。Sun Cluster は次にノードをクラスタメンバーシップから削除します。

重大な問題が非投票ノードで発生した場合、Sun Cluster は非投票ノードを再起動します。

ノードは、ほかのノードとの接続を失うと、通信が可能なノードとクラスタを形成しようとします。そのセットのノードが定足数に達しない場合、Sun Cluster ソフトウェアはノードを停止して、共有ディスクからノードをフェンスします。つまり、ノードの共有ディスクへのアクセスを遮ります。

フェンシングは、選択したディスクまたはすべてのディスクに対してオフにできます。

不適切な状況でフェンシングを無効にすると、アプリケーションのフェイルオーバー時にデータが破損する危険性が高くなります。フェンシングの無効化を検討する場合には、データ破損の可能性を十分に調査してください。SATA (Serial Advanced Technology Attachment) ディスクなど、共有記憶装置が SCSI プロトコルに対応していない場合、またはクラスタの外部にあるホストからクラスタの記憶装置へのアクセスを許可する場合にフェンシングをオフにします。

1 つまたは複数のクラスタ固有のデーモンが停止すると、Sun Cluster ソフトウェアは重大な問題が発生したことを宣言します。Sun Cluster ソフトウェアは、投票ノードと非投票ノードの両方でクラスタ固有のデーモンを実行します。重大な問題が発生すると、Sun Cluster はノードを停止して削除するか、問題が発生した非投票ノードを再起動します。

非投票ノードで実行されるクラスタ固有のデーモンが失敗すると、次のようなメッセージがコンソールに表示されます。

cl_runtime: NOTICE: Failfast: Aborting because "pmfd" died in zone "zone4" (zone id 3)
35 seconds ago.

投票ノードで実行されるクラスタ固有のデーモンが失敗し、ノードでパニックが発生すると、次のようなメッセージがコンソールに表示されます。

panic[cpu1]/thread=2a10007fcc0: Failfast: Aborting because "pmfd" died in zone "global" (zone id 0)
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

パニック後、Solaris ホストは再起動し、ノードはクラスタに再び参加しようとすることがあります。あるいは、SPARC ベースのシステムで構成されているクラスタの場合、そのホストは OpenBoot PROM (OBP) プロンプトのままになることがあります。ホストがどちらのアクションをとるかは、auto-boot? パラメータの設定によって決定されます。OpenBoot PROM の ok プロンプトで、eeprom コマンドにより auto-boot? を設定できます。詳細は、eeprom(1M) のマニュアルページを参照してください。

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

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

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

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