この章では、Solaris ボリュームマネージャに関連する問題の解決方法について説明します。 また、この章では、障害追跡の一般的な指針と、いくつかの特定の問題を解決するための具体的な手順も示します。
この章では、次の内容について説明します。
この章は、Solaris ボリュームマネージャの問題とその解決方法について説明し、 一般的なシナリオと回復手順を示すことを目的としています。ここでは、包括的な情報は提供されません。
次の表に、Solaris ボリュームマネージャの障害追跡に必要な作業を示します。
作業 |
説明 |
参照先 |
---|---|---|
不良ディスクを交換する |
ディスクを交換してから、新しいディスク上の状態データベースの複製と論理ボリュームを更新します。 | |
ディスク移動の問題から回復する |
ディスクを元の場所に戻すか、製品サポートに連絡します。 | |
/etc/vfstab 内の不適切なエントリを修正する |
ミラーに対して fsck コマンドを実行してから、システムが正しく起動するように /etc/vfstab ファイルを編集します。 | |
起動デバイスの障害から回復する |
ほかのサブミラーから起動します。 | |
状態データベースの複製数の不足から回復する |
metadb コマンドを使って、使用不能な複製を削除します。 | |
ソフトパーティションの失われた構成データを復元する |
metarecover コマンドを使って、ソフトパーティションの構成データを復元します。 | |
別のディスクから Solaris ボリュームマネージャ構成を復元する |
新しいシステムにディスクを追加し、既存の状態データベースの複製から Solaris ボリュームマネージャ構成を再構築します。 | |
別のシステムから記憶領域を回復する |
既知のディスクセットから別のシステムへ記憶領域をインポートします。 | |
アクセスできないディスクセットをパージする |
metaset コマンドを使用して、取得または使用できないディスクセットのレコードをパージします。 |
Solaris ボリュームマネージャの記憶領域管理に関連する問題を解決するには、次の条件を満たしている必要があります。
ルート権限を持っている
すべてのデータの最新バックアップを取っている
Solaris ボリュームマネージャで障害追跡を行うときは、次の情報を用意してください。
metadb コマンドの出力
metastat コマンドの出力
metastat -p コマンドの出力
/etc/vfstab ファイルのバックアップコピー
/etc/lvm/mddb.cf ファイルのバックアップコピー
prtvtoc コマンド (SPARC® システム) または fdisk コマンド (x86 ベースのシステム) の出力 (ディスクパーティションの情報)
Solaris のバージョン
インストールされている Solaris のパッチ
インストールされている Solaris ボリュームマネージャのパッチ
Solaris ボリュームマネージャ構成を更新したり、記憶領域やオペレーティングシステムに関連するその他の変更をシステムに適用した場合は、その構成情報の最新コピーを生成してください。 cron ジョブを使えば、この情報を自動的に生成できます。
Solaris ボリュームマネージャに関連するすべての問題の検証を可能にする手順はありませんが、一般には次の手順に従って障害を追跡します。
現在の構成に関する情報を収集します。
metastat や metadb コマンドの出力など、最新の状態情報を調べます。 これらの出力から、どのコンポーネントで障害が発生したかを示す情報が得られます。
障害が起こりそうなハードウェア部分をチェックします (すべてのハードウェアが適切に接続されているか、 最近、停電がなかったか、 最近、機器を追加または変更しなかったか、など)。
この節では、Solaris ボリュームマネージャ環境でディスクを交換する方法について説明します。
不良ディスク上または不良ディスク上に構築したボリューム上でソフトパーティションを使用していた場合は、新しいディスクを交換対象ディスクと同じ物理位置に配置し、同じc*t*d* 番号を使用する必要があります。
/var/adm/messages ファイルと metastat コマンドの出力を調べて、交換する不良ディスクを特定します。
不良ディスクに状態データベースの複製がないかチェックします。
metadb コマンドを使って複製を表示します。
metadb コマンドの出力を見ると、不良ディスクの状態データベースの複製にエラーが表示されていることがわかります。 この例では、c0t1d0 のデバイスに問題があります。
# metadb flags first blk block count a m u 16 1034 /dev/dsk/c0t0d0s4 a u 1050 1034 /dev/dsk/c0t0d0s4 a u 2084 1034 /dev/dsk/c0t0d0s4 W pc luo 16 1034 /dev/dsk/c0t1d0s4 W pc luo 1050 1034 /dev/dsk/c0t1d0s4 W pc luo 2084 1034 /dev/dsk/c0t1d0s4 |
この出力には、ローカルディスク c0t0d0 と c0t1d0 のスライス 4 にそれぞれ 3 つの状態データベースの複製があることがわかります。 c0t1d0s4 スライスのフラグフィールドの W は、このデバイスに書き込みエラーがあることを示しています。 c0t0d0s4 スライスの 3 つの複製は正常です。
状態データベースの複製があるスライス名とその複製の数を書き留めておき、状態データベースの複製を削除します。
状態データベースの複製の数は、 metadb コマンド出力に同じスライス名が表示される行数と同じです。 この例では、c0t1d0s4 にある 3 つの状態データベースの複製を削除します。
# metadb -d c0t1d0s4 |
不良の状態データベースの複製を削除すると、複製の数が 3 以下になることがあります。その場合は、状態データベースの複製を追加してから先に進みます。 これによって、前と同じ構成情報が保たれます。
不良ディスクにホットスペアがないか探して、あれば削除します。 ホットスペアの検索には、 metastat コマンドを使用します。 この例では、c0t1d0s6 がホットスペア集合 hsp000 に含まれていたので、集合から削除します。
# metahs -d hsp000 c0t1d0s6 hsp000: Hotspare is deleted |
不良ディスクを物理的に交換します。
devfsadm コマンド、cfgadm コマンド、 luxadm コマンド、または使用ハードウェアと環境に適したほかのコマンドを使用して、不良ディスクを論理的に交換します。
metadevadm -u cntndn コマンドを使用して、Solaris ボリュームマネージャの状態データベースを新しいディスクのデバイス ID で更新します。
この例では、新しいディスクは c0t1d0 です。
# metadevadm -u c0t1d0 |
新しいディスクのパーティションを再分割します。
format か fmthard コマンドを使い、不良ディスクと同じスライス情報に基づいてディスクをパーティション分割します。 不良ディスクに対する prtvtoc の出力がある場合は、fmthard -s /tmp/failed-disk-prtvtoc-output で新しいディスクをフォーマットできます。
状態データベースの複製を削除した場合は、同じ数の複製を適切なスライスに追加します。
この例では、/dev/dsk/c0t1d0s4 を使用します。
# metadb -a -c 3 c0t1d0s4 |
ディスク上のスライスが、RAID 5 ボリュームのコンポーネントである場合、あるいは RAID 0 ボリュームのコンポーネントで、それが RAID 1 ボリュームのサブミラーになっている場合は、各スライスに metareplace -e コマンドを実行します。
この例では、/dev/dsk/c0t1d0s4 およびミラー d10 を使用します。
# metareplace -e d10 c0t1d0s4 |
ソフトパーティションが交換ディスクのスライス上に直接構築されている場合は、ソフトパーティションのあるスライスごとに metarecover -d -p コマンドを実行して、ディスクのエクステントヘッダーを再生します。
この例では、/dev/dsk/c0t1d0s4 の再作成されたディスクにソフトパーティションのマーキングが必要なので、このディスクをスキャンし、状態データベースの複製の情報に基づいてマーキングを再度適用します。
# metarecover c0t1d0s4 -d -p |
ディスク上のソフトパーティションが、RAID 5 ボリュームのコンポーネントである場合、あるいは RAID 0 ボリュームのコンポーネントで、それが RAID 1 ボリュームのサブミラーになっている場合は、各スライスに metareplace -e コマンドを実行します。
この例では、/dev/dsk/c0t1d0s4 およびミラー d10 を使用します。
# metareplace -e d10 c0t1d0s4 |
RAID 0 ボリューム上にソフトパーティションが構築されている場合は、各 RAID 0 ボリュームに metarecover コマンドを実行します。
この例では、RAID 0 ボリューム d17 にソフトパーティションが構築されています。
# metarecover d17 -m -p |
削除されたホットスペアを置き換え、それを 1 つまたは複数の適切なホットスペア集合に追加します。
# metahs -a hsp000 c0t0d0s6 hsp000: Hotspare is added |
ソフトパーティションまたは非冗長ボリュームが障害の影響を受けた場合は、バックアップからデータを復元します。 冗長ボリュームだけが影響を受けた場合は、データを検証します。
すべてのボリュームのユーザーデータやアプリケーションデータをチェックします。 必要であれば、アプリケーションレベルの整合性チェックプログラムなどのツールを使ってデータをチェックします。
この節では、Solaris ボリュームマネージャ環境でディスクを移動させた後に発生する予想外の問題から回復する方法について説明します。
Solaris ボリュームマネージャでは、特定のディスクと対応づけられたデバイス ID を使用して、Solaris ボリュームマネージャ構成で使用されているあらゆるディスクを追跡します。 ディスクを別のコントローラに移した場合、または SCSI ターゲット番号が変更された場合、通常は Solaris ボリュームマネージャが移動を正しく認識して、関連するすべての Solaris ボリュームマネージャレコードを相応に更新するので、システム管理者の介入は不要です。 とはいえ、まれに、Solaris ボリュームマネージャがレコードを正しく更新できず、起動時にエラーが通知されることがあります。
新しいハードウェアを追加したり、ハードウェアを移動させると (あるコントローラから別のコントローラに一連のディスクを移動させた場合など)、Solaris ボリュームマネージャが、移動されたディスクに対応するデバイス ID を調べ、内部 Solaris ボリュームマネージャレコードの c*t*d* 名を適切に更新します。 レコードを更新できなかった場合、 /etc/rc2.d/S95svm.sync (/etc/init.d/svm.sync へのリンク) によって生成された起動プロセスが、起動時に次のようなエラーをコンソールに通知します。
Unable to resolve unnamed devices for volume management. Please refer to the Solaris Volume Manager documentation, Troubleshooting section, at http://docs.sun.com or from your local copy." |
この問題によってデータが消失したわけでも、特に何かが起きるわけでもありません。 このメッセージが示していることは、Solaris ボリュームマネージャの名前レコードの一部だけが更新されたため、metastat コマンドの出力に、以前使用されていた c*t*d* 名と、移動後の状態が反映された c*t*d* 名が混在する可能性があるということです。
この条件下で Solaris ボリュームマネージャ構成の更新が必要になった場合は、meta* コマンドを実行する際に、必ず metastat コマンドの出力どおりの c*t*d* 名を使用してください。
このエラー条件が発生した場合、次の方法のどちらかで解決できます。
すべてのディスクを元の場所に戻す。 次に、再構成時の再起動を実行するか、(単一コマンドとして) 次のコマンドを実行する
/usr/sbin/devfsadm /usr/sbin/metadevadm -r |
コマンドの完了後、エラー条件が解決されるので、処理を続けることができます。
サポートの担当者に連絡し、指示を受ける
このエラー条件はめったに発生しません。 万一発生した場合は、高い確率で、ファイバチャネルに接続された記憶装置が影響を受けます。
Solaris ボリュームマネージャではルート (/)、swap、および /usr ディレクトリをミラー化できるため、システムの起動時に、ハードウェア障害やオペレータの操作ミスによって特殊な障害が発生することがあります。 この節の作業は、そのような障害に対処するためのものです。
次の表に、そのような障害の原因と適切な解決方法を示します。
表 261 Solaris ボリュームマネージャの一般的な起動障害
障害の原因 |
参照先 |
---|---|
/etc/vfstab ファイルの情報が正しくない | |
状態データベースの複製の数が足りない | |
起動デバイス (ディスク) に障害が発生した | |
起動ミラーに障害が発生した |
エラーのためにボリュームが Solaris ボリュームマネージャによってオフラインにされた場合は、障害が発生したディスクにあるすべてのファイルシステムのマウントを解除する必要があります。 個々のディスクスライスは独立しているため、 同じディスクに複数のファイルシステムがマウントされていることがあります。 ドライバソフトウェアに障害が発生した場合には、同じディスクの他のスライスでもまもなく障害が発生するはずです。 ディスクスライスに直接マウントされているファイルシステムは Solaris ボリュームマネージャのエラー処理対象ではないため、そのようなファイルシステムをマウントしたままにしておくと、システムのクラッシュによってデータを失う恐れがあります。
サブミラーを無効な状態やオフラインのままにしておく時間を最小限に抑えます。 再同期やオンラインバックアップの処理中は、ミラー化による保護は不完全になります。
たとえば、ルート (/) をミラー化するときに、/etc/vfstab ファイルに不適切なエントリを設定した場合、システムは最初は正しく起動しているように見えますが、やがて起動に失敗します。 この問題を解決するためには、シングルユーザーモードで /etc/vfstab ファイルを編集する必要があります。
/etc/vfstab ファイル内の不適切なエントリを修正するおおよその手順は次のとおりです。
シングルユーザーモードでシステムを起動します。
ミラーボリュームに対して fsck コマンドを実行します。
ファイルシステムを読み取り/書き込みモードでマウントし直します。
(省略可能) ルート (/) ミラーに対して metaroot コマンドを実行します。
/etc/vfstab ファイル内のファイルシステムエントリがこのボリュームを参照していることを確認します。
再起動します。
次の例では、ルート (/) が 2 面ミラー d0 でミラー化されています。 /etc/vfstab ファイルのルート (/) エントリが何らかの理由でこのファイルシステムの元のスライスに戻されていますが、/etc/system ファイルの情報は、起動がミラー d0 から行われるようになっています。 最も一般的な原因としては、metaroot コマンドを使わずに /etc/system や /etc/vfstab ファイルを変更したか、/etc/vfstab ファイルの古いコピーを復元したことが考えられます。
間違った /etc/vfstab ファイルの例を以下に示します。
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/dsk/c0t3d0s0 /dev/rdsk/c0t3d0s0 / ufs 1 no - /dev/dsk/c0t3d0s1 - - swap - no - /dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 2 no - # /proc - /proc proc - no - swap - /tmp tmpfs - yes - |
エラーがあるために、システムは、起動時に自動的にシングルユーザーモードになります。
ok boot ... configuring network interfaces: hme0. Hostname: lexicon mount: /dev/dsk/c0t3d0s0 is not this fstype. setmnt: Cannot open /etc/mnttab for writing INIT: Cannot create /var/adm/utmp or /var/adm/utmpx INIT: failed write of utmpx entry:" " INIT: failed write of utmpx entry:" " INIT: SINGLE USER MODE Type Ctrl-d to proceed with normal startup, (or give root password for system maintenance): root-password> |
この時点では、ルート (/) と /usr は読み取り専用でマウントされています。 次の手順を実行します。
ルート (/) ミラーに対して fsck コマンドを実行します。
ルートのボリューム名を間違えないでください。
# fsck /dev/md/rdsk/d0 ** /dev/md/rdsk/d0 ** Currently Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 2274 files, 11815 used, 10302 free (158 frags, 1268 blocks, 0.7% fragmentation) |
/etc/vfstab ファイルを編集できるように、ルート (/) を読み取り/書き込みモードでマウントし直します。
# mount -o rw,remount /dev/md/dsk/d0 / mount: warning: cannot lock temp file /etc/.mnt.lock> |
metaroot コマンドを実行します。
# metaroot d0 |
このコマンドを実行すると、/etc/system と /etc/vfstab ファイルが編集され、ルート (/) ファイルシステムのエントリがボリューム d0 を参照します。
/etc/vfstab ファイルに正しいボリュームのエントリが含まれていることを確認します。
/etc/vfstab ファイルのルート (/) エントリは次のようになっているはずです。これによって、ファイルシステムのエントリは RAID 1 ボリュームを正しく参照します。
#device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # /dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no - /dev/dsk/c0t3d0s1 - - swap - no - /dev/dsk/c0t3d0s6 /dev/rdsk/c0t3d0s6 /usr ufs 2 no - # /proc - /proc proc - no - swap - /tmp tmpfs - yes - |
システムを再起動します。
システムは正常な動作に戻ります。
ルート (/) がミラー化されているシステムの起動デバイスに障害がある場合は、代替起動デバイスを設定する必要があります。
この手順の概要は次のとおりです。
代替ルート (/) サブミラーからシステムを起動します。
エラーのある状態データベースの複製とボリュームを特定します。
不良ディスクを修復します。
状態データベースの複製とボリュームを元の状態に復元します。
次の例では、6 つの状態データベースの複製のうち 2 つが起動デバイスにあり、ルート (/)、swap、および /usr の各サブミラーが使用不能になっています。
起動デバイスに障害が発生すると、最初に次のようなメッセージが表示されます。 このメッセージは、アーキテクチャによってこれとは異なる場合があります。
Rebooting with command: Boot device: /iommu/sbus/dma@f,81000/esp@f,80000/sd@3,0 The selected SCSI device is not responding Can't open boot device ... |
このメッセージが表示された場合は、このデバイス名を書き留めておき、 次の手順を実行します。
ルート (/) の別のサブミラーからシステムを起動します。
この例では 2 つの状態データベースの複製だけが異常であるため、システムを起動することができます。 起動できない場合は、アクセスできない状態データベースの複製をシングルユーザーモードで削除する必要があります。 この手順については、「状態データベースの複製数の不足から回復するには」を参照してください。
ルート (/) ファイルシステムのミラーを作成したときに、その手順の中で代替起動デバイスを書き留めてあるはずです。 この例では、disk2 が代替起動デバイスになります。
ok boot disk2 SunOS Release 5.9 Version s81_51 64-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. Hostname: demo ... demo console login: root Password: root-password> Dec 16 12:22:09 lexicon login: ROOT LOGIN /dev/console Last login: Wed Dec 12 10:55:16 on console Sun Microsystems Inc. SunOS 5.9 s81_51 May 2002 ... |
metadb コマンドを使って、2 つの状態データベースの複製が使用不能であることを確認します。
# metadb flags first blk block count M p unknown unknown /dev/dsk/c0t3d0s3 M p unknown unknown /dev/dsk/c0t3d0s3 a m p luo 16 1034 /dev/dsk/c0t2d0s3 a p luo 1050 1034 /dev/dsk/c0t2d0s3 a p luo 16 1034 /dev/dsk/c0t1d0s3 a p luo 1050 1034 /dev/dsk/c0t1d0s3 |
不良ディスクの一部であるスライス /dev/dsk/c0t3d0s3 上の状態データベースの複製は、システムから認識されません。
metastat コマンドを使って、ルート (/)、swap、および /usr の各ミラーの半分が使用不能であることを確認します。
# metastat d0: Mirror Submirror 0: d10 State: Needs maintenance Submirror 1: d20 State: Okay ... d10: Submirror of d0 State: Needs maintenance Invoke: "metareplace d0 /dev/dsk/c0t3d0s0 new device>" Size: 47628 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t3d0s0 0 No Maintenance d20: Submirror of d0 State: Okay Size: 47628 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t2d0s0 0 No Okay d1: Mirror Submirror 0: d11 State: Needs maintenance Submirror 1: d21 State: Okay ... d11: Submirror of d1 State: Needs maintenance Invoke: "metareplace d1 /dev/dsk/c0t3d0s1 new device>" Size: 69660 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t3d0s1 0 No Maintenance d21: Submirror of d1 State: Okay Size: 69660 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t2d0s1 0 No Okay d2: Mirror Submirror 0: d12 State: Needs maintenance Submirror 1: d22 State: Okay ... d2: Mirror Submirror 0: d12 State: Needs maintenance Submirror 1: d22 State: Okay ... d12: Submirror of d2 State: Needs maintenance Invoke: "metareplace d2 /dev/dsk/c0t3d0s6 new device>" Size: 286740 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t3d0s6 0 No Maintenance d22: Submirror of d2 State: Okay Size: 286740 blocks Stripe 0: Device Start Block Dbase State Hot Spare /dev/dsk/c0t2d0s6 0 No Okay |
この例では、次のサブミラーの保守が必要であることがわかります。
サブミラー d10、デバイス c0t3d0s0
サブミラー d11、デバイス c0t3d0s1
サブミラー d12、デバイス c0t3d0s6
システムを停止し、ディスクを交換し、format コマンドまたは fmthard コマンドを使用して、障害の発生前と同じようにディスクをパーティション分割します。
新しいディスクが他方のディスク (つまり、ミラーの別の半分があるディスク) と同じ構成であれば、prtvtoc /dev/rdsk/c0t2d0s2 | fmthard -s - /dev/rdsk/c0t3d0s2 を使って、新しいディスク (c0t3d0) を短時間でフォーマットできます。
# halt ... Halted ... ok boot ... # format /dev/rdsk/c0t3d0s0 |
システムを再起動します。
ここでは、ルート (/) ミラーの他方の半分から起動する必要があります。 この代替起動デバイスは、ミラーを作成したときに書き留めておいたものです。
# halt ... ok boot disk2 |
metadb コマンドを使って、使用不能な状態データベースの複製を削除してから、新しい複製を追加します。
# metadb flags first blk block count M p unknown unknown /dev/dsk/c0t3d0s3 M p unknown unknown /dev/dsk/c0t3d0s3 a m p luo 16 1034 /dev/dsk/c0t2d0s3 a p luo 1050 1034 /dev/dsk/c0t2d0s3 a p luo 16 1034 /dev/dsk/c0t1d0s3 a p luo 1050 1034 /dev/dsk/c0t1d0s3 # metadb -d c0t3d0s3 # metadb -c 2 -a c0t3d0s3 # metadb flags first blk block count a m p luo 16 1034 /dev/dsk/c0t2d0s3 a p luo 1050 1034 /dev/dsk/c0t2d0s3 a p luo 16 1034 /dev/dsk/c0t1d0s3 a p luo 1050 1034 /dev/dsk/c0t1d0s3 a u 16 1034 /dev/dsk/c0t3d0s3 a u 1050 1034 /dev/dsk/c0t3d0s3 |
metareplace コマンドを使用して、サブミラーを再び有効にします。
# metareplace -e d0 c0t3d0s0 Device /dev/dsk/c0t3d0s0 is enabled # metareplace -e d1 c0t3d0s1 Device /dev/dsk/c0t3d0s1 is enabled # metareplace -e d2 c0t3d0s6 Device /dev/dsk/c0t3d0s6 is enabled |
しばらくすると、再同期処理が終了します。 これで、また元のデバイスから起動できるようになります。
ドライブ障害などのために、状態データベースの複製の数が規定数に達していないと、システムをマルチユーザーモードで再起動できなくなります。 この状態になるのは、使用可能な状態データベースの複製の数が半数に達しないことを Solaris ボリュームマネージャが検出した後 (パニックの後) や、使用可能な状態データベースの複製の数が半数以下の状態でシステムが再起動されたときなどです。 Solaris ボリュームマネージャでは、これを、状態データベースの複製が「無効」状態になったといいます。 この問題から回復するための手順を次に示します。
システムを起動して、どの状態データベースの複製に障害があるのか調べます。
使用不能な状態データベースの複製を特定します。
次の形式の metadb コマンドを実行します。
metadb -i |
1 つまたは複数のディスクが使用不能であることがわかっている場合は、それらのディスク上の状態データベースの複製をすべて削除します。 そうでない場合は、障害のある状態データベースの複製 (metadb の出力のステータスフラグ W、M、D、F、R で示される) を削除して、状態データベースの複製の過半数が正常なものであるようにします。
metadb -d コマンドを使って、不良ディスク上の状態データベースの複製を削除します。
大文字の状態フラグが付いている状態データベースの複製は障害のある複製であり、小文字のフラグが付いているものは正常な複製です。
metadb コマンドを使って、複製が削除されていることを確認します。
システムを再起動します。
必要であれば、ディスクを交換し、適切にフォーマットしてから、必要な状態データベースの複製をディスクに追加します。 「状態データベースの複製の作成 」の指示に従います。
交換用のディスクが用意できたら、システムを停止し、不良ディスクを交換してから、システムを再起動します。 format か fmthard コマンドを使って、障害の発生前と同じようにディスクをパーティション分割します。
この例では、7 つの状態データベースの複製を含むディスクに障害が発生したものとします。 システムには正常な複製が 3 つしか残らないため、システムはパニック状態になり、マルチユーザーモードで再起動できなくなります。
panic[cpu0]/thread=70a41e00: md: state database problem 403238a8 md:mddb_commitrec_wrapper+6c (2, 1, 70a66ca0, 40323964, 70a66ca0, 3c) %l0-7: 0000000a 00000000 00000001 70bbcce0 70bbcd04 70995400 00000002 00000000 40323908 md:alloc_entry+c4 (70b00844, 1, 9, 0, 403239e4, ff00) %l0-7: 70b796a4 00000001 00000000 705064cc 70a66ca0 00000002 00000024 00000000 40323968 md:md_setdevname+2d4 (7003b988, 6, 0, 63, 70a71618, 10) %l0-7: 70a71620 00000000 705064cc 70b00844 00000010 00000000 00000000 00000000 403239f8 md:setnm_ioctl+134 (7003b968, 100003, 64, 0, 0, ffbffc00) %l0-7: 7003b988 00000000 70a71618 00000000 00000000 000225f0 00000000 00000000 40323a58 md:md_base_ioctl+9b4 (157ffff, 5605, ffbffa3c, 100003, 40323ba8, ff1b5470) %l0-7: ff3f2208 ff3f2138 ff3f26a0 00000000 00000000 00000064 ff1396e9 00000000 40323ad0 md:md_admin_ioctl+24 (157ffff, 5605, ffbffa3c, 100003, 40323ba8, 0) %l0-7: 00005605 ffbffa3c 00100003 0157ffff 0aa64245 00000000 7efefeff 81010100 40323b48 md:mdioctl+e4 (157ffff, 5605, ffbffa3c, 100003, 7016db60, 40323c7c) %l0-7: 0157ffff 00005605 ffbffa3c 00100003 0003ffff 70995598 70995570 0147c800 40323bb0 genunix:ioctl+1dc (3, 5605, ffbffa3c, fffffff8, ffffffe0, ffbffa65) %l0-7: 0114c57c 70937428 ff3f26a0 00000000 00000001 ff3b10d4 0aa64245 00000000 panic: stopped at edd000d8: ta %icc,%g0 + 125 Type 'go' to resume ok boot -s Resetting ... Sun Ultra 5/10 UPA/PCI (UltraSPARC-IIi 270MHz), No Keyboard OpenBoot 3.11, 128 MB memory installed, Serial #9841776. Ethernet address 8:0:20:96:2c:70, Host ID: 80962c70. Rebooting with command: boot -s Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0:a File and args: -s SunOS Release 5.9 Version s81_39 64-bit Copyright 1983-2001 Sun Microsystems, Inc. All rights reserved. configuring IPv4 interfaces: hme0. Hostname: dodo metainit: dodo: stale databases Insufficient metadevice database replicas located. Use metadb to delete databases which are broken. Ignore any "Read-only file system" error messages. Reboot the system when finished to reload the metadevice database. After reboot, repair any broken database replicas which were deleted. Type control-d to proceed with normal startup, (or give root password for system maintenance): root password single-user privilege assigned to /dev/console. Entering System Maintenance Mode Jun 7 08:57:25 su: 'su root' succeeded for root on /dev/console Sun Microsystems Inc. SunOS 5.9 s81_39 May 2002 # metadb -i flags first blk block count a m p lu 16 8192 /dev/dsk/c0t0d0s7 a p l 8208 8192 /dev/dsk/c0t0d0s7 a p l 16400 8192 /dev/dsk/c0t0d0s7 M p 16 unknown /dev/dsk/c1t1d0s0 M p 8208 unknown /dev/dsk/c1t1d0s0 M p 16400 unknown /dev/dsk/c1t1d0s0 M p 24592 unknown /dev/dsk/c1t1d0s0 M p 32784 unknown /dev/dsk/c1t1d0s0 M p 40976 unknown /dev/dsk/c1t1d0s0 M p 49168 unknown /dev/dsk/c1t1d0s0 # metadb -d c1t1d0s0 # metadb flags first blk block count a m p lu 16 8192 /dev/dsk/c0t0d0s7 a p l 8208 8192 /dev/dsk/c0t0d0s7 a p l 16400 8192 /dev/dsk/c0t0d0s7 # |
システムがパニック状態になったのは、状態データベースの複製をスライス /dev/dsk/c1t1d0s0 上で検出できなかったためです (このスライスは、障害が発生したディスクの一部であるか、障害が発生したコントローラに接続されています)。 最初の metadb - i コマンドによって、このスライス上の複製のマスターブロックに問題があることがわかります。
無効状態の状態データベースの複製を削除する場合、ルート (/) ファイルシステムは読み取り専用になっています。 mddb.cf エラーメッセージが表示されますが、無視してください。
この時点でシステムは再び動作できるようになりますが、おそらく、システムには本来の数よりも少ない状態データベースの複製しかありません。また、障害が発生した記憶領域を使用していたボリュームは異常状態またはエラー状態になっているか、あるいはホットスペアで置き換えられています。このような問題は、速やかに解決しなければなりません。
トランザクションボリュームは、マスターデバイスとロギングデバイスからなる「階層構造」ボリュームです。また、ロギングボリュームは複数のファイルシステムによって共有されることがあるため、障害のあるトランザクションボリュームを修復する作業には、特別な回復手順が必要です。
デバイスのエラーやパニックの修復には、コマンド行ユーティリティを使用する必要があります。
ファイルシステムは、使用されている間に内部的な不整合を検出すると、システムをパニック状態にします。 また、ファイルシステムがロギングとして構成されている場合には、再起動時にファイルシステムのチェックが必要であることをトランザクションボリュームに通知します。 トランザクションボリュームは、それ自身を「ハードウェアエラー (Hard Error)」状態にします。 また、同じログデバイスを共有するすべてのトランザクションボリュームも「ハードウェアエラー (Hard Error)」状態になります。
再起動時に fsck は、このファイルシステムをチェック、修復し、「正常 (Okay)」状態に戻します。 fsck は、/etc/vfstab ファイルにリストされているトランザクションボリュームのうち、このログデバイスを共有するすべてのトランザクションボリュームに対してこの処理を実行します。
トランザクションボリュームがロギングデータを処理しているときにマスターデバイスかログデバイスでデバイスエラーが起こると、そのデバイスは「正常 (Okay)」状態から「ハードウェアエラー (Hard Error)」状態に移行します。 デバイスが「ハードウェアエラー (Hard Error)」状態か「エラー (Error)」状態の場合は、デバイスエラーまたはパニックが起きたことを意味します。
また、障害が発生したログデバイスを共有するデバイスも「エラー (Error)」状態になります。
次の各項では、ソフトパーティションの構成情報を復元する方法について説明します。 この方法は、状態データベースの複製がすべて失われており、また metastat -p の出力、md.cf ファイル、または最新の md.tab ファイルの最新コピーあるいは正確なコピーがまったくないときにだけ使用します。
各ソフトパーティションの先頭部分には、ソフトパーティションエクステントの開始位置を示すセクターがあります。 これらの隠しセクターはエクステントヘッダーと呼ばれ、ソフトパーティションのユーザーには見えません。 すべての Solaris ボリュームマネージャ構成が失われた場合には、ディスクをスキャンして構成データを生成することができます。
この手順は、失われたソフトパーティションの構成情報を復元する最後の手段です。 したがって、metarecover コマンドは、metadb ファイルと md.cf ファイルの両方が失われており、また md.tab も失われているか、md.tab が古い場合にのみ使用します。
この手順は、ソフトパーティションの情報を復元するためのものです。したがって、他の構成や他の Solaris ボリュームマネージャボリュームの構成情報を復元するためには使用できません。
ソフトパーティション上に他の Solaris ボリュームマネージャボリュームが作成されている場合には、ソフトパーティションを復元してから他のボリュームを復元する必要があります。
ソフトパーティションの構成情報は、デバイスと状態データベースに格納されています。 どちらかのソースが破壊されている可能性があるため、どちらが信頼できるソースなのかを metarecover コマンドに知らせる必要があります。
最初に、metarecover コマンドを使って 2 つのソースが一致するかどうかを判定します。 両者が一致する場合は、metarecover コマンドを使って変更を行うことはできません。 両者が一致しない場合は、出力を慎重に検討して、ディスクと状態データベースのどちらが破壊されているか判定する必要があります。次に metarecover コマンドを使い、適切なソースに基づいて構成を再構築します。
「ソフトパーティション構成の指針 」を確認します。
metarecover コマンドを実行し、出力されたソフトパーティション回復情報を検討します。
# metarecover component-p -d |
ここで、コンポーネントには、raw コンポーネントの c*t*d*s* 名を使用します。 -d オプションは、物理スライスをスキャンして、ソフトパーティションのエクステントヘッダーを検出することを意味します。
詳細は、metarecover(1M) のマニュアルページを参照してください。
# metarecover c1t1d0s1 -p -d The following soft partitions were found and will be added to your metadevice configuration. Name Size No. of Extents d10 10240 1 d11 10240 1 d12 10240 1 # metarecover c1t1d0s1 -p -d The following soft partitions were found and will be added to your metadevice configuration. Name Size No. of Extents d10 10240 1 d11 10240 1 d12 10240 1 WARNING: You are about to add one or more soft partition metadevices to your metadevice configuration. If there appears to be an error in the soft partition(s) displayed above, do NOT proceed with this recovery operation. Are you sure you want to do this (yes/no)?yes c1t1d0s1: Soft Partitions recovered from device. bash-2.05# metastat d10: Soft Partition Device: c1t1d0s1 State: Okay Size: 10240 blocks Device Start Block Dbase Reloc c1t1d0s1 0 No Yes Extent Start Block Block count 0 1 10240 d11: Soft Partition Device: c1t1d0s1 State: Okay Size: 10240 blocks Device Start Block Dbase Reloc c1t1d0s1 0 No Yes Extent Start Block Block count 0 10242 10240 d12: Soft Partition Device: c1t1d0s1 State: Okay Size: 10240 blocks Device Start Block Dbase Reloc c1t1d0s1 0 No Yes Extent Start Block Block count 0 20483 10240 |
この例では、すべての状態データベースの複製が誤って削除されているときに、ディスクから 3 つのソフトパーティションを復元します。
Solaris ボリュームマネージャ構成を元のシステムから別のシステムに回復できます。
システムの障害時には、記憶領域を別のシステムに接続し、ローカルディスクセットから完全な構成を回復できます。 たとえば、6 つのディスクからなる外部ディスクパックと Solaris ボリュームマネージャ構成のシステムがあるとします。これらのディスクには、少なくとも 1 つの状態データベースの複製があります。 システムの障害時には、そのディスクパックを新しいシステムに物理的に移動して、新しいシステムがその構成を認識できるように設定します。 ここでは、ディスクを別のシステムに移動して、ローカルディスクセットから構成を回復する方法を示します。
Solaris ボリュームマネージャ構成が含まれている 1 つまたは複数のディスクを、Solaris ボリュームマネージャ構成が存在していないシステムに追加します。
再起動してシステムを再構成し、新たに追加したディスクをシステムが認識できるようにします。
# reboot -- -r |
状態データベースの複製が含まれている (新たに追加したディスク上の) スライスのメジャー/マイナー番号を特定します。
ls -lL 出力のグループ名と日付の間にある 2 つの数字が このスライスのメジャー/マイナー番号です。
# ls -Ll /dev/dsk/c1t9d0s7 brw-r----- 1 root sys 32, 71 Dec 5 10:05 /dev/dsk/c1t9d0s7 |
必要であれば、/etc/name_to_major 内のメジャー番号を調べ、そのメジャー番号に対応するメジャー名を特定します。
# grep " 32" /etc/name_to_major sd 32 |
2 つのコマンドを使って /kernel/drv/md.conf ファイルを更新します。 最初のコマンドでは、有効な状態データベースの複製が新しいディスク上のどこにあるのかを Solaris ボリュームマネージャに指示します。 次のコマンドでは、新しい複製を優先して使用し、矛盾するデバイス ID がシステム上にあってもそれを無視するように Solaris ボリュームマネージャに指示します。
たとえば、mddb_bootlist1 で始まる行にある sd を、手順 4 で特定したメジャー名で置き換えます。また、同じ行の 71 を、手順1 で特定したマイナー番号で置き換えます。
#pragma ident "@(#)md.conf 2.1 00/07/07 SMI" # # Copyright (c) 1992-1999 by Sun Microsystems, Inc. # All rights reserved. # name="md" parent="pseudo" nmd=128 md_nsets=4; # #pragma ident "@(#)md.conf 2.1 00/07/07 SMI" # # Copyright (c) 1992-1999 by Sun Microsystems, Inc. # All rights reserved. # name="md" parent="pseudo" nmd=128 md_nsets=4; # Begin MDD database info (do not edit) mddb_bootlist1=" |
システムを再起動して、Solaris ボリュームマネージャに構成を再ロードさせます。
次のようなメッセージがコンソールに表示されます。
volume management starting. Dec 5 10:11:53 lexicon metadevadm: Disk movement detected Dec 5 10:11:53 lexicon metadevadm: Updating device names in Solaris Volume Manager The system is ready. |
構成を確認します。 metadb コマンドを実行して、状態データベースの複製の状態を確認します。 各ボリュームの状態を表示するには、metastat コマンドを使用します。
# metadb flags first blk block count a m p luo 16 8192 /dev/dsk/c1t9d0s7 a luo 16 8192 /dev/dsk/c1t10d0s7 a luo 16 8192 /dev/dsk/c1t11d0s7 a luo 16 8192 /dev/dsk/c1t12d0s7 a luo 16 8192 /dev/dsk/c1t13d0s7 # metastat d12: RAID State: Okay Interlace: 32 blocks Size: 125685 blocks Original device: Size: 128576 blocks Device Start Block Dbase State Reloc Hot Spare c1t11d0s3 330 No Okay Yes c1t12d0s3 330 No Okay Yes c1t13d0s3 330 No Okay Yes d20: Soft Partition Device: d10 State: Okay Size: 8192 blocks Extent Start Block Block count 0 3592 8192 d21: Soft Partition Device: d10 State: Okay Size: 8192 blocks Extent Start Block Block count 0 11785 8192 d22: Soft Partition Device: d10 State: Okay Size: 8192 blocks Extent Start Block Block count 0 19978 8192 d10: Mirror Submirror 0: d0 State: Okay Submirror 1: d1 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 82593 blocks d0: Submirror of d10 State: Okay Size: 118503 blocks Stripe 0: (interlace: 32 blocks) Device Start Block Dbase State Reloc Hot Spare c1t9d0s0 0 No Okay Yes c1t10d0s0 3591 No Okay Yes d1: Submirror of d10 State: Okay Size: 82593 blocks Stripe 0: (interlace: 32 blocks) Device Start Block Dbase State Reloc Hot Spare c1t9d0s1 0 No Okay Yes c1t10d0s1 0 No Okay Yes Device Relocation Information: Device Reloc Device ID c1t9d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3487980000U00907AZ c1t10d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3397070000W0090A8Q c1t11d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3449660000U00904NZ c1t12d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS32655400007010H04J c1t13d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3461190000701001T0 # # metadb flags first blk block count a m p luo 16 8192 /dev/dsk/c1t9d0s7 a luo 16 8192 /dev/dsk/c1t10d0s7 a luo 16 8192 /dev/dsk/c1t11d0s7 a luo 16 8192 /dev/dsk/c1t12d0s7 a luo 16 8192 /dev/dsk/c1t13d0s7 # metastat d12: RAID State: Okay Interlace: 32 blocks Size: 125685 blocks Original device: Size: 128576 blocks Device Start Block Dbase State Reloc Hot Spare c1t11d0s3 330 No Okay Yes c1t12d0s3 330 No Okay Yes c1t13d0s3 330 No Okay Yes d20: Soft Partition Device: d10 State: Okay Size: 8192 blocks Extent Start Block Block count 0 3592 8192 d21: Soft Partition Device: d10 State: Okay Size: 8192 blocks Extent Start Block Block count 0 11785 8192 d22: Soft Partition Device: d10 State: Okay Size: 8192 blocks Extent Start Block Block count 0 19978 8192 d10: Mirror Submirror 0: d0 State: Okay Submirror 1: d1 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 82593 blocks d0: Submirror of d10 State: Okay Size: 118503 blocks Stripe 0: (interlace: 32 blocks) Device Start Block Dbase State Reloc Hot Spare c1t9d0s0 0 No Okay Yes c1t10d0s0 3591 No Okay Yes d1: Submirror of d10 State: Okay Size: 82593 blocks Stripe 0: (interlace: 32 blocks) Device Start Block Dbase State Reloc Hot Spare c1t9d0s1 0 No Okay Yes c1t10d0s1 0 No Okay Yes Device Relocation Information: Device Reloc Device ID c1t9d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3487980000U00907AZ1 c1t10d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3397070000W0090A8Q c1t11d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3449660000U00904NZ c1t12d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS32655400007010H04J c1t13d0 Yes id1,sd@SSEAGATE_ST39103LCSUN9.0GLS3461190000701001T0 # metastat -p d12 -r c1t11d0s3 c1t12d0s3 c1t13d0s3 -k -i 32b d20 -p d10 -o 3592 -b 8192 d21 -p d10 -o 11785 -b 8192 d22 -p d10 -o 19978 -b 8192 d10 -m d0 d1 1 d0 1 2 c1t9d0s0 c1t10d0s0 -i 32b d1 1 2 c1t9d0s1 c1t10d0s1 -i 32b # |
Solaris ボリュームマネージャのディスクセットにデバイス ID サポートを導入すると、既知のディスクセットから記憶領域を回復できます。 metaimport コマンドを使用すると、あるシステムから別のシステムに既知のディスクセットをインポートできます。 両方のシステムにおいて、既存の Solaris ボリュームマネージャ構成でデバイス ID がサポートされている必要があります。 デバイス ID サポートの詳細については、「ディスクセット内で非同期的に共有される記憶領域」を参照してください。
ディスクセットをインポートする前に、/kernel/drv/md.conf ファイルにある nmd フィールドの値が、インポートするボリュームの名前空間を含むように設定されていることを確認します。 ディスクセットが持つボリュームの名前が nmd フィールドで設定された範囲外である場合、インポートは失敗します。 nmd フィールドの値をボリュームの名前空間を含むように設定し、システムを再起動してから、インポートを実行します。 たとえば、ディスクセットに d200 という名前のボリュームがある場合、nmd が 128 に設定されていると、インポートは失敗します。このインポートを成功させるには、nmd フィールドの値を少なくとも 201 まで増やす必要があります。 nmd フィールドの値を変更する方法については、「デフォルトのボリューム数を増やすには」を参照してください。
スーパーユーザーになります。
インポートに利用できるディスクセットについてのレポートを取得します。
# metaimport -r -v |
システム上にあってインポートに利用できる未構成のディスクセットのレポートを提供します。
状態データベースの複製の場所についての詳細な情報と、システム上にあってインポートに利用できる未構成のディスクセットのディスクの状態についての詳細な情報を提供します。
次の例では、インポートに利用できるディスクセットについてのレポートを出力する方法を示します。
# metaimport -r Drives in diskset including disk c1t2d0: c1t2d0 c1t3d0 c1t8d0 More info: metaimport -r -v c1t2d0 Import: metaimport -s newsetname> c1t2d0 # metaimport -r -v c1t2d0 Import: metaimport -s newsetname> c1t2d0 Last update: Mon Dec 29 14:13:35 2003 Device offset length replica flags c1t2d0 16 8192 a u c1t3d0 16 8192 a u c1t8d0 16 8192 a u |
スーパーユーザーになります。
ボリューム名が nmd 値の範囲内であるかどうかを確認します。 必要であれば、/kernel/drv/md.conf 内の nmd フィールドを変更します。 nmd フィールドの値を変更する方法については、「デフォルトのボリューム数を増やすには」を参照してください。
ディスクセットがインポートに利用できることを確認します。
# metaimport -r -v |
利用できるディスクセットをインポートします。
# metaimport -s diskset-name drive-name |
作成するディスクセットの名前です。
インポートするディスクセットの状態データベースの複製を含むディスク (c#t#d#) を指定します。
ディスクセットがインポートされたことを確認します。
# metaset -s diskset-name |
次の例では、ディスクセットをインポートする方法を示します。
# metaimport -s red c1t2d0 Drives in diskset including disk c1t2d0: c1t2d0 c1t3d0 c1t8d0 More info: metaimport -r -v c1t2d0 # metaset -s red Set name = red, Set number = 1 Host Owner lexicon Yes Drive Dbase c1t2d0 Yes c1t3d0 Yes c1t8d0 Yes |
この節では、ディスクセットの特定の問題から回復する方法について説明します。
システム障害、ディスク障害、通信リンクの障害などが原因で、どのノードからもディスクセットの所有権を取得できなくなり、ディスクセットのレコードを削除できない場合には、現在のホスト上にある Solaris ボリュームマネージャ状態データベースの複製からディスクセットのレコードをパージする方法があります。
ディスクセットのレコードをパージしても、ディスクセットに含まれる状態データベースの情報には影響しないため、そのディスクセットはあとでインポートできます。このためには、metaimport コマンドを使用します (「ディスクセットのインポート 」を参照)。
Sun Cluster 構成からディスクセットをパージする必要がある場合は、次の手順を使用します。ただし、Sun Cluster 構成が存在しないときに使用する -P オプションではなく、-C オプションを使用します。
metaset コマンドを使用して、ディスクセットの取得を試みます。
# metaset -s setname -t -f |
このコマンドは、setname で指定したディスクセットを強制的に (-f) に取得 (-t) します。 ディスクセットを取得できた場合、このコマンドは成功します。 このコマンドを実行したときに別のホストがこのディスクセットを所有していた場合、このホストはパニック状態になり、データの破損や損失が回避されます。 このコマンドが成功した場合、ディスクセットをきれいに削除できます。ディスクセットをパージする必要はありません。
ディスクセットを取得できなかった場合、所有権レコードをパージする必要があります。
metaset コマンドに -P オプションを付けて使用して、現在のホストからディスクセットをパージします。
# metaset -s setname -P |
このコマンドは、コマンドを実行したホストから、setname で指定したディスクセットをパージ (-P) します。
metaset コマンドを使用して、ディスクセットがパージされたことを確認します。
# metaset |
lexicon# metaset -s red -t -f metaset: lexicon: setname "red": no such set |
concordance# metaset Set name = red, Set number = 1 Host Owner concordance Drive Dbase c1t2d0 Yes c1t3d0 Yes c1t8d0 Yes concordance# metaset -s red -P concordance# metaset |
ディスクセットに関連する概念については、第20章「ディスクセット (概要)」を参照してください。
ディスクセットに関連する作業については、第21章「ディスクセット (作業)」を参照してください。