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

第26章 Solaris ボリュームマネージャの障害追跡 (作業)

この章では、Solaris ボリュームマネージャに関連する問題の解決方法について説明します。また、この章では、障害追跡の一般的な指針と、いくつかの特定の問題を解決するための具体的な手順も示します。

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

この章は、Solaris ボリュームマネージャの問題とその解決方法について説明し、一般的なシナリオと回復手順を示すことを目的としています。ここでは、包括的な情報は提供されません。

Solaris ボリュームマネージャの障害追跡 (作業マップ)

次の表に、Solaris ボリュームマネージャの障害追跡に必要な作業を示します。

作業	説明	参照先
不良ディスクを交換する	ディスクを交換してから、新しいディスク上の状態データベースの複製と論理ボリュームを更新します。	「不良ディスクを交換するには」
ディスク移動の問題から回復する	ディスクを元の場所に戻すか、製品サポートに連絡します。	「ディスク移動の問題からの回復」
`/etc/vfstab` 内の不適切なエントリを修正する	ミラーに対して `fsck` コマンドを実行してから、システムが正しく起動するように `/etc/vfstab` ファイルを編集します。	「`/etc/vfstab` 内の不適切なエントリを修正するには」
起動デバイスの障害から回復する	ほかのサブミラーから起動します。	「起動デバイスの障害から回復するには」
状態データベースの複製数の不足から回復する	`metadb` コマンドを使って、使用不能な複製を削除します。	「状態データベースの複製数の不足から回復するには」
ソフトパーティションの失われた構成データを復元する	`metarecover` コマンドを使って、ソフトパーティションの構成データを復元します。	「ソフトパーティションの構成データを復元するには」
別のディスクから Solaris ボリュームマネージャ構成を復元する	新しいシステムにディスクを追加し、既存の状態データベースの複製から Solaris ボリュームマネージャ構成を再構築します。	「ローカルディスクセットから記憶領域を回復するには」
別のシステムから記憶領域を回復する	既知のディスクセットから別のシステムへ記憶領域をインポートします。	「別のシステムからの記憶領域の回復」
アクセスできないディスクセットをパージする	`metaset` コマンドを使用して、取得または使用できないディスクセットのレコードをパージします。	「ディスクセットの問題からの回復」

障害追跡の概要

障害追跡の前提条件

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

ルート権限を持っている
すべてのデータの最新バックアップを取っている

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 ボリュームマネージャ環境でディスクを移動させた後に発生する予想外の問題から回復する方法について説明します。

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

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` ファイルの情報が正しくない	「`/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 ファイルの例を以下に示します。

#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 コマンドを使って、障害の発生前と同じようにディスクをパーティション分割します。

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

この例では、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) のマニュアルページを参照してください。

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

# 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="sd:71:16:id0";  md_devid_destroy=1; \
# End MDD database info (do not edit)

システムを再起動して、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
-r

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

-v

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

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

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

# 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
- s diskset-name

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

drive-name

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

ディスクセットがインポートされたことを確認します。
# metaset -s diskset-name

例 264 ディスクセットをインポートする

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

# 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

例 265 ディスクセットをパージする

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章「ディスクセット (作業)」を参照してください。