| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Solaris Volume Manager 管理ガイド Oracle Solaris 10 1/13 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Solaris Volume Manager 管理ガイド Oracle Solaris 10 1/13 Information Library (日本語) |
1. Solaris Volume Manager の使用開始
4. Solaris Volume Manager for Sun Cluster (概要)
5. Solaris Volume Manager の構成と使用 (シナリオ)
8. RAID-0 (ストライプと連結) ボリューム (概要)
9. RAID-0 (ストライプおよび連結) ボリューム (タスク)
20. Solaris Volume Manager の保守 (タスク)
21. Solaris Volume Manager のベストプラクティス
25. Solaris Volume Manager のトラブルシューティング (タスク)
Solaris Volume Manager のトラブルシューティング (タスクマップ)
Solaris Volume Manager のトラブルシューティングの一般的なガイドライン
Solaris 10 リリースにアップグレードしたあとのデバイス ID の不一致
インポートに使用可能なディスクセットに関するレポートを出力する方法
ディスクセットをあるシステムから別のシステムにインポートする方法
ufsdump コマンドによるマウント済みファイルシステムのバックアップの実行
RAID-1 ボリューム上のマウント済みファイルシステムのバックアップを実行する方法
Solaris Volume Manager 構成を使用してシステムを回復する方法
A. 重要な Solaris Volume Manager ファイル
B. Solaris Volume Manager のクイックリファレンス
Solaris Volume Manager ではルート (/)、swap、および /usr ディレクトリをミラー化できるので、システムのブート時に特殊な問題が発生することがあります。このような問題の原因は、ハードウェア障害またはオペレータエラーのどちらかです。このセクションでは、このような問題に対処するための手順について説明します。
次の表に、そのような問題の説明と適切な解決方法を示します。
表 25-1 Solaris Volume Manager での一般的なブートの問題
|
エラーのためにボリュームが Solaris Volume Manager によってオフラインにされた場合は、障害が発生したディスクにあるすべてのファイルシステムをアンマウントしてください。
個々のディスクスライスは独立しているため、同じディスクに複数のファイルシステムがマウントされていることがあります。ソフトウェアに障害が発生した場合には、同じディスクの他のスライスでもまもなく障害が発生するはずです。ディスクスライスに直接マウントされているファイルシステムは、Solaris Volume Manager によるエラー処理の保護の対象になりません。このようなファイルシステムをマウントしたままにしておくと、システムクラッシュによってデータを失う可能性があります。
サブミラーを無効な状態やオフラインのままにしておく時間を最小限に抑えてください。再同期やオンラインバックアップの処理中は、ミラー化による保護は不完全になります。
ルート (/) ファイルシステムをミラー化するときなどに、/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 ファイルにコピーしたことが原因になる場合もあります。
不適切な /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: host1 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 /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)
# mount -o rw,remount /dev/md/dsk/d0 / mount: warning: cannot lock temp file </etc/.mnt.lock>
# metaroot d0
このコマンドは、ルート (/) ファイルシステムが現在はボリューム d0 上にあることを示すように、/etc/system ファイルと /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 -
システムは通常の動作に戻ります。
ルート (/) がミラー化されているシステムのブートデバイスに障害がある場合は、代替ブートデバイスを設定する必要があります。
このタスクの大まかな手順は次のとおりです。
代替ルート (/) サブミラーからシステムをブートする
エラーのある状態データベースの複製とボリュームを特定する
不良ディスクを修復する
状態データベースの複製とボリュームを元の状態に復元する
ブートデバイスに障害が発生すると、最初に次のようなメッセージが表示されます。このメッセージは、アーキテクチャーによって異なる場合があります。
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 ...
このメッセージが表示された場合は、そのデバイスを書き留めておきます。その後、次の手順に従ってください。
この例では、6 つの状態データベースの複製のうち 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 host1 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
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
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
...
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 この例では、次のサブミラーの保守が必要であることが metastat コマンドで示されています。
サブミラー d10、デバイス c0t3d0s0
サブミラー d11、デバイス c0t3d0s1
サブミラー d12、デバイス c0t3d0s6
ヒント - 新しいディスクが既存ディスク (この例では、ミラーの変更のない側) とまったく同じ場合は、新しいディスクを簡単にフォーマットできます。それには、prtvtoc /dev/rdsk/c0t2d0s2 | fmthard -s - /dev/rdsk/c0t3d0s2 コマンド (この例では c0t3d0) を使用します。
# halt ... Halted ... ok boot ... # format /dev/rdsk/c0t3d0s0
ルート (/) ミラーの他方の半分からリブートする必要があります。この代替ブートデバイスは、ミラーを作成したときに書き留めておいたものです。
# halt ... ok boot disk2
# 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 -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
しばらくすると、再同期が完了します。これで、また元のデバイスからブートできるようになります。
|