test

Sun Cluster 2.2 Cluster Volume Manager ガイド

Cluster Volume Manager

この章では、Cluster Volume Manager (CVM) の概要、ユーティリティとデーモン、エラーメッセージ、障害追跡、CVM 関連の用語について説明します。

この章の内容は次のとおりです。

このマニュアルでは、システム管理者が Sun StorEdge Volume Manager (SSVM) に関する一般的な知識を持っていると仮定しています。詳細については SSVM マニュアルセットを参照してください。

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

Cluster Volume Manager ユーティリティとデーモン

CVM を使用するために、次のユーティリティやデーモンが作成または変更されています。

vxclust コマンド

注 -

vxclust は移植性のあるユーティリティではありません。vxclust は SSVM と同じか類似した機能を実行しますが、特定のクラスタマネージャを使用するための修正または書き直しが必要です。

vxclust は、ボリュームマネージャクラスタ再構成ユーティリティです。クラスタのメンバーの変更を調整し、クラスタマネージャと CVM との間の通信を提供します。クラスタの再構成が発生すると、クラスタマネージャによって vxclust が呼び出されます。vxclust はボリュームマネージャカーネルと vxconfigd デーモンに、クラスタの再構成が発生したことを通知します。

クラスタの再構成が発生するたびに、クラスタに現在結合中のすべてのノードが vxclust ユーティリティの一連の手順を実行します。クラスタマネージャの機能により、すべてのノードで同じ手順が同時に実行されることが保証されます。1 つの手順がすべてのノードで完了してから、次の手順が開始されます。再構成の各手順で、vxclust は CVM が次に何をすべきかを判定します。vxclust は、CVM に次の動作を指示した後、その結果 (成功、失敗、再試行) を待ち、それをクラスタマネージャに通知します。

ノードが特定のタイムアウト期間内に vxclust の要求に応答しない場合、そのノードはアボートします。次に vxclust は状況に応じて、再構成を再開するか、放棄するかを決定します。再構成の原因がローカルな、訂正不可能なエラーの場合には、vxclust は動作を停止します。他のノードが切り離されたためにノードが処理を完了できなかった場合には、残ったノードはタイムアウトします。この場合、vxclust は他のノードが切り離されることを予測して再構成を要求します。切り離されるノードがなかった場合は、vxclust はローカルノードから切り離されます。

再構成手順が失敗すると、vxclust はクラスタマネージャにエラーを返します。クラスタマネージャはノードをアボートし、クラスタから即時に切り離されるよう決定することができます。共有ディスクに対して進行中の入出力は失敗し、共有ディスクへのアクセスは停止されます。

vxclust は、クラスタの変更を通知されたときに実行すべき動作を決定します。(以前のマスターが故障したために) 新しいマスターノードが必要になった場合は、vxclust はどのノードが新しいマスターになるかを決定します。

vxconfigd コマンド

ボリュームマネージャ構成デーモン vxconfigd は、ボリュームマネージャオブジェクトの構成を管理します。vxconfigd は、vxclust ユーティリティからクラスタ関連の命令を受信します。ノードごとに vxconfigd の個別のコピーが存在し、これらのコピーがネットワーク機能を通じて相互に通信します。ボリュームマネージャユーティリティは、クラスタ内のノードごとに動作中の vxconfigd と通信します。ボリュームマネージャユーティリティは、それ以外のノード上の vxconfigd デーモンとの接続は試みません。クラスタの起動時には、vxclust は vxconfigd にクラスタ動作の開始を指示し、そのノードがマスターとスレーブのどちらかを通知します。

ノードがクラスタ動作のため初期化されると、vxclust はカーネルと vxconfigd に対し、そのノードがクラスタに結合しつつあることを通知し、vxconfigd に (クラスタマネージャ構成データベースから) 次の情報を提供します。

vxconfigd による回復

ボリュームマネージャの vxconfigd デーモンは、任意の時点で停止および再開できます。vxconfigd の停止中はボリュームの再構成は行えず、vxconfigd が再開するまで他のノードはクラスタに結合できません。クラスタでは、スレーブ上の vxconfigd デーモンは常にマスター上の vxconfigd デーモンに接続されています。したがって、クラスタ編成されたノードで vxconfigd デーモンを停止することは推奨できません。

vxconfigd が何らかの理由で停止された場合、どのノードでデーモンが停止されたかに応じて、以下のように異なる動作が実行されます。

vxdg コマンド

vxdg ユーティリティは、ボリュームマネージャディスクグループを管理します。vxdg を使用することにより、ディスクグループをクラスタ共有可能なものとして指定できます。vxdg に -s オプションを指定すると、ディスクグループを「共有済み」として初期化またはインポートすることができます。

クラスタを設定するためにクラスタソフトウェアを実行中のときは、次のコマンドを使用して共有ディスクグループを作成します。


vxdg -s init diskgroup [medianame=]accessname

ここで diskgroup はディスクグループ名です。medianame はディスクに対して選択した管理名です。accessname はディスクアクセス名 (またはデバイス名) です。

ディスクグループを共有済みとしてインポートするには、vxdg -s import を使用します。クラスタソフトウェアを実行する前にディスクグループが設定されていた場合は、次のコマンドを使用して、そのディスクグループをクラスタ構成にインポートできます。


vxdg -s import diskgroup

ここで diskgroup はディスクグループ名または ID です。後でクラスタを再起動するときに、このディスクグループは自動的に共有済みとしてインポートされます。このコマンドを呼び出す前に、(vxdg deport diskgroup を使用して) ディスクグループのデポートが必要な場合があります。

ディスクグループを共有から個人用に切り替えるには、vxdg deport を使用してディスクグループをデポートし、次に vxdg import diskgroup を使用してインポートします。

注 -

システムはディスクが共有されるかどうかを判断できません。複数のシステムがアクセスする可能性のあるディスクを取り扱う際にデータの整合性を守るには、システム管理者がディスクグループにディスクを追加するとき、正しい指定を行うよう注意する必要があります。物理的に共有されていないディスクを共有ディスクグループに追加しようとした場合、クラスタ内にノードが 1 つしかなく、そのノードでそのディスクがアクセス可能であれば、ボリュームマネージャはこの操作を許容してしまいます。しかし、他のノードはクラスタに結合できなくなります。さらに、同じディスクを 2 つのノードで同時に別のディスクグループに追加しようとすると、予測不可能な結果が生じます。このような理由から、1 つのノードだけですべての構成を取り扱う必要があります。

vxdg には、ディスクグループを強制的にインポートする、またはディスクグループにディスクを強制的に追加するための強制オプション (-f) があります。

注 -

強制オプション (-f) は、予測される結果をシステム管理者が完全に理解したうえで、注意して使用する必要があります。

クラスタを再起動した時点で、CVM は次のいずれかの理由でディスクグループの自動インポートを拒絶する場合があります。

vxdg を使用して、共有ディスクグループを一覧表示することもできます。次のコマンドを実行すると、ディスクグループごとに 1 行ずつ情報が表示されます。


vxdg list

このコマンドによる出力は次のようになります。


NAME         STATE             ID
rootdg       enabled           774215886.1025.teal
group2       enabled,shared    774575420.1170.teal
group1       enabled,shared    774222028.1090.teal

共有ディスクグループには、フラグ shared が付きます。

次のコマンドを実行すると、共有ディスクグループごとに 1 行ずつ情報が表示されます。


vxdg -s list

このコマンドによる出力は次のようになります。


NAME         STATE            ID
group2       enabled,shared   774575420.1170.teal
group1       enabled,shared   774222028.1090.teal

次のコマンドを実行すると、特定のディスクグループに関する情報 (共有済みかどうかも含めて) が表示されます。


vxdg list diskgroup

ここで diskgroup はディスクグループ名です。

ディスクグループ group1 のマスターで vxdg list group1 コマンドを実行すると、出力は次のようになります。


Group:     group1
dgid:      774222028.1090.teal
import-id: 32768.1749
flags:     shared
copies:    nconfig=default nlog=default
config:    seqno=0.1976 permlen=1456 free=1448 templen=6 loglen=220
config disk c1t0d0s2 copy 1 len=1456 state=clean online
config disk c1t1d0s2 copy 1 len=1456 state=clean online
log disk c1t0d0s2 copy 1 len=220
log disk c1t1d0s2 copy 1 len=220

「flags:」フィールドが「shared」に設定されている点に注意してください。同じコマンドをスレーブで実行すると、出力は異なります。

vxdisk コマンド

vxdisk ユーティリティは、ボリュームマネージャディスクを管理します。次のように vxdisk を使用して、ディスクがクラスタ共有可能ディスクグループに属するかどうかを調べることができます。 


vxdisk list accessname

ここで accessname はディスクアクセス名 (またはデバイス名) です。

このコマンドのデバイス c1t0d0s2 に関する出力は、次のようになります。


Device:    c1t0d0s2
devicetag: c1t0d0
type:      sliced
clusterid:    cvm
disk:      name=disk01 id=774215890.1035.teal
group:     name=group1 id=774222028.1090.teal
flags:     online ready private autoconfig shared imported
pubpaths:  block=/dev/dsk/c1t0d0s4 char=/dev/rdsk/c1t0d0s4
privpaths: block=/dev/dsk/c1t0d0s3 char=/dev/rdsk/c1t0d0s3
version:   2.1
iosize:    min=512 (bytes) max=248 (blocks)
public:    slice=4 offset=0 len=2050272
private:   slice=3 offset=1 len=2015
update:    time=778564769 seqno=0.1614
headers:   0 248
configs:   count=1 len=1456
logs:      count=1 len=220
Defined regions:
 config   priv 000017-000247[000231]: copy=01 offset=000000 enabled
 config   priv 000249-001473[001225]: copy=01 offset=000231 enabled
 log      priv 001474-001693[000220]: copy=01 offset=000000 enabled

「clusterid:」フィールドが「cvm」(クラスタ名) に設定され、「flags:」フィールドに「shared」というエントリが表示される点に注意してください。ノードがクラスタに結合していないときは、「flags:」フィールドには「imported」の代わりに「autoimport」フラグが表示されます。

vxrecover コマンド

vxrecover ユーティリティは、ディスク交換後にプレックスとボリュームを回復します。

ノードがクラスタから切り離されるとき、一部のミラーが不整合な状態のまま残される場合があります。vxrecover ユーティリティは、この状態のすべてのボリュームに対して回復を実行します。-c オプションを指定すると、クラスタ共有可能ディスクグループのすべてのボリュームの回復が行われます。vxclust は必要に応じて vxrecover -c を自動的に呼び出します。

注 -

vxrecover の実行中は、システム性能が低下する場合があります。

vxdctl コマンド

vxdctl ユーティリティは、ボリューム構成デーモン vxconfigd の一部の機能を管理します。-c オプションを使用して、クラスタ情報を表示できます。vxdctl を次のように使用して、vxconfigd が使用可能かどうか、および動作中かどうかを判定できます。 


vxdctl -c mode

このコマンドの出力は、状況に応じて次のようになります。


mode: enabled: cluster active - MASTER

mode: enabled: cluster active - SLAVE

mode: enabled: cluster inactive

mode: enabled: cluster active - role not set
注 -

vxconfigd が使用不可のときは、クラスタ情報は表示されません。

vxstat コマンド

vxstat は、特定のオブジェクトに関する統計情報を返します。CVM 環境では、vxstat はクラスタ内のすべてのノードから統計情報を収集します。この統計情報では、すべてのノードによる指定したオブジェクトの総合的な使用状況が示されます。ローカルオブジェクトを指定した場合は、ローカルでの使用状況が返されます。

vxstat では、呼び出し元がノードのサブセットを任意に指定できます。


vxstat -g diskgroup -n node[,node...]

ここで node は整数です。コンマで区切ったノードのリストを指定すると、そのリストのノード群に関する統計の和が表示されます。

次の例は、ノード 2、ボリューム vol1 に関する統計情報を取得します。


vxstat -g rootdg -n 2 vol1

この場合、次のような出力が生成されます。


OPERATIONS           BLOCKS         AVG TIME(ms)
TYP  NAME          READ     WRITE      READ     WRITE    READ  WRITE
vol  vol1          2421         0    600000         0    99.0    0.0

vxstat を次のように使用して、クラスタ全体に関する統計情報を取得し表示することもできます。


vxstat -b

すべてのノードに関する統計が加算されます。たとえば、ノード 1 が 100 回、ノード 2 が 200 回の入出力をそれぞれ行なった場合には、vxstat -b は 300 を返します。

エラーメッセージ

この節では、CVM で表示される可能性のあるエラーメッセージについて説明します。各メッセージの説明と、推奨される対処方法を示します。

注 -

これらのメッセージには、コンソールに表示されるものもありますが、vxclust によって返されるものもあります。 


error in cluster processing

クラスタの現在の状態に適さない操作 (スレーブから共有ディスクグループをインポートまたはデポートしようとした場合など) が原因と考えられます。また、vxclust からの予期されないコマンドシーケンスが原因の場合もあります。

現在の環境で操作が実行可能かどうかを確認してください。


cannot find disk on slave node

スレーブノードが共有ディスクを検出できません。このメッセージと共に次の syslog メッセージが表示されます。


vxvm:vxconfigd cannot find disk disk

両方のノードで同じ共有ディスクの集合がオンラインであることを確認してください。

マスターとスレーブの両方でコマンド vxdisk list を使用してディスクを検証し、「shared」フラグ付きのディスクの同じ集合が両方のノードで見えることを確認してください。そうでない場合には、ディスクへの接続を検査してください。


disk in use by another cluster

他のクラスタの ID を持つディスクを含むディスクグループをインポートしようとしました。

ディスクグループが他のクラスタによってインポートされていない場合は、-C (クリアインポート) フラグを使用してインポートを再試行してください。


vxclust not there

クラスタへの結合を試みている間にエラーが発生し、vxclust が失敗しました。結合中に他のノードで故障が発生したか、vxclust の障害が原因と考えられます。

結合を再試行してください。他のノードで表示されるエラーメッセージで問題点が判明する可能性があります。


unable to add portal for cluster

vxconfigd が他のノード上の vxconfigd との通信を確立できませんでした。このエラーは、システム資源 (メモリーやファイル記述子など) が不足しつつあるシステムで発生する可能性があります。

システムの資源が不足している兆候がなければ、vxconfigd を停止してから再起動し、操作を再試行してください。


vol recovery in progress

障害が発生したノードが、クラスタに再結合を試みましたが、その DRL マップがまだ回復マップにマージされていません。

マージ処理が完了してから再結合をやり直してください。


cannot assign minor #

スレーブが結合を試みましたが、そのスレーブ上の既存のボリュームが、マスター上の共有ボリュームと同じマイナー番号を持っています。

このメッセージとともに、次のコンソールメッセージが表示されます。


WARNING vxvm:vxconfigd minor number ### diskgroup group in use

結合を再試行する前に、vxdg reminor diskgroup ### (vxdg(1M) のマニュアルページを参照) を使用して、マスター上のディスクグループまたはスレーブ上の重複するディスクグループに、新しいマイナー番号の範囲を選択してください。ディスクグループ内にオープンボリュームがある場合は、そのディスクグループがデポートされ明示的に更新されるか、またはシステム再起動によって更新されて初めて、reminor の結果が有効になります。


master sent no data

スレーブ結合プロトコルの実行中に、データを伴わないメッセージが受信されました。このメッセージが表示されるのは、プログラミングエラーの場合だけと考えられます。

ご購入先にお問い合わせください。


join in progress

クラスタの再構成中に共有ディスクグループをインポートまたはデポートしようとしました。

後で再試行してください。


join not allowed now

マスターの準備が整っていないとき、スレーブがクラスタに結合しようとしました。スレーブは自動的に再試行します。再試行が成功すれば、次のメッセージが表示されます。


vxclust: slave join complete

最終的に結合が完了すれば、何もする必要はありません。それ以外の場合は、マスター上でクラスタモニターを調べてください。


Disk reserved by other host

他のホストによってコントローラが予約されているディスクをオンライン状態にしようとした場合に、このエラーが発生します。

何もする必要はありません。ノードがクラスタに結合すると、クラスタマネージャはディスクを解放し、ボリュームマネージャはディスクをオンライン状態にします。


vxvm:vxconfigd: group group exists

スレーブがクラスタに結合しようとしましたが、そのスレーブの個人用ディスクグループと同じ名前の共有ディスクグループが、クラスタ内にすでに存在しています。

vxdg newname を使用して、マスター上の共有ディスクグループまたはスレーブ上の個人用ディスクグループの名前を変更してください。


WARNING: vxvm:vxio: Plex plex detached from volume volume
NOTICE: vol_kmsg_send_wait_callback: got error 22
NOTICE: commit: NOTE: Reason found for abort: code=6

これらのメッセージは、スレーブ上でプレックスの切り離し操作が行われるときに表示される場合があります。

これらのメッセージは情報を提供するものであり、ユーザーによる措置は必要ありません。


WARNING: vxvm:vxio: read error on Plex plex of shared volume volume 
offset 10 ¥ length 1
WARNING: vxvm:vxio: Plex plex detached from volume volume 
NOTICE: commit: NOTE: Reason found for abort: code=2
NOTICE: ktcvm_check: sent to slave node: node=1 mid=196

これらのメッセージは、マスター上でプレックスの切り離し操作が行われるときに表示される場合があります。

これらのメッセージは情報を提供するものであり、ユーザーによる措置は必要ありません。

回復

CVM で必要とされる基本的な回復処置は、同じ状況のとき SSVM で必要とされる回復処置と非常に類似しています。ただし CVM をクラスタモードで実行中のときは、別の手順が必要であり、ある種の制約が適用されます。最も顕著な違いは、共有ディスクグループの回復をマスターノードから行わなければならない点です。

ボリュームマネージャオブジェクトの状態は、いくつかの方法で監視できます。最もよく使われるのは、vxprint コマンド、VxVa (GUI)、vxnotify コマンドを使用する方法です。ほとんどのエラー条件では、コンソールメッセージが生成されるか、メッセージファイルにメッセージが送信されます。ある種のイベント (たとえば、クラスタノードの故障など) の場合は、Sun Cluster フレームワークを通じて CVM が自動的に回復しますが、システム管理者による介入を必要とするイベントもあります。回復を実行するには、vxva、vxdiskadm、vxreattach、vxrecover、vxvol ユーティリティのうち 1 つ以上を使用します。これらのユーティリティには、vxdg、vxdisk、vxplex などの他のユーティリティを内部的に呼び出すものがあります。特定の状況から回復するために何が必要かを理解するためには、ボリュームマネージャユーティリティに関する十分な知識が必要です。ボリュームの回復やディスクの交換手順についての詳細は、『Sun StorEdge Volume Manager 2.6 ユーザーマニュアル』および『Sun StorEdge Volume Manager 2.6 システム管理ガイド』を参照してください。

次の各節では、発生頻度の高いいくつかの状況から回復するプロセスを説明します。

ディスク、コントローラ、記憶装置の故障

ディスク、コントローラ、または他の記憶装置の故障によって、ノードがデバイスにアクセスできなくなる場合があります。故障発生時にデバイスがアクセス中だった場合は、そのデバイスはディスクグループから切り離されます。ミラー化デバイスのデータ配置上、1 つの障害によってすべてのミラーが使用不可能になることはありません。

回復の最初の手順は、故障したデバイスを再びアクセス可能にすることです。具体的には次の処置を行います。

  1. 障害条件 (ハードウェア、ソフトウェア) を修正し、デバイスが再びアクセス可能になったことを確認します。

  2. クラスタのすべてのノードで vxdctl enable を実行します。

  3. マスターノードで vxreattach を実行します。

  4. 非共有ディスクグループを持つ他のノードで vxreattach を実行します。

  5. vxprint を実行してデバイスが再接続されたことを検証します 。ある種の状況では、切り離されたディスクや交換されたディスクが vxreattach によって再接続できない場合があります。このようなディスクは vxdg/vxdiskadm/vxva を使用して手動で再接続する必要があります。

  6. マスターノードで vxrecover -sb を実行します。

  7. 非共有ディスクグループを持つ他のノードで vxrecover -g <dg> -sb を実行します。

回復の例

次に、いくつかの典型的な回復の例を示します。回復プロセスでは、最初にクラスタノードの動作モードを検査します。回復プロセスはマスターノードで実行する必要があります (非共有ディスクグループについては、そのディスクグループをインポートしたノードで実行する必要があります)。


Root@capri:/# vxdctl -c mode
mode: enabled: cluster active - SLAVE
Root@palermo:/# vxdctl -c mode
mode: enabled: cluster active - MASTER

両方のノードで使用可能なディスクグループを検査するため、vxdg list を使用します。


Root@capri:/# vxdg list
NAME   STATE          ID
rootdg enabled        885258939.1025.capri
test   enabled,shared 885331519.1233.palermo
Root@palermo:/# vxdg list
NAME   STATE          ID
rootdg enabled        885258917.1025.palermo
test   enabled,shared 885331519.1233.palermo

この場合、非共有ディスクグループ (rootdg) が 1 つ、共有ディスクグループ (test) が 1 つあります。rootdg は、2 つのホスト上で名前は同じでも、ディスクグループ ID が異なっています。ボリュームマネージャオブジェクトの状態に注意してください。各オブジェクトの KSTATE および STATE から、オブジェクトの状態を確認し、回復が保証されているかどうかを判定できます。


vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -

dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -

v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -

v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

デバイス c4t0d6s2 またはコントローラ c4 の制御下のすべてのデバイスが使用不可能になった場合、そのデバイスはディスクグループから切り離されます。障害発生後の vxprint の出力例を以下に示します。


vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -

dm disk1        -            -        -        -        NODEVICE -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -

v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        DISABLED 132867   -        NODEVICE -       -
sd c4t0d6s2-01  test1-01     DISABLED 132867   0        NODEVICE -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -

v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        DISABLED 132867   -        NODEVICE -       -
sd c4t0d6s2-02  test2-01     DISABLED 132867   0        NODEVICE -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

dm エントリ disk1、およびこのディスクを使用するサブディスクとプレックスの状態が NODEVICE になっている点に注目してください。この場合、デバイスが再びアクセス可能になったら再接続する必要があります。ディスクの状態は、vxdisk list の出力で示されます。デバイスの状態が変化した場合は、vxdctl enable を実行してから vxdisk list を実行する必要があります。


vxdctl enable vxdisk list | grep c[45]t0d6s2
c4t0d6s2     sliced    -            -            error  shared
c5t0d6s2     sliced    disk2        test         online shared
-            -         disk1        test        failed was:c4t0d6s2

c5t0d6s2 は online 状態であるのに対し、c4t0d6s2 は error 状態である点に注目してください。デバイスをアクセスできるノードとアクセスできないノードがあった場合、vxdisk list による出力はノードごとに異なったものになります (デバイスをアクセスできるノードでは、そのデバイスは online と表示されます)。以上で障害条件を訂正する準備が整いました (この場合、palermo が SSA の 1 つへの接続を失い、後に接続は復元されています)。この時点では、デバイスを再接続するため vxreattach を実行すれば十分です。

次に vxdctl enable を実行し、デバイスがアクセス可能になったこと (デバイスの状態が online) を検証します。次の例は vxdisk および vxdg コマンドの使用法を示しています。


vxdctl enable
vxdisk -a online
vxdisk list | grep c[45]t0d6s2
c4t0d6s2     sliced    -            -            error  shared
c5t0d6s2     sliced    disk2        test         online shared
-            -         disk1        test         failed was:c4t0d6s2

上記の出力から、どのディスクグループとも関連付けられなくなった c4t0d6s2 が、ディスクグループ test に DM disk1 として関連付けられていたことが分かります。disk1 が依然として関連付けを解除されており、c4t0d6s2 が正しいディスクである (つまり、スワップされていない) ことを確認した後、コマンド vxdg -g test -k adddisk disk1=c4t0d6s2 を使用して再接続できます。


vxprint -d -g test -F "%name %nodarec %diskid"
disk1 on 882484157.1163.palermo
disk2 off 884294145.1517.palermo

上記の出力は、DM 名とディスク ID の関連付けを示しています。disk1 の nodarec 属性は有効なので、これは依然として関連付けを解除されています。以前は、ディスク 882484157.1163.palermo がこれと関連付けられていました。ディスクを物理的に交換するか移動していない限り、このディスク ID は c4t0d6s2 に対応しています。新しい初期化済みディスクに交換した場合には、対応するディスク ID は発見できません。ディスク ID を検証するために、コマンド vxdisk -s list を実行します。


vxdisk -s list c4t0d6s2 c5t0d6s2
Disk:   c4t0d6s2
type:   sliced
flags:  online ready private autoconfig shared autoimport
diskid: 882484157.1163.palermo
dgname: test
dgid:   885331519.1233.palermo
clusterid: italia
Disk:   c5t0d6s2
type:   sliced
flags:  online ready private autoconfig shared autoimport imported
diskid: 884294145.1517.palermo
dgname: test
dgid:   885331519.1233.palermo
clusterid: italia

上記の出力は、ディスク c4t0d6s2 の ID が 882484157.1163.palermo であることを示しています。このように関連付けを検証する作業は、やや煩雑ですが、vxreattach (-c オプション) を使用すれば、ディスクを再接続すべきディスクグループと DM を表示できます。


vxreattach -c  c4t0d6s2
test disk1

以上で、コマンド vxdg -g test -k adddisk disk1=c4t0d6s2 を使用してディスクを関連付ける準備が整いました。ほとんどの状況では、vxreattach の実行によって、ここまでのすべての手順 (vxdctl enable の実行と、デバイスと対応するディスクグループとの再接続) が処理されます。しかし、管理上の理由で vxdiskadm コマンドを使用してディスクを除去していた場合や、物理的に交換していた場合には、vxdg コマンド (オプション 5) または VxVM GUI を使用して交換する必要があります。


vxreattach -bv
! vxdg -g 885331519.1233.palermo -k adddisk disk1=c4t0d6s2

vxprint コマンドを使用して、DM とプレックスの状態の変更を検証できます。


vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -

dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -

v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        DISABLED 132867   -        IOFAIL   -       -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -

v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        DISABLED 132867   -        RECOVER  -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

この時点で vxreattach の -rb オプションを指定して vxrecover を起動することにより、ボリュームとプレックスを回復できます。


vxrecover -g test -vb
job 026404 dg test volume test1: reattach plex test1-01
ps -ef | grep plex
    root 26404 26403  1 13:58:04 ?        0:01 /usr/lib/vxvm/type/fsgen/vxplex -U fsgen -g 885331519.1233.palermo -- att test1
    root 26406   916  0 13:58:10 console  0:00 grep plex

バックグラウンドで実行される vxrecover は、vxplex を起動してプレックスをボリュームに接続します (STALE 状態と TUTIL0 の ATT に注意)。


vxprint -g test               
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -
dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -
v  test1        fsgen        ENABLED  131072   -        ACTIVE   ATT1    -
pl test1-01     test1        ENABLED  132867   -        STALE    ATT     -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -
v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        DISABLED 132867   -        RECOVER  -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -
Root@palermo:/ # job 026404 done status=0
job 026408 dg test volume test2: reattach plex test2-01
job 026408 done status=0

ボリュームの回復後、デバイスの状態をもう一度検査します (KSTATE は ENABLED、STATE は ACTIVE でなければなりません)。


vxprint -g test               
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -
dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -
v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -
v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

以上で回復が完了しました。マスターノードではなくスレーブノードで障害が発生した場合、状況は若干異なったものになります。障害発生後、vxprint の出力は次のようになります。


vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -

dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -

v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        DETACHED 132867   -        IOFAIL   -       -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -

v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

デバイスは切り離されていないので、スレーブがディスクを再びアクセスできるようになった後、マスターで vxrecover を実行するだけで十分です。ただし、管理上の理由でディスクを除去していた場合には、vxdg/vxdiskadm/vxva を使用してそのディスクを追加し (vxreattach は使用できません)、次に vxrecover を使用してディスクを回復する必要があります。


vxdg -k rmdisk disk1
vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -
dm disk1        -            -        -        -        REMOVED  -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -
v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        DISABLED 132867   -        REMOVED  -       -
sd c4t0d6s2-01  test1-01     DISABLED 132867   0        REMOVED  -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -
v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        DISABLED 132867   -        REMOVED  -       -
sd c4t0d6s2-02  test2-01     DISABLED 132867   0        REMOVED  -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

vxreattach は、再接続できるディスクがあればそれを報告します。ただし、次のようにしてディスクを手動で再接続できます。


vxdg -g test -k adddisk disk1=c4t0d6s2
vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -

dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -

v  test1        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test1-01     test1        DISABLED 132867   -        RECOVER  -       -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -
v  test2        fsgen        ENABLED  131072   -        ACTIVE   -       -
pl test2-01     test2        DISABLED 132867   -        RECOVER  -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -
vxrecover -v -g test
job 026416 dg test volume test1: reattach plex test1-01
waiting...
job 026416 done status=0
job 026417 dg test volume test2: reattach plex test2-01
waiting...
job 026417 done status=0

次の例は、再接続と回復の方法を示しています。


ps -ef | grep vx
    root 21935     1  1 20:10:31 ?        5:36 vxconfigd
    root 29295     1  0 14:29:11 ?        0:00 /usr/sbin/vxrecover -c -v -s
    root 29349     1  0 14:29:13 ?        0:00 /usr/sbin/vxrecover -c -v -s
    root 29399 29295  0 14:29:14 ?        0:00 /usr/lib/vxvm/type/fsgen/vxvol -U fsgen -g 885331519.1233.palermo -- resync tes
    root 29507 29399  0 14:29:16 ?        0:00 /usr/lib/vxvm/type/fsgen/vxvol -U fsgen -g 885331519.1233.palermo -- resync tes
    root 29508 29349  0 14:29:17 ?        0:00 /usr/lib/vxvm/type/fsgen/vxvol -U fsgen -g 885331519.1233.palermo -- resync tes
    root 29509 29508  0 14:29:17 ?        0:00 /usr/lib/vxvm/type/fsgen/vxvol -U fsgen -g 885331519.1233.palermo -- resync tes
    root 29511   916  0 14:29:21 console  0:00 grep vx
vxprint -g test
TY NAME         ASSOC        KSTATE   LENGTH   PLOFFS   STATE    TUTIL0  PUTIL0
dg test         test         -        -        -        -        -       -
dm disk1        c4t0d6s2     -        8379057  -        -        -       -
dm disk2        c5t0d6s2     -        8379057  -        -        -       -

v  test1        fsgen        ENABLED  131072   -        SYNC     -       -
pl test1-01     test1        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-01  test1-01     ENABLED  132867   0        -        -       -
pl test1-02     test1        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-01  test1-02     ENABLED  132867   0        -        -       -

v  test2        fsgen        ENABLED  131072   -        SYNC     -       -
pl test2-01     test2        ENABLED  132867   -        ACTIVE   -       -
sd c4t0d6s2-02  test2-01     ENABLED  132867   0        -        -       -
pl test2-02     test2        ENABLED  132867   -        ACTIVE   -       -
sd c5t0d6s2-02  test2-02     ENABLED  132867   0        -        -       -

この時点でボリュームの状態は SYNC になっている点に注意してください。vxplex の完了後は、ボリュームの状態は ACTIVE になります。