test

Sun Cluster 2.2 Cluster Volume Manager ガイド

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 アボート機能が呼び出されます。この機能は共有ボリュームへのすべてのアクセスを一度に停止しようとしますが、ディスクに対する入出力が完了するまで待ちます。まだ開始されていなかった入出力動作は失敗し、共有ボリュームは削除されます。したがって共有ボリュームをアクセスしていたアプリケーションは、エラーを返します。

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

クラスタの停止

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