Storage Foundation for Oracle® RAC 7.3.1 管理者ガイド - Solaris

CVM のアーキテクチャ

CVM は、「マスター/スレーブ」アーキテクチャで設計されています。 クラスタ内の 1 つのノードが論理ボリューム管理のマスターとして設定されており、他のすべてのノードはスレーブになります。 既存のマスターで障害が発生した場合は、いずれかのノードがマスターの役割を引き継ぎます。 CVM マスターはクラスタごとに存在しており、GAB と LLT を使用して設定データを転送します。

VxVM の場合と同様に、Volume Manager 設定デーモン vxconfigd は、論理ボリュームの設定を維持します。 このデーモンは、カーネルレベルでオペレーティングシステムを更新することによって、ボリュームの変更を処理します。 たとえば、ボリュームのミラーに障害が発生すると、そのミラーはボリュームから切断されます。vxconfigd が正しいアクションを決定し、新しいボリュームレイアウトを更新して、カーネルに新しいボリュームレイアウトを通知します。 CVM はこの動作を複数のノードまで拡張し、ボリューム変更をマスター vxconfigd に伝達します。

マスター vxconfigd プロセスはこれらの変更をスレーブ vxconfigd プロセスにプッシュし、各スレーブプロセスはローカルカーネルを更新します。 CVM のカーネルのモジュールは kmsg です。

図: ローレベルでの通信:を参照してください。

CVM は、ノード間で書き込みロックを設定しません。 各ノードはストレージのどの領域についても自由に更新できます。 データの整合性を保持するのは、すべて上位のアプリケーションの責任です。 アプリケーションの視点から見ると、スタンドアロンシステムは CVM システムと同じように論理ボリュームにアクセスします。

デフォルトでは、CVM は「統一共有ストレージ」モデルを適用します。 すべてのノードは、1 つのディスクグループの同じディスクセットに接続する必要があります。 1 つのディスクグループの物理ディスクセット全体を検出できないノードは、グループをインポートできません。 ノードが特定のディスクとの通信手段を失うと、CVM はそのノードを除外して、そのノードがそのディスクを使用できないようにします。

共有ストレージ全体へのアクセスを持たないクラスタノードでも参加できるように storage_connectivity チューニングパラメータを非対称に設定します。同様にノードは、ストレージに対するローカルエラーがあっても共有ディスクグループをインポートできます。

詳しくは、『Storage Foundation Cluster File System High Availability 管理者ガイド』を参照してください。