test

Sun Cluster 2.2 Cluster Volume Manager ガイド

Cluster Volume Manager の概要

Cluster Volume Manager (CVM) は、ボリュームマネージャの制御下で複数のホストが特定のディスクの集合を同時にアクセスし管理することを可能にする SSVM の拡張機能です。「クラスタ」は、ディスクの集合を共有するホストの集合です。各ホストは、クラスタ内の「ノード」と呼ばれます。一連のノードがネットワークで接続されます。いずれか 1 つのノードが故障しても、他のノードは引き続きディスクにアクセスできます。CVM はすべてのノードについて、ディスク構成 (変更も含む) に関する同じ論理的ビューを提供します。

注 -

CVM は現在、1 クラスタあたり最大 4 ノードをサポートします。

共有ボリュームマネージャオブジェクト

ボリュームマネージャオブジェクトは、CVM で使用する場合、クラスタ内のすべてのノードで共有できます。

CVM では次の 2 種類のディスクグループを使用できます。

CVM を使用する場合、ほとんどのディスクグループが共有ディスクグループです。ただし、ルートディスクグループ (rootdg) は常に非共有ディスクグループです。

共有ディスクグループ内のボリュームマネージャディスクは、クラスタ内のすべてのノードによって共有されるので、クラスタ内の複数のノードが特定のボリュームマネージャディスクを同時にアクセスする可能性があります。同様に、共有ディスクグループ内のすべてのボリュームが、クラスタ内のすべてのノードによって共有される可能性があります。ボリュームマネージャディスクまたはボリュームは、複数のノードによって同時にアクセスされたとき「共有された」と見なされます。

注 -

CVM を通じて実行されるのは、raw デバイスアクセスだけです。CVM はファイルシステムを持つ共有ボリュームをサポートしません。CVM は現在、クラスタ共有可能ディスクグループの RAID5 ボリュームをサポートしていません。ただし、クラスタの特定のノードに接続された非共有ディスクグループでは RAID5 ボリュームを使用できます。

Cluster Volume Manager の動作

CVM は、外部から提供される「クラスタマネージャ」(クラスタのメンバーの変更を CVM に通知するデーモン) と連携します。各ノードはそれぞれ独自に起動し、動作環境、CVM、およびクラスタマネージャのコピーをそれぞれ独自に持ちます。あるノードがクラスタに「結合」すると、共有ディスクにアクセスできるようになります。ノードがクラスタから「切り離される」と、それらの共有ディスクにアクセスできなくなります。システム管理者はノード上でクラスタマネージャを起動することにより、そのノードをクラスタに結合させます。

図 2-1 は、単純なクラスタ編成を示しています。すべてのノードがネットワークで接続されています。これらのノードがさらに、クラスタ共有可能ディスクグループに接続されています。クラスタマネージャにとっては、どのノードも同等です。ただし CVM では、1 つのノードが「マスターノード」、他のノードが「スレーブノード」として動作することが要求されます。マスターノードは、ある種のボリュームマネージャの動作を調整します。CVM ソフトウェアは、どのノードがマスター機能を実行するかを決定します (どのノードでもマスターノードの役割を果たすことができます)。マスターとスレーブの役割は、マスターノードがクラスタから切り離される場合にのみ変化します。マスターノードがクラスタから切り離されると、スレーブノードのいずれか 1 つが新しいマスターになります。この例ではノード 1 がマスターノードであり、ノード 2、3、4 がスレーブノードです。

図 2-1 4 ノードクラスタの例

Graphic

システム管理者は vxdg ユーティリティを使用してディスクグループをクラスタ共有可能なものに指定します。詳細については 「vxdg コマンド」を参照してください。ディスクグループが 1 つのノードに対してクラスタ共有可能なものとしてインポートされると、そのディスクヘッダーにはクラスタ ID が付けられます。他のノードがクラスタに結合すると、それらのノードはそのディスクグループをクラスタ共有可能なものとして認識し、インポートします。システム管理者は任意の時点で共有ディスクグループをインポートまたはデポートすることができ、その操作はすべてのノードで分散形式で発生します。

各物理ディスクには固有のディスク ID が付けられます。マスター上でクラスタを起動した後、マスターは (noautoimport 属性が設定されたものを除いて) すべての共有ディスクグループをインポートします。スレーブが結合を試みると、マスターはインポートしたディスク ID のリストをスレーブに送信します。スレーブはそれらのディスクにすべてアクセス可能かどうかを検査します。リストに含まれるインポート済みディスクのいずれかにアクセスできない場合、スレーブはクラスタへの結合の試みを中止します。リストに含まれるすべてのディスクにアクセスできる場合、スレーブはマスターと同じ共有ディスクグループの集合をインポートし、クラスタに結合します。ノードがクラスタから切り離されるとき、そのノードはインポートした共有ディスクグループをすべてデポートしますが、クラスタに残るノードでは、それらのディスクグループはインポートされた状態を続けます。これはノードの種類 (マスターまたはスレーブ) に関わらず、ノードがクラスタから切り離される場合に該当します。

共有ディスクグループを再構成する処理は、すべてのノードの共同作業によって実行されます。ディスクグループの構成変更はすべてのノードで同時に発生し、変更内容はすべてのノードで同じです。この変更の性質は不可分であり、すべてのノードで同時に発生するか、あるいはまったく発生しないかのどちらかです。

クラスタのすべてのメンバーが、任意のクラスタ共有可能ディスクグループを同時に読み取りおよび書き込みアクセスすることができます。一部のノードで障害が発生しても、クラスタ内の正常なノードによるアクセスが影響されることはありません。クラスタ内で少なくとも 1 つのノードが正常である限り、クラスタ共有可能ディスクグループに含まれるデータは使用可能です。どのノードがクラスタ共有可能ディスクグループにアクセスするかは関係なく、ディスクグループの構成は一定に表示されます。各ノードで実行するアプリケーション群は、ボリュームマネージャディスク上のデータに同時にアクセスできます。

注 -

CVM には、複数のノードによる共有ボリュームへの同時の書き込みに対する保護手段はありません。アプリケーションレベルで (たとえば分散型ロックマネージャなどの使用によって) 整合性が管理されることを前提としています。

構成と初期化

新しいクラスタに初めてノードが結合するには、事前にシステム管理者がある種の構成情報を提供する必要があります。この情報はクラスタマネージャの設定時に提供され、通常はクラスタマネージャ構成データベースに格納されます。この情報の正確な内容と書式は、クラスタマネージャの特性によって異なります。

CVM が必要とする情報は、次のとおりです。

クラスタの再構成

クラスタの状態に (ノードの切り離しまたは結合という形式で) 変更があったとき、「クラスタの再構成」が行われます。各ノードのクラスタマネージャがクラスタ内の他のノードを監視し、クラスタのメンバーに変更があったとき、クラスタ再構成ユーティリティ vxclust を呼び出します。vxclust はクラスタ再構成を調整し、CVM とクラスタマネージャとの間の通信を提供します。クラスタマネージャと vxclust が連携して、クラスタ再構成の各段階が正しい順序で行われることが保証されます。

クラスタの再構成時、共有ディスクへの入出力は一時停止され、再構成が完了すると再開されます。そのため、アプリケーションが少しの間停止するように見えます。

他の処理 (ボリュームマネージャの動作や回復など) が進行中の場合は、それらの処理が完了するまでクラスタの再構成が遅延される場合があります。ボリュームの再構成 (詳細は後述) は、クラスタ再構成と同時には行われません。状況によっては、処理が停止され、後で再開される場合があります。ほとんどの場合、クラスタの再構成が優先されます。ただし、ボリュームの再構成がコミット段階のときは、それが先に処理されます。

クラスタの再構成についての詳細は、「vxclust コマンド」を参照してください。

ボリュームの再構成

「ボリュームの再構成」は、構成内のボリュームマネージャオブジェクト (ディスクグループ、ボリューム、ミラーなど) を作成、変更、削除するプロセスです。クラスタでは、このプロセスはすべてのノードの共同作業によって実行されます。ボリュームの再構成は、すべてのノードに分散されます。つまり、すべてのノードで同じ構成変更が同時に発生します。

ボリュームの再構成では、vxconfigd デーモンが使用されます。再構成が正常に行われるためには、vxconfigd がすべてのノードで動作している必要があります。

再構成は「起動ノード」によって開始され、調整されます。起動ノードとは、システム管理者がボリュームマネージャオブジェクトの変更を要求するユーティリティを実行するノードです。

起動ノード上のユーティリティは、ローカルの vxconfigd デーモンと通信し、そのデーモンはローカルの検査を行なって、要求された変更が適切かどうかを確認します。たとえば、新しいディスクグループの作成を試みた場合、同じ名前のディスクグループがすでに存在していれば、その試みは失敗します。次に起動ノードの vxconfigd は、変更についての詳細事項を含むメッセージをクラスタ内の他のすべてのノードの vxconfigd デーモンに送信します。それぞれの非起動ノードの vxconfigd は、独自の検査を行います。たとえば、作成予定のディスクグループと同じ名前の非共有ディスクグループが非起動ノードに存在しないことが確認されます。新しいディスクが関与する場合は、各ノードでそのディスクがアクセス可能かどうかが確認されます。提示された変更が適切であることがすべてのノードの vxconfigd によって承認されると、それぞれの vxconfigd はそのカーネルに通知し、次にカーネル同士が共同してそのトランザクションをコミットまたはアボートします。トランザクションをコミットする前に、すべてのカーネルで進行中の入出力動作がないことを保証する必要があります。再構成の開始とトランザクションコミットの調整は、マスターノードが行います。

いずれかのノードの vxconfigd が再構成プロセス中に消失すると、すべてのノードにその旨が通知され、操作は失敗します。いずれかのノードがクラスタから切り離されると、マスターがすでに処理をコミットしていた場合を除いて、操作は失敗します。マスターがクラスタから切り離された場合は、(以前はスレーブだった) 新しいマスターが操作を完了するか、操作が失敗するかのどちらかです。これは、新しいマスターが以前のマスターから正常な完了を通知するメッセージを受信したかどうかに依存します。この通知は、新しいマスターが受信しない限り、他のスレーブにも伝達されません。

ボリュームの再構成の実行中にクラスタへの結合を試みるノードがあった場合、その結果は、再構成がどの程度まで進行していたかによって異なります。カーネルがまだ関与していない段階では、ボリューム再構成は一時停止され、結合が完了した時点で再開されます。カーネルが関与していれば、再構成が完了するまで結合は待機させられます。

エラー (スレーブでの検査が失敗した場合や、ノードがクラスタから切り離される場合など) が発生すると、そのエラーはユーティリティに返され、起動ノードのコンソールにエラーメッセージが表示され、エラーが発生したノードが特定されます。

ノードの停止

システム管理者は、特定のノードでクラスタマネージャの停止作業を実行することにより、そのノードでクラスタを停止できます。この結果、クラスタアプリケーションが停止された後でクラスタ構成要素が終了します。CVM では「クリーンノードシャットダウン」がサポートされています。これは、共有ボリュームへのすべてのアクセスを終了した時点で、ノードがクラスタから切り離される機能です。ホストは引き続き動作しますが、ホスト上のクラスタアプリケーションは実行不可能になります。

CVM は各ボリュームに関する全体的な状態情報を管理します。その結果、ノードに障害が発生したとき、CVM はどのボリュームの回復が必要かを正確に判断できます。クリーンシャットダウン以外の不正な手段や障害によってノードがクラスタから切り離された場合、CVM はどのボリュームに未完の書き込みがあるかを判断し、マスターはそれらのボリュームを再同期します。それらのボリュームのいずれかに対してダーティーリージョンログ (DRL) がアクティブな場合は、それが使用されます。

「クリーンノードシャットダウン」は、すべてのクラスタアプリケーションを停止させる作業の後、またはその作業と組み合わせて使用する必要があります。クラスタアプリケーションの特性とその停止方法によっては、停止作業が正常に終了するまでに長い時間 (数分から数時間) を要する場合があります。たとえば、多くのアプリケーションに「ドレイニング」という概念がありますが、これは新しい処理を受け付けず、進行中の処理を完了してから終了するものです。たとえば、実行に長時間を要するトランザクションがアクティブの場合、このプロセスに長い時間がかかることがあります。

CVM 停止作業が呼び出されると、停止対象のノード上のすべての共有ディスクグループ内のすべてのボリュームを検査し、停止作業を続行するかエラーを返します。

ノードのアボート

ノードがクリーンに切り離されなかった場合、その原因は、ホストに障害が発生したか、一部のクラスタ構成要素によって緊急事態としてノードを切り離す決定が行われたかのどちらかです。その後のクラスタ再構成で、CVM アボート機能が呼び出されます。この機能は共有ボリュームへのすべてのアクセスを一度に停止しようとしますが、ディスクに対する入出力が完了するまで待ちます。まだ開始されていなかった入出力動作は失敗し、共有ボリュームは削除されます。したがって共有ボリュームをアクセスしていたアプリケーションは、エラーを返します。

ノードがアボートしたか障害が発生した後は、ミラーが同期していない可能性が非常に高いので、(残されたノードまたは後続のクラスタ再起動によって) ボリュームを回復する必要があります。

クラスタの停止

クラスタ内のすべてのノードが切り離された場合、次のクラスタ起動時に、共有ボリュームを回復すべきかどうかの決定を行う必要があります。すべてのノードが正常に切り離された場合は、回復の必要はありません。最後のノードは正常に切り離され、その前のノードがアボートや障害によって切り離された結果としての再同期が完了している場合には、回復の必要はありません。ただし、最後のノードが正しく切り離されなかった場合や、その前のノードの異常な切り離しにより再同期が完了していない場合には、回復を実行する必要があります。

ディスクと CVM

クラスタ内の一連のノードは、常にディスクの状態について合意している必要があります。特に、1 つのノードが特定のディスクに書き込めない場合、その書き込み操作の結果が呼び出し元に返されるまで、すべてのノードがそのディスクへのアクセスを停止する必要があります。したがって、ノードがディスクに接続できない場合には、そのノードは別のノードと交渉し、ディスクの状態について検査する必要があります。ディスクが故障した場合には、どのノードもそのディスクにはアクセスできないので、ノード間でそのディスクの切り離しに合意して問題ありません。ディスクは故障していないが、一部のノードからのアクセスパスが故障した場合には、ディスクの状態についてノード間で合意できません。このような問題を解決するため、何らかの方針が成立している必要があります。現在の方針では、ディスクが故障していなくても切り離すことになっています。この方針では、状態の問題は解決されますが、ミラー化ディスクについてはミラーが減少する問題が残り、またミラー化以外のボリュームにはデータがアクセスできない問題が残ります。

注 -

この方針は現在の実装オプションです。今後の CVM リリースでは、システム管理者が別の方針を選択できるようになる予定です。たとえば代替の方針として、ディスクをアクセスできなくなったノードはクラスタを切り離すという方式が考えられます。この方針では、一部のノードをクラスタ外に保持しなければなりませんが、データの整合性は維持されます。

ダーティーリージョンログと 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 回復マップ更新の揮発性 (メモリー上で動作する) 追跡を実行し、複数のユーティリティが回復マップを同時に変更する事態を防止します。