Solaris ボリュームマネージャの管理

ブート障害からの回復

Solaris ボリュームマネージャではルート (/)、 swap、および /usr ディレクトリをミラー化できるので、システムのブート時に特殊な問題が発生することがあります。原因はハードウェア障害またはオペレータエラーのどちらかです。この節では、このような障害に対処するための手順について説明します。

次の表に、そのような障害の原因と適切な解決方法を示します。

表 25–1 Solaris ボリュームマネージャで一般的なブート障害


障害の原因	参照先
`/etc/vfstab` ファイルの情報が正しくない	「`/etc/vfstab` 内の不適切なエントリを修正するには」
十分な数の状態データベースの複製が定義されていない	「状態データベースの複製数の不足から回復するには」
ブートデバイス (ディスク) に障害が発生した	「ブートデバイスの障害から回復するには」

ブート障害の背景情報

エラーのためにボリュームが Solaris ボリュームマネージャによってオフラインにされた場合は、障害が発生したディスクにあるすべてのファイルシステムのマウントを解除する必要があります。

個々のディスクスライスは独立しているため、同じディスクに複数のファイルシステムがマウントされていることがあります。ドライバソフトウェアに障害が発生した場合には、同じディスクの他のスライスでもまもなく障害が発生するはずです。ディスクスライスに直接マウントされているファイルシステムは、Solaris ボリュームマネージャによるエラー処理の対象になりません。このようなファイルシステムをマウントしたままにしておくと、システムクラッシュによってデータを失う可能性があります。
サブミラーを無効な状態やオフラインのままにしておく時間を最小限に抑えます。再同期やオンラインバックアップの処理中は、ミラー化による保護は不完全になります。

`/etc/vfstab` 内の不適切なエントリを修正するには

ルート (/) ファイルシステムをミラー化するときなどに、/etc/vfstab ファイルに不適切なエントリを作成した場合、システムは一見、正常にブートしているように見えますが、あとからシステム障害が発生します。この問題を解決するためには、シングルユーザーモードで /etc/vfstab ファイルを編集する必要があります。

/etc/vfstab ファイル内の不適切なエントリを修正するおおよその手順は次のとおりです。

シングルユーザーモードでシステムをブートします。
ミラーボリュームに対して fsck コマンドを実行します。
読み取りオプションと書き込みオプションを有効にして、ファイルシステムをマウントし直します。
(省略可能)ルート (/) ミラーに対して metaroot コマンドを実行します。
/etc/vfstab ファイル内のファイルシステムエントリがこのボリュームを参照していることを確認します。
システムのリブート

ルート (`/`) RAID-1 (ミラー) ボリュームを回復する

次の例では、ルート (/) ファイルシステムが 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 コマンドを実行します。

注 –

ルート (/) ミラーに正しいボリュームを使用するように注意してください。

# 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     -

システムをリブートします。

システムは正常な動作に戻ります。

ブートデバイスの障害から回復するには

ルート (/) がミラー化されているシステムのブートデバイスに障害がある場合は、代替ブートデバイスを設定する必要があります。

この手順の概要は次のとおりです。

代替ルート (/) サブミラーからシステムをブートします。
エラーのある状態データベースの複製とボリュームを特定します。
不良ディスクを修復します。
状態データベースの複製とボリュームを元の状態に復元します。

ブートデバイスに障害が発生すると、最初に次のようなメッセージが表示されます。このメッセージは、アーキテクチャーによってこれとは異なる場合があります。

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 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 コマンドを使って、状態データベースの使用不能な複製数を判別します。

# 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
...
 
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

しばらくすると、再同期処理が終了します。これで、また元のデバイスからブートできるようになります。

ブート障害からの回復

ブート障害の背景情報

/etc/vfstab 内の不適切なエントリを修正するには

ルート (/) RAID-1 (ミラー) ボリュームを回復する

ブートデバイスの障害から回復するには

`/etc/vfstab` 内の不適切なエントリを修正するには

ルート (`/`) RAID-1 (ミラー) ボリュームを回復する