第 25 章 Solaris ボリュームマネージャのトラブルシューティング (作業)

この章では、Solaris ボリュームマネージャに関連する問題の解決方法について説明します。また、この章では、トラブルシューティングの一般的な指針と、既知の問題を解決するための具体的な手順も示します。

この章では、次の内容について説明します。

• 「Solaris ボリュームマネージャのトラブルシューティング (作業マップ)」

• 「トラブルシューティングの概要」

• 「ディスクの交換」

• 「ディスク移動の問題からの回復」

• 「Solaris 10 リリースにアップグレードした場合のデバイス ID の不一致」

• 「ブート障害からの回復」

• 「状態データベースの複製の障害からの回復」

• 「ソフトパーティション障害からの回復」

• 「別のシステムからの記憶領域の回復」

• 「ディスクセットの問題からの回復」

• 「ufsdump コマンドによるマウント済みファイルシステムのバックアップ」

• 「システムの復元」

この章では、Solaris ボリュームマネージャの問題とその解決方法について説明しますが、すべてを扱うわけではなく、一般的なシナリオと回復手順を紹介します。

Solaris ボリュームマネージャのトラブルシューティング (作業マップ)

次の表に、Solaris ボリュームマネージャのトラブルシューティングに必要な作業を示します。

トラブルシューティングの概要

トラブルシューティングの前提条件

Solaris ボリュームマネージャの記憶領域管理に関連する問題を解決するには、次の条件を満たしている必要があります。

• root 権限を持っている

• すべてのデータの最新バックアップを取っている

Solaris ボリュームマネージャによるトラブルシューティングの一般的な指針

Solaris ボリュームマネージャでトラブルシューティングを行うときは、次の情報を用意してください。

• metadb コマンドの出力

• metastat コマンドの出力

• metastat -p コマンドの出力

• /etc/vfstab ファイルのバックアップコピー

• /etc/lvm/mddb.cf ファイルのバックアップコピー

• prtvtoc コマンド (SPARC® システム) または fdisk コマンド (x86 ベースのシステム) で出力されるディスクパーティションの情報

• システムで稼働している Solaris のバージョン

• Solaris のインストール済みパッチを記したリスト

• Solaris ボリュームマネージャのインストール済みパッチを記したリスト

Solaris ボリュームマネージャ構成を更新したり、記憶領域やオペレーティングシステムに関連するその他の変更をシステムに適用した場合は、その構成情報の最新コピーを生成してください。cron ジョブを使えば、この情報を自動的に生成できます。

一般的なトラブルシューティング方法

1 つの手順で Solaris ボリュームマネージャに関連するすべての問題を検証できるわけではありませんが、一般には次の手順に従って障害を追跡します。

1. 現在の構成に関する情報を収集します。

2. metastat や metadb コマンドの出力など、最新の状態情報を調べます。この情報から、問題のあるコンポーネントがわかります。

3. 障害が起こりそうなハードウェア部分をチェックします

   • すべてのハードウェアが適切に接続されているか、

   • 最近、停電がなかったか

   • 機器を変更または追加しなかったか

ディスクの交換

この節では、Solaris ボリュームマネージャ環境でのディスク交換の方法について説明します。

不良ディスク上または不良ディスク上に構築したボリューム上でソフトパーティションを使用していた場合は、新しいディスクを交換対象ディスクと同じ物理位置に配置し、交換対象ディスクと同じ cntndn 番号を使用する必要があります。

不良ディスクを交換するには

1. /var/adm/messages ファイルと metastat コマンドの出力を調べて、交換すべき障害ディスクを特定します。

2. 不良ディスクに状態データベースの複製がないかチェックします。

   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 つの複製は正常です。

3. 状態データベースの複製が配置されているスライスの名前と状態データベースの複製数を記録します。その後、状態データベースの複製を削除します。

   状態データベースの複製の数は、 metadb コマンド出力に同じスライス名が表示される行数と同じです。この例では、c0t1d0s4 にある 3 つの状態データベースの複製を削除します。

   # metadb -d c0t1d0s4

   ---

   注意 –

   不良の状態データベースの複製を削除すると、複製の数が 3 以下になることがあります。その場合は、状態データベースの複製を追加してから先に進みます。これによって、前と同じ構成情報が保たれます。

   ---

4. 不良ディスクにホットスペアがないか探して、あれば削除します。

   ホットスペアの検索には、metastat コマンドを使用します。この例では、c0t1d0s6 がホットスペア集合 hsp000 に含まれていたので、集合から削除します。

   # metahs -d hsp000 c0t1d0s6 hsp000: Hotspare is deleted

5. 不良ディスクを交換します。

   この手順では、使用しているハードウェアと環境によって、cfgadm コマンド、luxadm コマンド、またはその他のコマンドを使用しなければならないことがあります。この手順の実行時には、使用しているハードウェアのマニュアルを参照しながら、Solaris 上でのこのディスクの状態を適切に操作してください。

6. 新しいディスクのパーティションを再分割します。

   format か fmthard コマンドを使い、不良ディスクと同じスライス情報に基づいてディスクをパーティション分割します。不良ディスクに対する prtvtoc の出力がある場合は、fmthard -s /tmp/failed-disk-prtvtoc-output コマンドで新しいディスクをフォーマットできます。

7. 状態データベースの複製を削除した場合は、同じ数の複製を適切なスライスに追加します。

   この例では、/dev/dsk/c0t1d0s4 を使用します。

   # metadb -a -c 3 c0t1d0s4

8. ディスク上のスライスが、RAID-5 ボリュームのコンポーネントである場合、あるいは RAID-0 ボリュームのコンポーネントで、それが RAID-1 ボリュームのサブミラーになっている場合は、各スライスに metareplace -e コマンドを実行します。

   この例では、/dev/dsk/c0t1d0s4 およびミラー d10 を使用します。

   # metareplace -e d10 c0t1d0s4

9. 交換したディスクのスライス上にソフトパーティションが直接構築されている場合は、ソフトパーティションが含まれているスライスごとに metarecover -m -p コマンドを実行します。このコマンドによって、ディスク上にエクステントヘッダーが再作成されます。

   この例では、 /dev/dsk/c0t1d0s4 の再作成されたディスクにソフトパーティションのマーキングが必要です。そこでスライスをスキャンし、状態データベースの複製の情報に基づいてマーキングを再適用します。

   # metarecover c0t1d0s4 -m -p

10. ディスク上のソフトパーティションが、RAID-5 ボリュームのコンポーネントである場合、あるいは RAID-0 ボリュームのコンポーネントで、それが RAID-1 ボリュームのサブミラーになっている場合は、各スライスに metareplace -e コマンドを実行します。

    この例では、/dev/dsk/c0t1d0s4 およびミラー d10 を使用します。

    # metareplace -e d10 c0t1d0s4

11. RAID-0 ボリューム上にソフトパーティションが構築されている場合は、各 RAID-0 ボリュームに metarecover コマンドを実行します。

    この例では、RAID-0 ボリューム d17 にソフトパーティションが構築されています。

    # metarecover d17 -m -p

12. 削除されたホットスペアを置き換え、それを 1 つまたは複数の適切なホットスペア集合に追加します。

    この例では、ホットスペア集合 hsp000 に c0t1d0s6 が含まれていました。このスライスをホットスペア集合に追加します。

    # metahs -a hsp000 c0t1d0s6 hsp000: Hotspare is added

13. ソフトパーティションまたは非冗長ボリュームが障害の影響を受けた場合は、バックアップからデータを復元します。冗長ボリュームだけが影響を受けた場合は、データを検証します。

    すべてのボリュームのユーザーデータとアプリケーションデータを調べます。必要であれば、アプリケーションレベルの整合性チェックプログラムなどのツールを使ってデータをチェックします。

ディスク移動の問題からの回復

ここでは、Solaris ボリュームマネージャ環境でディスクを移動させたあとで発生する予想外の問題から回復する方法について説明します。

ディスク移動とデバイス ID の概要

Solaris ボリュームマネージャでは、特定のディスクと対応づけられたデバイス ID を使用して、Solaris ボリュームマネージャ構成で使用されているあらゆるディスクを追跡します。ディスクを別のコントローラに移した場合、または SCSI ターゲット番号が変更された場合、通常は Solaris ボリュームマネージャが移動を正しく認識して、関連するすべての Solaris ボリュームマネージャレコードを相応に更新します。システム管理者の介入は不要です。とはいえ、まれに、Solaris ボリュームマネージャがレコードを正しく更新できず、ブート時にエラーが通知されることがあります。

名前のないデバイスに関するエラーメッセージを解決するには

新しいハードウェアを追加したり、ハードウェアを移動させると (あるコントローラから別のコントローラに一連のディスクを移動させた場合など)、Solaris ボリュームマネージャが、移動されたディスクに対応するデバイス ID を調べ、内部 Solaris ボリュームマネージャレコードの cnt ndn 名を適切に更新します。レコードを更新できなかった場合は、svc:/system/mdmonitor サービスによって生成されたブートプロセスがブート時にコンソールに対してエラーを伝えます。

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 コマンドの出力に、前に使用されていた cntndn 名の一部が示されます。この出力には、移動後の状態が反映された cntndn 名の一部も示されます。

この条件下で Solaris ボリュームマネージャ構成の更新が必要になった場合は、meta* コマンドを実行する際に、必ず metastat コマンドの出力どおりの cntndn 名を使用してください。

このエラー条件が発生した場合、次の方法のどちらかで解決できます。

• すべてのディスクを元の場所に戻す。次に、再構成時のリブートを実行するか、(単一コマンドとして) 次のコマンドを実行する

  /usr/sbin/devfsadm && /usr/sbin/metadevadm -r

  これらのコマンドが完了すると、エラー条件が解消されます。

• サポートの担当者に連絡し、指示を受ける

  ---

  注 –

  このエラー条件はめったに発生しません。万一発生した場合は、高い確率で、ファイバチャネルに接続された記憶装置が影響を受けます。

  ---

Solaris 10 リリースにアップグレードした場合のデバイス ID の不一致

Solaris 10 リリースから、デバイス ID 出力の表示形式が新しくなりました。Solaris ボリュームマネージャによるデバイス ID 出力の表示が新旧どちらの形式であるかは、デバイス ID 情報が状態データベースの複製に追加された時期によって決まります。

デバイス ID はこれまで 16 進値で表示されていました。新しい形式では、ASCII 文字列でデバイス ID が表示されます。次の例からわかるように、通常、変化はわずかです。

旧形式

id1,ssd@w 600c0ff00000000007ecd255a9336d00

新形式

id1,ssd@n 600c0ff00000000007ecd255a9336d00

次の例のように、変化が大きい場合もないわけではありません。

旧形式

id1,sd@w4849544143484920444b3332454a2d33364 \e4320202020203433334239383939

新形式

id1,ssd@n600c0ff00000000007ecd255a9336d00

Solaris 10 リリースにアップグレードした場合、既存のディスクセットに対応するデバイス IDは、Solaris ボリュームマネージャ構成で更新されません。以前の Solaris リリースに戻さなければならなくなった場合、アップグレード後にディスクセットに対して行った構成の変更は、以前のリリースでは使用できないことがあります。該当する構成変更は、次のとおりです。

• アップグレード以前に存在していたディスクセットへの新しいディスクの追加

• 新規ディスクセットの作成

• 状態データベースの複製の作成

このような構成変更は、ローカルディスクセットを含め、Solaris ボリュームマネージャで作成可能なあらゆるディスクセットに影響を与えます。たとえば、Solaris 10 リリースで作成したディスクセットに対してこのような変更を実行した場合、そのディスクセットは以前のリリースにインポートできません。もう 1 つ例を挙げます。ミラー化されたルートの片側を Solaris 10 リリースにアップグレードし、さらにローカルディスクセットに対して構成変更を行うことがあります。その後、サブミラーを以前のリリースに戻した場合、このような変更は認識されません。

Solaris 10 OS の構成には、アップグレードの場合も含めて、新しい形式のデバイス ID が示されます。prtconf -v コマンドを使用すると、この情報を表示できます。一方、Solaris ボリュームマネージャは、旧形式と新形式のどちらでも表示します。Solaris ボリュームマネージャでどちらの形式が表示されるかは、ディスクを使い始めたときに稼働していた Solaris OS のバージョンによって決まります。Solaris ボリュームマネージャが Solaris 10 リリースのデバイス ID と形式は異なるが同じ内容を示しているかどうかを判断するには、metastat コマンドの出力と prtconf -v コマンドの出力を比較します。

次の例では、metastat コマンドの出力は、同じディスクに対する prtconf -v コマンドの出力に含まれている c1t6d0 のデバイス ID と形式は異なりますが、内容は同じです。

# metastat
d127: Concat/Stripe
    Size: 17629184 blocks (8.4 GB)
    Stripe 0:
        Device     Start Block  Dbase   Reloc
        c1t6d0s2      32768     Yes     Yes

Device Relocation Information:
Device   Reloc  Device ID
 c1t6d0   Yes    id1,sd@w4849544143484920444b3332454a2d33364e4320202020203433334239383939

# prtconf -v
.(output truncated)

.
.
sd, instance #6
         System properties:
              name='lun' type=int items=1
                 value=00000000
              name='target' type=int items=1
                 value=00000006
              name='class' type=string items=1
                 value='scsi'
         Driver properties:
              name='pm-components' type=string items=3 dev=none
                 value='NAME=spindle-motor' + '0=off' + '1=on'
              name='pm-hardware-state' type=string items=1 dev=none
                 value='needs-suspend-resume'
              name='ddi-failfast-supported' type=boolean dev=none
              name='ddi-kernel-ioctl' type=boolean dev=none
              Hardware properties:
              name='devid' type=string items=1
                 value='id1,@THITACHI_DK32EJ-36NC_____433B9899'
.
.
.
(output truncated)

prtconf -v コマンドの出力に含まれている「instance #6」の行は、metastat コマンドの出力に含まれているディスク c1t6d0 と対応しています。prtconf -v コマンドの出力に含まれているデバイス ID id1,@THITACHI_DK32EJ-36NC_____433B9899 は、デバイス ID id1,sd@w4849544143484920444b3332454a2d33364e4320202020203433334239383939 という、metastat コマンドの出力と対応しています。この出力の相違は、Solaris ボリュームマネージャが metastat コマンドの出力では 16 進形式でデバイス ID を表示し、Solaris 10 OS 構成では prtconf コマンドの出力として ASCII 文字列を表示することを示します。

ブート障害からの回復

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

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

ブート障害の背景情報

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

  個々のディスクスライスは独立しているため、 同じディスクに複数のファイルシステムがマウントされていることがあります。ドライバソフトウェアに障害が発生した場合には、同じディスクの他のスライスでもまもなく障害が発生するはずです。ディスクスライスに直接マウントされているファイルシステムは、Solaris ボリュームマネージャによるエラー処理の対象になりません。このようなファイルシステムをマウントしたままにしておくと、システムクラッシュによってデータを失う可能性があります。

• サブミラーを無効な状態やオフラインのままにしておく時間を最小限に抑えます。再同期やオンラインバックアップの処理中は、ミラー化による保護は不完全になります。

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

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

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

1. シングルユーザーモードでシステムをブートします。

2. ミラーボリュームに対して fsck コマンドを実行します。

3. 読み取りオプションと書き込みオプションを有効にして、ファイルシステムをマウントし直します。

4. (省略可能)ルート (/) ミラーに対して metaroot コマンドを実行します。

5. /etc/vfstab ファイル内のファイルシステムエントリがこのボリュームを参照していることを確認します。

6. システムのリブート

ルート (/) 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 ファイルシステムは、読み取り専用としてマウントされています。次の手順を実行します。

1. ルート (/) ミラーに対して 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)

2. ルート (/) ファイルシステムを読み取り/書き込みファイルシステムとしてマウントし直し、 /etc/vfstab ファイルを編集できるようにします。

   # mount -o rw,remount /dev/md/dsk/d0 / mount: warning: cannot lock temp file </etc/.mnt.lock>

3. metaroot コマンドを実行します。

   # metaroot d0

   このコマンドを実行すると、/etc/system ファイルと /etc/vfstab ファイルが編集され、ルート (/) ファイルシステムのエントリがボリューム d0 を参照します。

4. /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 -

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

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

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

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

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

• 代替ルート (/) サブミラーからシステムをブートします。

• エラーのある状態データベースの複製とボリュームを特定します。

• 不良ディスクを修復します。

• 状態データベースの複製とボリュームを元の状態に復元します。

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

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

このメッセージが表示された場合は、このデバイス名を書き留めておき、次の手順を実行します。

1. ルート (/) の別のサブミラーからシステムをブートします。

   この例では 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 ...

2. 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 上の状態データベースの複製は、システムから認識されません。

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

4. システムを停止して、ディスクを交換します。format か fmthard コマンドを使って、障害の発生前と同じようにディスクをパーティション分割します。

   ---

   ヒント –

   新しいディスクが既存ディスクとまったく同じ場合 (この例では、ミラーの変更のない側)、ただちに新しいディスクをフォーマットします。フォーマットするには、prtvtoc /dev/rdsk/c0t2d0s2 | fmthard -s - /dev/rdsk/c0t3d0s2 コマンドを使用します (この例では c0t3d0)。

   ---

   # halt ... Halted ... ok boot ... # format /dev/rdsk/c0t3d0s0

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

   ここでは、ルート (/) ミラーの他方の半分からリブートする必要があります。この代替ブートデバイスは、ミラーを作成したときに書き留めておいたものです。

   # halt ... ok boot disk2

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

7. 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 ボリュームマネージャでは、これを、状態データベースの複製が「無効」状態になったといいます。この問題から回復するための手順を次に示します。

状態データベースの複製数の不足から回復するには

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

2. 使用不能な状態データベースの複製を特定します。

   # metadb -i

3. 1 つまたは複数のディスクが使用不能であることがわかっている場合は、それらのディスク上の状態データベースの複製をすべて削除します。そうでない場合は、障害のある状態データベースの複製 (metadb の出力のステータスフラグ W、M、D、F、R で示される) を削除して、状態データベースの複製の過半数が正常なものであるようにします。

   # metadb -d disk-slice

   ---

   ヒント –

   大文字の状態フラグが設定されている状態データベースの複製は、エラー状態です。小文字の状態フラグが設定されている状態データベースの複製は、正常に動作しています。

   ---

4. 複製が削除されたことを確認します。

   # metadb

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

   # reboot

6. 必要であれば、ディスクを交換し、適切にフォーマットしてから、必要な状態データベースの複製をディスクに追加します。

   「状態データベースの複製の作成」の指示に従います。

   交換用のディスクが用意できたら、システムを停止し、不良ディスクを交換してから、システムをリブートします。format か fmthard コマンドを使って、障害の発生前と同じようにディスクをパーティション分割します。

例 25–1 状態データベースの複製数の不足から回復する

この例では、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 エラーメッセージが表示されますが、無視してください。

この時点で、システムは再び動作状態になります。ただし、状態データベースの複製は、本来の数より少なくなっているはずです。障害記憶領域の一部を使用していたボリュームも、障害、エラー、またはホットスペア使用のいずれかになります。このような問題は、速やかに解決しなければなりません。

ソフトパーティション障害からの回復

ここでは、ソフトパーティションの構成情報を復元する方法について説明します。次の手順を使用するのは、状態データベースの複製がすべて失われていて、なおかつ次のいずれもない場合に限定してください。

• metastat -p の出力の最新コピーまたは正確なコピー

• md.cf ファイルの最新コピーまたは正確なコピー

• 最新の md.tab ファイル

ソフトパーティションの構成データを復元するには

各ソフトパーティションの先頭部分には、ソフトパーティションエクステントの開始位置を示すセクターがあります。このような隠れたセクターを「エクステントヘッダー」といいます。このヘッダーはソフトパーティションのユーザーには見えません。Solaris ボリュームマネージャの構成データがすべて失われた場合には、ディスクをスキャンして構成データを生成することができます。

この手順は、失われたソフトパーティションの構成情報を復元する最後の手段です。したがって、metarecover コマンドは、metadb ファイルと md.cf ファイルの両方が失われており、また md.tab ファイルも失われているか、md.tab ファイルが古い場合にのみ使用します。

この手順が有効なのは、ソフトパーティション情報を復元する場合だけです。この手順で、その他の失われた構成を復元したり、他の Solaris ボリュームマネージャボリュームの構成情報を復元したりすることはできません。

ソフトパーティション上に他の Solaris ボリュームマネージャボリュームが作成されている場合には、ソフトパーティションを復元してから他のボリュームを復元する必要があります。

ソフトパーティションの構成情報は、デバイスと状態データベースに格納されています。どちらかのソースが破壊されている可能性があるため、どちらが信頼できるソースなのかを metarecover コマンドに知らせる必要があります。

最初に、metarecover コマンドを使って 2 つのソースが一致するかどうかを判定します。両者が一致する場合は、metarecover コマンドを使って変更を行うことはできません。ただし、metarecover コマンドから不一致が伝えられた場合は、出力を丹念に調べ、ディスクが壊れているのか、それとも状態データベースが壊れているのかを判断する必要があります。さらに、metarecover コマンドを使用して、適切なソースに基づいて構成を再作成します。

1. 「ソフトパーティション構成の指針」を確認します。

2. metarecover コマンドを実行し、出力されたソフトパーティション回復情報を検討します。

   # metarecover component-p -d

   component

   raw コンポーネントの cnt ndnsn 名を指定します。

   -p

   ソフトパーティションを再作成することを指定します。

   -d

   物理スライスをスキャンしてソフトパーティションのエクステントヘッダーを検出することを指定します。

例 25–2 ディスク上のエクステントヘッダーからソフトパーティションを復元する

# 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 9 以降の Solaris ボリュームマネージャボリュームに限られます。

1. Solaris ボリュームマネージャ構成が含まれている 1 つまたは複数のディスクを、Solaris ボリュームマネージャ構成が存在していないシステムに追加します。

2. リブートしてシステムを再構成し、新たに追加したディスクをシステムが認識できるようにします。

   # reboot -- -r

3. 状態データベースの複製が含まれている (新たに追加したディスク上の) スライスのメジャー/マイナー番号を特定します。

   ls -lL 出力のグループ名と日付の間にある 2 つの数字がこのスライスのメジャー/マイナー番号です。

   # ls -Ll /dev/dsk/c1t9d0s7 brw-r----- 1 root sys 32, 71 Dec 5 10:05 /dev/dsk/c1t9d0s7

4. 必要であれば、/etc/name_to_major 内のメジャー番号を調べ、そのメジャー番号に対応するメジャー名を特定します。

   # grep " 32" /etc/name_to_major sd 32

5. 有効な状態データベースの複製が新しいディスク上のどこにあるのかを Solaris ボリュームマネージャに指示する情報を使用して、/kernel/drv/md.conf ファイルを更新します。

   たとえば、mddb_bootlist1 で始まる行にある sd を、手順 4 で特定したメジャー名で置き換えます。また、同じ行の 71 を、手順 3 で特定したマイナー番号で置き換えます。

   #pragma ident "@(#)md.conf 2.2 04/04/02 SMI" # # Copyright 2004 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # # The parameters nmd and md_nsets are obsolete. The values for these # parameters no longer have any meaning. name="md" parent="pseudo" nmd=128 md_nsets=4; # Begin MDD database info (do not edit) mddb_bootlist1="sd:71:16:id0"; # End MDD database info (do not edit)

6. システムをリブートして、Solaris ボリュームマネージャに構成を再ロードさせます。

   次のようなメッセージがコンソールに表示されます。

   volume management starting. Dec 5 10:11:53 host1 metadevadm: Disk movement detected Dec 5 10:11:53 host1 metadevadm: Updating device names in Solaris Volume Manager The system is ready.

7. 構成を確認します。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 サポートの詳細については、「ディスクセット内で非同期的に共有される記憶領域」を参照してください。metaimport コマンドの詳細については、metaimport(1M) のマニュアルページを参照してください。

インポートに利用できるディスクセットのレポートを出力するには

1. スーパーユーザーになります。

2. インポートに利用できるディスクセットについてのレポートを取得します。

   # metaimport -r -v

   -r

   システム上にあってインポートに利用できる未構成のディスクセットのレポートを提供します。

   -v

   状態データベースの複製の場所についての詳細な情報と、システム上にあってインポートに利用できる未構成のディスクセットのディスクの状態についての詳細な情報を提供します。

例 25–3 インポートに利用できるディスクセットを報告する

次の例では、インポートに利用できるディスクセットについてのレポートを出力する方法を示します。

# metaimport -r
 Drives in regular diskset including disk c1t2d0:
   c1t2d0
   c1t3d0
 More info:
   metaimport -r -v c1t2d0 
Import:   metaimport -s <newsetname> c1t2d0 
 Drives in replicated diskset including disk c1t4d0:
   c1t4d0
   c1t5d0
 More info:
   metaimport -r -v c1t4d0 
Import:   metaimport -s <newsetname> c1t4d0


# 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     

あるシステムから別のシステムにディスクセットをインポートするには

1. スーパーユーザーになります。

2. ディスクセットがインポート可能であることを確認します。

   # metaimport -r -v

3. 利用できるディスクセットをインポートします。

   # metaimport -s diskset-name drive-name

   - s diskset-name

   作成するディスクセットの名前です。

   drive-name

   インポートするディスクセットの状態データベースの複製を含むディスク (c#t#d#) を指定します。

4. ディスクセットがインポートされたことを確認します。

   # metaset -s diskset-name

例 25–4 ディスクセットのインポート

次の例では、ディスクセットをインポートする方法を示します。

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

Drive    Dbase

c1t2d0   Yes  

c1t3d0   Yes  

c1t8d0   Yes  

ディスクセットの問題からの回復

この節では、ディスクセットの特定の問題から回復する方法について説明します。

ディスクセットの所有権を取得できないときには

システム障害、ディスク障害、通信リンクの障害などが原因で、どのノードからもディスクセットの所有権を取得できなくなり、ディスクセットのレコードを削除できない場合には、現在のホスト上にある Solaris ボリュームマネージャ状態データベースの複製からディスクセットのレコードを削除する方法があります。

ディスクセットのレコードを削除しても、ディスクセットに含まれる状態データベースの情報には影響しないため、そのディスクセットはあとでインポートできます。このためには、metaimport コマンドを使用します (「ディスクセットのインポート」を参照)。

Sun Cluster 構成からディスクセットを削除する必要がある場合は、次の手順を使用します。ただし、Sun Cluster 構成が存在しないときに使用する -P オプションではなく、-C オプションを使用します。

ディスクセットを削除するには

1. metaset コマンドを使用して、ディスクセットの取得を試みます。

   # metaset -s setname -t -f

   このコマンドは、setname で指定したディスクセットを強制的に (-f) に取得 (-t) します。ディスクセットを取得できた場合、このコマンドは成功します。このコマンドを実行したときに別のホストがこのディスクセットを所有していた場合、このホストはパニック状態になり、データの破損や損失が回避されます。このコマンドが成功した場合、ディスクセットをきれいに削除できます。ディスクセットを削除する必要はありません。

   ディスクセットを取得できなかった場合、所有権レコードを削除する必要があります。

2. metaset コマンドに -P オプションを付けて使用して、現在のホストからディスクセットを削除します。

   # metaset -s setname -P

   このコマンドは、コマンドを実行したホストから、setname で指定したディスクセットを削除 (-P) します。

3. metaset コマンドを使用して、ディスクセットが削除されたことを確認します。

   # metaset

例 25–5 ディスクセットを削除する

host1# metaset -s red -t -f
metaset: host1: setname "red": no such set

host2# metaset

Set name = red, Set number = 1

Host                Owner
  host2        

Drive    Dbase

c1t2d0   Yes  

c1t3d0   Yes  

c1t8d0   Yes  

host2# metaset -s red -P
host2# metaset

参照

• 第 18 章「ディスクセット (概要)」(ディスクセットに関連する概念)

• 第 19 章「ディスクセット (作業)」(ディスクセットに関連する作業)

ufsdump コマンドによるマウント済みファイルシステムのバックアップ

次の手順で、RAID-1 ボリューム上のマウント済みファイルシステムを ufsdump コマンドを使用してバックアップする場合に、ufsdump コマンドの性能を向上させる方法について説明します。

RAID-1 ボリューム上のマウント済みファイルのバックアップを実行するには

ufsdump コマンドを使用すると、RAID-1 ボリューム上のマウント済みファイルシステムのファイルをバックアップできます。バックアップユーティリティーが ufsdump の場合は、ボリュームの読み取りポリシーを「first」に設定します。バックアップの実行速度が上がります。

1. スーパーユーザーになります。

2. metastat コマンドを実行して、ミラーが「正常 (Okay)」状態であることを確認します。

   # metastat d40 d40: Mirror Submirror 0: d41 State: Okay Submirror 1: d42 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 20484288 blocks (9.8 GB)

   ミラーが「保守 (Maintenance)」状態の場合は、まずそれを修復する必要があります。

3. ミラーの読み取りポリシーを「first」に設定します。

   # metaparam -r first d40 # metastat d40 d40: Mirror Submirror 0: d41 State: Okay Submirror 1: d42 State: Okay Pass: 1 Read option: first Write option: parallel (default) Size: 20484288 blocks (9.8 GB)

4. ファイルシステムのバックアップを実行します。

   # ufsdump 0f /dev/backup /opt/test

5. ufsdump コマンドの実行後、ミラーの読み取りポリシーを「roundrobin」に設定します。

   # metaparam -r roundrobin d40 # metastat d40 d40: Mirror Submirror 0: d41 State: Okay Submirror 1: d42 State: Okay Pass: 1 Read option: roundrobin Write option: parallel (default) Size: 20484288 blocks (9.8 GB)

システムの復元

システムを復元するとき、DVD または CD メディア上にある Solaris OS インストールイメージからブートすると便利な場合があります。たとえば、root のパスワードをリセットできるというのも、インストールイメージから起動するときの利点です。

Solaris ボリュームマネージャ構成を使用している場合は、実際のディスクではなく、Solaris ボリュームマネージャボリュームをマウントします。この手順は、ルート (/) ファイルシステムがミラー化されている場合には特に重要になります。Solaris ボリュームマネージャは Solaris OS の一部であるため、Solaris ボリュームマネージャボリュームをマウントすると、すべての変更がミラーの両側に反映されます。

Solaris OS DVD または CD-ROM のインストールイメージから Solaris ボリュームマネージャボリュームにアクセスできるようにするには、次の手順を使用します。

Solaris ボリュームマネージャ構成を使用してシステムを復元するには

Solaris OS インストール DVD または CD メディアからシステムをブートします。この手順は、Solaris miniroot の root プロンプトから実行します。

1. Solaris ボリュームマネージャ構成が含まれる実際のディスクを読み取り専用としてマウントします。

   # mount -o ro /dev/dsk/c0t0d0s0 /a

2. md.conf ファイルを /kernel/drv ディレクトリにコピーします。

   # cp /a/kernel/drv/md.conf /kernel/drv/md.conf

3. ファイルシステムを miniroot からマウント解除します。

   # umount /a

4. この構成を読み込むように、Solaris ボリュームマネージャドライバを更新します。update_drv コマンドから出力される警告メッセージはすべて無視します。

   # update_drv -f md

5. システムボリュームを構成します。

   # metainit -r

6. Solaris ボリュームマネージャ構成に RAID-1 ボリュームがある場合は、これらのボリュームの再同期をとります。

   # metasync mirror-name

7. mount コマンドを使用すれば、Solaris ボリュームマネージャボリュームにアクセスできます。

   # mount /dev/md/dsk/volume-name /a

例 25–6 Solaris ボリュームマネージャ構成を使用してシステムを復元する

# mount -o ro /dev/dsk/c0t0d0s0 /a
# cp /a/kernel/drv/md.conf /kernel/drv/md.conf
# umount /a
# update_drv -f md
Cannot unload module: md
Will be unloaded upon reboot.
Forcing update of md.conf.
devfsadm: mkdir fialed for /dev 0xled: Read-only file system
devfsadm: inst_sync failed for /etc/path_to_inst.1359: Read-only file system
devfsadm: WARNING: failed to update /etc/path_to_inst
# metainit -r
# metasync d0
# mount /dev/md/dsk/d0 /a