ダーティーリージョンログと CVM

ダーティーリージョンログ (DRL) は、システム故障時にミラー化ボリュームの迅速な回復を実現する、ボリュームのオプションプロパティです。ダーティーリージョンログは、クラスタ共有可能ディスクグループでサポートされます。この節では DRL の概要を簡単に説明するとともに、SSVM DRL と CVM 実装の DRL の違いを説明します。DRL についての詳細は『Sun StorEdge Volume Manager 2.6 システム管理ガイド』を参照してください。

DRL は、ミラー化ボリュームへの入出力書き込みによって変化したリージョンを追跡し、この情報を使用して、回復が必要なボリューム部分だけを回復します。DRL はボリュームを連続するリージョンの集合に論理的に分割し、ボリュームの各リージョンを表す状態ビットを含むダーティーリージョンログを管理します。DRL が使用可能になっているボリュームのダーティーリージョンログは、「ログサブディスク」に格納されます。DRL 付きのボリュームは、ボリュームの 1 つのプレックスと関連付けられた最低 1 つのログサブディスクを持ちます。

ボリュームにデータを書き込む前に、書き込まれるリージョンがログでダーティーとしてマークされます。書き込みによって以前クリーンだったログリージョンがダーティになる場合には、ログがディスクに同期的に書き込まれ、それから書き込み操作が発生します。システム再起動時には、ボリュームマネージャはダーティーリージョンログでダーティーとしてマークされたボリュームのリージョンだけを回復します。

DRL の CVM 実装は、SSVM 実装とはやや異なります。次の各節では、いくつかの相違点について概略を説明するとともに、CVM 実装の一部の機能を説明します。

ログ書式とサイズ

CVM ダーティーリージョンログは、SSVM と同様、ミラー化ボリューム内のログサブディスクに存在します。

SSVM ダーティーリージョンログには、1 つの回復マップと 1 つのアクティブマップがあります。これに対し CVM ダーティーリージョンログには、1 つの回復マップと複数のアクティブマップ (クラスタ内のノードごとに 1 つ) があります。CVM では SSVM とは異なり、回復マップがログの先頭に配置されます。

CVM ダーティーリージョンログは、クラスタ内の全ノード用のアクティブマップに加えて回復マップを収容しなければならないため、一般的に SSVM ダーティーリージョンログよりサイズが大きくなります。ダーティーリージョンログ内の各マップのサイズは、1 つ以上の整数個ブロックです。vxassist によって自動的に十分な大きさのダーティーリージョンログが割り当てられます。

ログサイズは、ボリュームサイズとノード数によって異なります。ログは、すべてのマップ (ノードごとに 1 つのマップと、回復マップ) を収容できる十分な大きさが必要です。各マップは、ボリュームサイズ 2G バイトごとに 1 ブロックが必要です。2 ノードクラスタ内の 2G バイトボリュームの場合、ログサイズとして 5 ブロック (マップごとに 1 ブロック) あれば十分です。これが最小のログサイズです。また、4 ノードクラスタ内の 4G バイトボリュームの場合は、ログサイズとして 10 ブロックが必要です。これ以上のボリュームの場合は、これらと同様に増加します。

互換性

CVM DRL ヘッダーは、CVM 固有のマジックナンバーが追加される点を除いて、SSVM のそれと同じです。

SSVM ディスクグループ (およびそのボリューム) を CVM 共有ディスクグループとしてインポートすることは可能であり、その逆も可能です。ただし、インポートしたディスクグループのダーティーリージョンログは無効と見なされ、完全回復が実行される場合があります。

CVM 共有ディスクグループが SSVM システムによってインポートされた場合、SSVM は CVM ボリュームのログを無効と見なし、ボリュームの完全回復を実行します。この回復が完了すると、ボリュームマネージャは CVM ダーティーリージョンログを使用するようになります。

CVM は非共有 SSVM ボリュームに対して DRL 回復を実行できます。ただし、SSVM ボリュームが CVM システムに移動され、共有されるものとしてインポートされた場合、クラスタ内の全ノードに対応するにはダーティーリージョンログは小さすぎます。したがって、CVM はそのログを無効なものとしてマークし、完全回復を実行します。同様に、DRL ボリュームを 2 ノードクラスタから 4 ノードクラスタに移動した場合にも、ログサイズが小さすぎることになり、CVM はそれに対処するためボリュームの完全回復を実行します。どちらの場合にも、システム管理者は十分なサイズの新しいログを割り当てる必要があります。

DRL による回復

クラスタ内の 1 つ以上のノードに障害が発生した場合、DRL は障害の発生時点でそれらのノードが使用していたすべてのボリュームの回復を処理することができなければなりません。最初のクラスタ起動時に、すべてのアクティブマップが回復マップに組み込まれます。これは volume start 動作時に行われます。

障害が発生した (すなわち、「ダーティー」としてクラスタから切り離された) ノードは、影響されるすべてのボリュームで、そのノードの DRL アクティブマップが回復マップに組み込まれるまで、クラスタへの再結合は認められません。回復ユーティリティは障害が発生したノードのアクティブマップを回復マップと比較し、必要な更新処理を行います。その後、そのノードはクラスタに再結合し、ボリュームへの入出力を再開できるようになります (それによってアクティブマップが上書きされる)。他のノードはこの処理が行われている間にも、引き続き入出力を実行できます。

CVM カーネルは、どのノードに障害が発生したかを追跡します。ある時点でクラスタ内で複数のノード回復が進行中のとき、それぞれの回復処理と回復マップの更新が互いに競合する可能性があります。したがって CVM カーネルは DRL 回復状態の変更を追跡し、入出力動作の衝突を防止します。

マスターは各ボリュームについて DRL 回復マップ更新の揮発性 (メモリー上で動作する) 追跡を実行し、複数のユーティリティが回復マップを同時に変更する事態を防止します。