回復
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 つの障害によってすべてのミラーが使用不可能になることはありません。
回復の最初の手順は、故障したデバイスを再びアクセス可能にすることです。具体的には次の処置を行います。
-
故障したハードウェアの交換 (該当する場合)
-
記憶装置に固有の回復、起動処置の実行 (例: Sun StorEdge A3000 での Recovery Guru 、Sun StorEdge A5000 での luxadm の使用など)
-
Solaris デバイスツリーの更新 (drvconfig/boot -r)
実行する手順の詳細については、記憶装置の管理マニュアルを参照してください。
デバイスがアクセス可能になったことを、ボリュームマネージャに認識させる必要があります。これは、一般に vxdctl enable を実行することによって行います。これによって CVM がデバイスに関する回復処置を実行できる状態になります。デバイスの再接続は、vxreattach、vxdiskadm (オプション 5)、vxva GUI を使用して行います。これらのユーティリティはいずれも、vxdg -k adddisk を使用してディスクを接続します。ディスクを接続したら、次に vxrecover を使用してボリュームを回復する必要があります。回復のために必要な操作は、kstate (カーネル状態) と dm/volume/plex の状態によって異なります。状態値の説明については、『Sun StorEdge Volume Manager2.6 システム管理ガイド』を参照してください。各種の状態からの回復方法を、以下に簡単に説明します。
デバイスが NODEVICE 状態のときは、vxreattach/vxdiskadm/vxva を使用してデバイスを再接続する必要があります。vxreattach はディスク媒体とデバイスアクセス名の判定を試みるので便利ですが、ディスクが交換されている場合には、vxdg/vxdiskadm/vxva を使用して接続する必要があります。vxva/vxdiskadm を使用する場合は、ディスク媒体にどのディスクを使用するかを指定する必要があります。REMOVED 状態のディスクは、vxva/vxdisk を使用して接続する必要があります。
注 -交換用ディスクを初期化していない場合は、まず初期化する必要があります。
ボリュームは起動された時点で kstate が ENABLED になり、停止された時点で (または重大なエラーの結果、使用不可能になったとき) DISABLED になります。kstate が ENABLED でないボリュームが存在する場合は、vxvol/vxrecover/vxva を使用してそれらのボリュームを起動できます。プレックスがいずれも CLEAN または ACTIVE 状態でないときは、ボリュームが起動しない可能性がありますが、この場合は vxmend を使用して、選択したプレックスの状態を CLEAN または ACTIVE に変更することで、ボリュームが起動できるようになります。
ノードがクラスタから異常な状態で切り離された場合、ボリュームが NEEDSYNC 状態になる可能性があります。この場合、クラスタフレームワークによって vxrecover が起動され、必要な同期処理が行われます。ボリュームは同期処理中には SYNC 状態になり、それが完了すると ACTIVE 状態に移行します。回復を実行するプロセスが強制的に終了されると、ボリュームは SYNC から ACTIVE に移行しない可能性があります。その場合は vxvol -f resync を使用してボリュームを回復する必要があります。
ボリュームと関連付けられているが切り離されているプレックスは、kstate が DISABLED になります。このようなプレックスは vxrecover (vxplex att を呼び出す) を使用して回復できます。次の手順を実行することで、ほとんどの一般的な障害から回復できます。
-
障害条件 (ハードウェア、ソフトウェア) を修正し、デバイスが再びアクセス可能になったことを確認します。
-
クラスタのすべてのノードで vxdctl enable を実行します。
-
マスターノードで vxreattach を実行します。
-
非共有ディスクグループを持つ他のノードで vxreattach を実行します。
-
vxprint を実行してデバイスが再接続されたことを検証します 。ある種の状況では、切り離されたディスクや交換されたディスクが vxreattach によって再接続できない場合があります。このようなディスクは vxdg/vxdiskadm/vxva を使用して手動で再接続する必要があります。
-
マスターノードで vxrecover -sb を実行します。
-
非共有ディスクグループを持つ他のノードで 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 になります。
- © 2010, Oracle Corporation and/or its affiliates