Solstice DiskSuite 4.2.1 ユーザーズガイド

第 7 章システムのトラブルシューティング

この章では、DiskSuite の問題を解決する方法について説明します。

特定の作業に対する手順ごとの指示を記載した節に直接進むためには、次の目次を使用してください。

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

この章では、DiskSuite に関するいくつかのトラブル、およびその適切な解決法について説明します。テーマを包括的に取り上げるのではなく、共通のシナリオと回復手順を提示することを目的としています。

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

この節に含まれる手順の前提条件を次に示します。

ルート権限をもつ。
現在の時点で、すべてのデータをバックアップしている。

トラブルシューティングを行う時の注意

トラブルシューティングを行う前に、次の情報を調べてください。

/etc/vfstab ファイルの内容
DiskSuite ツール、または metadb(1M) コマンドと metastat(1M) コマンドの出力から得られる、状態データベースの複製、メタデバイス、ホットスペアの状態
prtvtoc(1M) コマンドやストレージマネージャ (Solaris システム)、または fdisk コマンド (x86 システム) から得られる、ディスクパーティションに関する情報
Solaris のバージョン
Solaris のパッチ
DiskSuite のパッチ

DiskSuite 設定の回復

/etc/lvm/md.cf ファイルは、ローカルディスクセット用の DiskSuite 設定のバックアップファイルです。設定を変更するたびに、md.cf ファイルは自動的に更新されます (ホットスペアリングを除く)。md.cf ファイルを直接編集しないでください。

システムがメタデバイスの状態データベース内に保存されていた情報を失った場合、その一方でメタデバイスの作成や変更が行われていない限り、md.cf ファイルを使用して、DiskSuite 設定を回復することができます。

注 -

md.cf ファイルは、アクティブなホットスペアに関する情報を保持しません。したがって、DiskSuite の設定が失われたときにホットスペアが使用されていた場合、ホットスペアを使用しているメタデバイスは、おそらく破壊されます。

`md.cf` ファイルを使用して DiskSuite 設定を回復する方法

注意 -

この作業を行うのは、DiskSuite の設定が完全に失われた場合だけです。

状態データベースの複製を再作成する。

状態データベースの複製の作成方法については、第 1 章「概要」を参照してください。

/etc/lvm/md.tab ファイルのバックアップコピーを作成する。

md.cf ファイルから md.tab ファイルに情報をコピーする。

新しい md.tab ファイルを編集して、次のように設定する。
- すべてのミラーを 1 面のミラーにします。ミラーのサブミラーが同じサイズでない場合は、この 1 面のミラーには最も小さいサブミラーを使用します。さもなければ、データが失われる可能性があります。
- デバイスの再初期化を防止するため、RAID5 メタデバイスを -k オプションで再作成します (このオプションの詳細は、metainit(1M) のマニュアルページを参照してください)。

metainit(1M) コマンドを実行して、md.tab ファイルのエントリの構文をチェックする。
# metainit -n -a

md.tab ファイルのエントリの構文が正しいことを確認してから、 metainit(1M) コマンドを実行して、md.tab ファイルからホットスペア集合とメタデバイスを再作成する。
# metainit -a

metattach(1M) コマンドを実行して、1 面のミラーを多面のミラーとする。

メタデバイス上のデータの妥当性をチェックする。

DiskSuite のデフォルトの変更

DiskSuite 設定のデフォルトでは、1034 ブロックのサイズをもつ 128 個のメタデバイスと状態データベースの複製があります。ディスクセットのデフォルト数は 4 です。必要ならば、これらの値はすべて変更可能です。この節ではそのための作業を説明します。

メタデバイスの予備情報

システムに対するメタデバイスのデフォルト数は 128 です。最大 1024 までこの値を増やすことができます。
多数のメタデバイスを追加する場合、(DiskSuite ツールやコマンド行ユーティリティを使用して) メタデバイスを管理するときに、システムパフォーマンスが若干低下し始めることがあります。多数のメタデバイスがあっても、通常のシステム操作には影響を与えません。
メタデバイスの数を増やして、一定の数値範囲内でデバイスタイプをパーティション分割するための大きな名前空間を獲得しても、作成したデバイスの数が 128 未満である場合、パフォーマンスの低下は発生しません。この場合、状態データベースの複製をさらに追加する必要はありません。

デフォルトのメタデバイス数を増やす方法 (コマンド行)

この作業では、メタデバイスの数をデフォルト値の 128 から増やす方法について説明します。

注意 -

デバイスの数を減らした場合、元の数と新しい数の間に存在するメタデバイスは使用できなくなり、データが失われる可能性があります。「md: d20: not configurable, check /kernel/drv/md.conf」などのメッセージを受け取った場合、この作業で説明するように md.conf ファイルを編集する必要があります。

前提条件 (「システムのトラブルシューティングのための前提条件」) と予備情報 (「メタデバイスの予備情報」) をチェックしてから、/kernel/drv/mdoconf ファイルを編集する。

nmd フィールドの値を変更する。

1024 までの値を設定できます。

変更内容を保存する。

再構成するためにリブートを実行して、メタデバイス名を構築する。
# boot -r

例 - `md.conf` ファイル

次に、256 個のメタデバイス用に設定された md.conf ファイルの例を示します。

#
#ident "@(#)md.conf   1.7     94/04/04 SMI"
#
# Copyright (c) 1992, 1993, 1994 by Sun Microsystems, Inc.
#
name="md" parent="pseudo" nmd=256 md_nsets=4;

ディスクセットのための予備情報

システムに対するディスクセットのデフォルト数は 4 です。この値を 32 まで増やすことができます。md_nsets にはローカルセットが含まれるため、共有されるディスクセットの数は、常に md_nsets の値より 1 だけ小さな値です。

デフォルトディスクセットの数を増やす方法 (コマンド行)

この作業では、ディスクセットの数をデフォルト値の 4 から増やす方法について説明します。

注意 -

デバイスの数を減らした場合、元の数と新しい数の間に存在するディスクセットに影響がある可能性があります。

「システムのトラブルシューティングのための前提条件」の前提条件をチェックしてから、/kernel/drv/md.conf ファイルを編集する。

md_nsets フィールドの値を変更する。

32 までの値を設定できます。

変更内容を保存する。

再構成するためにリブートを実行して、メタデバイス名を構築する。
# boot -r

例 - `md.conf` ファイル

次に、5 つのディスクセット用に設定された md.conf ファイルの例を示します。md_nsets の値は 6 であり、5 つのディスクセットと 1 つのローカルディスクセットで構成されます。

#
#ident "@(#)md.conf   1.7     94/04/04 SMI"
#
# Copyright (c) 1992, 1993, 1994 by Sun Microsystems, Inc.
#
name="md" parent="pseudo" nmd=255 md_nsets=6;

状態データベースの複製のための予備情報

多数のメタデバイスを作成した場合、状態データベースの複製のサイズは相対的に小さくなり、必要な情報をすべて収めることができなくなります。この場合、 -l オプション付きの metadb(1M) コマンドを使用して、大きな状態データベースの複製の追加してから、小さな状態データベースの複製を除去します。
一般的に、デフォルトのメタデバイス数を 2 倍にしたら、状態データベースの複製のサイズも 2 倍にします。

大きな状態データベースの複製を追加する方法 (コマンド行)

前提条件 (「システムのトラブルシューティングのための前提条件」) をチェックして予備情報 (「状態データベースの複製のための予備情報」) を読んでから、metadb コマンドを使用して大きな状態データベースの複製を追加し、古い小さな状態データベースの複製を削除します。詳細は、metadb(1M) のマニュアルページを参照してください。

例 - 大きな状態データベースの複製の追加

# metadb -a -l 2068 c1t0d0s3 c1t1d0s3 c2t0d0s3 c2t1d0s3
# metadb -d c1t0d0s7 c1t1d0s7 c2t0d0s7 c2t1d0s7

最初の metadb コマンドでは、-l 2068 オプション (2068 ブロック) でサイズを指定された、状態データベースの複製を追加します。これは、デフォルトの複製サイズである 1034 ブロックの 2 倍です。2 番目の metadb コマンドでは、小さな状態データベースの複製をシステムから除去します。

エラーのチェック

DiskSuite に障害 (スライスレベルでの物理エラーによって、メタデバイスに書き込みできないなど) が発生すると、メタデバイスの状態を、たとえば「Maintenance (保守状態)」に変更します。しかし、DiskSuite ツールで継続的に調査していたり metastat(1M) を実行している場合を除き、このような状態変化をタイムリーに見ることはできません。

DiskSuite のエラーを自動的にチェックする方法が 2 つあります。

SNMP トラップを使用する (「SNMP 警告と DiskSuite の統合」を参照)
スクリプトを使用して、継続的にエラーをチェックする (DiskSuite エラーのチェックに使用できるスクリプトについては、次の節以降を参照)

メタデバイス内のスライスエラーのチェックを自動化する方法 (コマンド行)

メタデバイス内の不良スライスを連続して自動的にチェックする 1 つの方法は、cron によって呼び出されるスクリプトを記述する方法です。次にその例を示します。

#
#ident "@(#)metacheck.sh   1.3     96/06/21 SMI"
#
# Copyright (c) 1992, 1993, 1994, 1995, 1996 by Sun Microsystems, Inc.
#
 
#
# DiskSuite コマンド
#
MDBIN=/usr/sbin
METADB=${MDBIN}/metadb
METAHS=${MDBIN}/metahs
METASTAT=${MDBIN}/metastat
 
#
# システムコマンド
#
AWK=/usr/bin/awk
DATE=/usr/bin/date
MAILX=/usr/bin/mailx
RM=/usr/bin/rm
 
#
# 初期化
#
eval=0
date=`${DATE} '+%a %b %e %Y'`
SDSTMP=/tmp/sdscheck.${$}
${RM} -f ${SDSTMP}
 
MAILTO=${*:-"root"}			# default to root, or use arg list
 
#
# 複製の障害をチェック。フラグ内の大文字はエラーを示す。
#
dbtrouble=`${METADB} | tail +2 | ¥
    ${AWK} '{ fl = substr($0,1,20); if (fl ‾ /[A-Z]/) print $0 }'`
if [ "${dbtrouble}" ]; then
        echo ""   >>${SDSTMP}
        echo "SDS replica problem report for ${date}"	>>${SDSTMP}
        echo ""   >>${SDSTMP}
        echo "Database replicas are not active:"     >>${SDSTMP}
        echo ""   >>${SDSTMP}
        ${METADB} -i >>${SDSTMP}
        eval=1
fi
 
#
# メタデバイスの状態をチェック。状態が正常でない場合、何かが発生。
#
mdtrouble=`${METASTAT} | ¥
    ${AWK} '/State:/ { if ( $2 != "Okay" ) print $0 }'`
if [ "${mdtrouble}" ]; then
        echo ""  >>${SDSTMP}
        echo "SDS metadevice problem report for ${date}"  >>${SDSTMP}
        echo ""  >>${SDSTMP}
        echo "Metadevices are not Okay:"  >>${SDSTMP}
        echo ""  >>${SDSTMP}
        ${METASTAT} >>${SDSTMP}
        eval=1
fi
 
#
# ホットスペアが使用されているかどうかをチェック。
#
hstrouble=`${METAHS} -i | ¥
    ${AWK} ' /blocks/ { if ( $2 != "Available" ) print $0 }'`
if [ "${hstrouble}" ]; then
        echo ""  >>${SDSTMP}
        echo "SDS Hot spares in use  ${date}"  >>${SDSTMP}
        echo ""  >>${SDSTMP}
        echo "Hot spares in usage:"  >>${SDSTMP}
        echo ""  >>${SDSTMP}
        ${METAHS} -i >>${SDSTMP}
        eval=1
fi
#
# 何かのエラーが発生した場合、ルート、またはコマンド行で指定された相手に
# レポートをメールする。
#
if [ ${eval} -ne 0 ]; then
        ${MAILX} -s "SDS problems ${date}" ${MAILTO} <${SDSTMP}
        ${RM} -f ${SDSTMP}
fi
 
exit ${eval}

このようにスクリプトを呼び出す方法については、cron(1M) のマニュアルページを参照してください。

注 -

このスクリプトは、DiskSuite のエラーチェックを自動化するための出発点として利用できます。このスクリプトは、使用する構成に合わせて変更する必要があります。

ブート障害

DiskSuite を使用すればルート (/)、swap、/usr をミラー化できるため、ハードウェアのエラーやオペレータのミスによって、システムのブート時に特殊な障害が発生することがあります。この節で説明する作業は、このような潜在的な障害に対する解決法です。

これらの障害と適切な解決法について表 7-1 に示します。

表 7-1 DiskSuite の一般的なブート障害


システムがブートしない理由	参照先
`/etc/vfstab` ファイルの情報に誤りがある。	「不適切な `/etc/vfstab` エントリからの回復方法 (コマンド行)」
状態データベースの複製が不足している。	「状態データベースの複製の不足からの回復方法 (コマンド行)」
ブートデバイス (ディスク) が故障した。	「ブートデバイス障害からの回復方法 (コマンド行)」
ブートミラーが故障した。	「SPARC: 代替デバイスからのブート方法 (コマンド行)」または「x86: 代替デバイスからのブート方法 (コマンド行)」

ブート障害のための予備情報

エラーにより、メタデバイスドライバがメタデバイスをオフラインにした場合は、障害の発生したディスク上のファイルシステムをすべてマウント解除します。各ディスクスライスは独立しているため、1 つのディスクに複数のファイルシステムがマウントされていることがあります。メタディスクドライバに障害が発生した場合は、同じディスク上の他のスライスにも、まもなく障害が発生する可能性があります。ディスクスライスに直接マウントされたファイルシステムには、メタディスクドライバのエラー処理という保護機能がないため、このようなファイルシステムをマウントしたままで放置すると、システムのクラッシュによってデータを失う危険性があります。

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

不適切な `/etc/vfstab` エントリからの回復方法 (コマンド行)

たとえば、ルート (/) をミラー化するときなど、/etc/vfstab ファイル内に誤ったエントリを作成した場合、システムは、最初は適切にブーティングしているように見えても、障害が発生します。このような場合、シングルユーザーモードで /etc/vfstab を編集する必要があります。

不適切な /etc/vfstab ファイルのエントリから回復するための手順を次に示します。

システムをシングルユーザーモードにブートする
ミラーメタデバイス上で fsck(1M) を実行する
ファイルシステムを読み書きモードで再マウントする
オプション : ルート (/) ミラー用の metaroot(1M) コマンドを実行する
/etc/vfstab ファイルがファイルシステムに記述されているメタデバイスを正しく参照することを確認する
リブートする

例 - ルート (/) ミラーの回復

次の例では、ルート (/) は 2 面のミラー d0 でミラー化されます。/etc/vfstab 内のルート (/) エントリは、どういうわけかファイルシステムの元のスライスに戻りました。しかし、/etc/system 内の情報は、まだミラー d0 からのブートを示しています。通常考えられる理由としては、/etc/system と /etc/vfstab の保守に metaroot(1M) コマンドが使用されなかったか、または /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       -
fd                -                  /dev/fd  fd       -     no       -
swap              -                  /tmp     tmpfs    -     yes      -

エラーのため、マシンがブートされると自動的にシングルユーザーモードとなります。

ok boot
...
SunOS Release 5.5 Version Generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1995, Sun Microsystems, Inc.
configuring network interfaces: le0.
Hostname: antero
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): <パスワードを入力>

この時点で、ルート (/) と /usr は読み取り専用でマウントされます。次の手順に従ってください。

ルート (/) ミラー上で fsck(1M) を実行する。

注 -

ルートには正しいメタデバイスを使用するよう注意してください。

# 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(1M) コマンドを実行する。
# metaroot d0
これは /etc/system と /etc/vfstab のファイルを編集して、ルート (/) ファイルシステムが現在メタデバイス d0 上にあることを指定します。

/etc/vfstab ファイルに正しいメタデバイスエントリが収められていることを確認する。

/etc/vfstab ファイル内のルート (/) エントリが次のようになっていると、ファイルシステムがミラーを正しく参照します。

#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      -
fd                -                  /dev/fd   fd      -      no      -
swap              -                  /tmp      tmpfs   -      yes     -

リブートする。

システムは通常の動作に復帰します。

状態データベースの複製の不足からの回復方法 (コマンド行)

たとえば、ドライブの障害など、何らかの理由によって状態データベースの複製が規定数に満たない場合、システムはリブートできません。DiskSuite の用語では、これを状態データベースが「無効」になったと表現します。ここでは、その回復方法について説明します。

この作業の手順を次に示します。

無効な状態データベースの複製を削除してリブートする
故障したディスクを修復する
状態データベースの複製を追加して戻す

例 - 無効な状態データベースの複製からの回復

次の例では、2 つの複製を含むディスクが不良となりました。システムには正常な複製が 2 つしか残されておらず、システムはリブートできません。

マシンをブートして、どの状態データベースの複製が障害を受けているのかを判定する。

ok boot
...
Hostname: demo
metainit: demo: 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 Ctrl-d to proceed with normal startup,
(or give root password for system maintenance): <パスワードを入力>
Entering System Maintenance Mode
 
SunOS Release 5.5 Version Generic [UNIX(R) System V Release 4.0]

metadb(1M) コマンドを使用してメタデバイスの状態データベースを調べ、状態データベースの複製のうち、使用できないものを判定する。

# metadb -i
   flags          first blk         block count
    a m  p  lu     16                1034             /dev/dsk/c0t3d0s3
    a    p  l      1050              1034             /dev/dsk/c0t3d0s3
    M    p         unknown           unknown          /dev/dsk/c1t2d0s3
    M    p         unknown           unknown          /dev/dsk/c1t2d0s3
...

システムは、障害の発生したディスクに含まれるスライス /dev/dsk/c1t2d0s3 上では、もう状態データベースの複製を検出できません。metadb コマンドは、このスライス上の複製に対して、マスターブロックに障害があるというフラグを立てます。

-d オプション付きの metadb(1M) コマンドを使用して、不良ディスク上の状態データベースの複製を削除する。

この時点では、ルート (/) ファイルシステムは読み取り専用である。mddb.cf のエラーメッセージは無視できる。
# metadb -d -f c1t2d0s3 metadb: demo: /etc/lvm/mddb.cf.new: Read-only file system

複製が削除されたことを確認する。

# metadb -i
   flags          first blk         block count
    a m  p  lu     16                1034             /dev/dsk/c0t3d0s3
    a    p  l      1050              1034             /dev/dsk/c0t3d0s3

リブートする。

交換用のディスクを用意できたらシステムを停止し、故障したディスクを交換し、もう一度システムをリブートする。format(1M) コマンドまたは fmthard(1M) コマンドを使用して、ディスクを故障の前と同じようにパーティション分割する。
# halt ... ok boot ... # format /dev/rdsk/c1t2d0s0 ...

metadb(1M) コマンドを使用して、状態データベースの複製を追加して戻し、状態データベースの複製が正常であることを確認する。

# metadb -a -c 2 c1t2d0s3
# metadb
   flags          first blk         block count
    a m  p  luo    16                1034             dev/dsk/c0t3d0s3
    a    p  luo    1050              1034             dev/dsk/c0t3d0s3
    a       u      16                1034             dev/dsk/c1t2d0s3
    a       u      1050              1034             dev/dsk/c1t2d0s3

-c 2 オプション付きの metadb コマンドは、同じスライスに状態データベースの複製を 2 つ追加します。

ブートデバイス障害からの回復方法 (コマンド行)

ルート (/) ミラーがあり、ブートデバイスが故障した場合、代わりのブートデバイスを設定する必要があります。

この作業での手順を次に示します。

代替ルート (/) サブミラーからのブート
エラーの発生した状態データベースの複製とメタデバイスの判定
故障ディスクの修復
メタデバイスの状態データベースとメタデバイスを元の状態に復元

例 - ブートデバイス障害からの回復

次の例では、6 つの状態データベースの複製のうち 2 つと、ルート (/)、swap、/usr の各サブミラーを含んだブートデバイスに障害が発生しました。

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

Rebooting with command:
Boot device: /iommu/sbus/dma@f,81000/esp@f,80000/sd@3,0   File and args: kadb
kadb: kernel/unix
The selected SCSI device is not responding
Can't open boot device
...

このメッセージが表示されたら、デバイスをメモしてから、次の手順に従います。

他のルート (/) サブミラーからブートする。

この例では、6 つの状態データベースの複製のうち、エラーであるのは 2 つだけなので、まだブートが可能です。そうでない場合、シングルユーザーモードで無効な状態データベースの複製を削除する必要があります。この作業については、「状態データベースの複製の不足からの回復方法 (コマンド行)」を参照してください。

ルート (/) ファイルシステム用のミラーを作成する場合、その作業の一部として、代替ブートデバイスを記録する必要があります。この例では、disk2 がその代替ブートデバイスです。

ok boot disk2
...
SunOS Release 5.5 Version Generic [UNIX(R) System V Release 4.0]
Copyright (c) 1983-1995, Sun Microsystems, Inc.
 
Hostname: demo
...
demo console login: root
Password: <パスワードを入力>
Last login: Wed Dec 16 13:15:42 on console
SunOS Release 5.1 Version Generic [UNIX(R) System V Release 4.0]
...

metadb(1M) コマンドを使用して、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(1M) コマンドを使用して、ルート (/)、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

この例では、metastat は、次のサブミラーに保守が必要なことを示します。

サブミラー d10、デバイス c0t3d0s0
サブミラー d11、デバイス c0t3d0s1
サブミラー d12、デバイス c0t3d0s6

システムを停止し、ディスクを修復し、format(1M) コマンドまたは fmthard(1M) コマンドを使用して、ディスクを障害を受ける前と同じようにパーティション分割する。
# halt ... Halted ... ok boot ... # format /dev/rdsk/c0t3d0s0

リブートする。

なお、ルート (/) ミラーの残った片方からリブートしなければなりません。ミラーを作成する際に、代替ブートデバイスを記録しておいてください。
# halt ... ok boot disk2

metadb(1M) コマンドを使用し、故障した状態データベースの複製を削除してから、追加して戻す。

# 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(1M) コマンドを使用して、サブミラーを再び有効にする。

# 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

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

代替ブートデバイスへのパスを記録する方法 (コマンド行)

ルート (/) をミラー化するとき、後で一次デバイスが障害を受けた場合に、代替ブートデバイスへのパスが必要になることがあります。

例 - SPARC: 代替ブートデバイスパスの記録

この例では、ルート (/) ミラーに 2 番目のサブミラーとして接続されているスライス上で ls -l コマンドを使用することによって、代替ブートデバイスへのパスを調べます。

# ls -l /dev/rdsk/c1t3d0s0
lrwxrwxrwx 1  root root  55 Mar 5 12:54  /dev/rdsk/c1t3d0s0 -> ../.
./devices/sbus@1,f8000000/esp@1,200000/sd@3,0:a

ここでは、/devices ディレクトリに続く文字列を記録します。 /sbus@1,f8000000/esp@1,200000/sd@3,0:a

一部の新しい Sun ハードウェアでは、/devices ディレクトリ名を sd@ から disk@ に変更する必要があります。

OpenBoot PROM 付きのシステムを使用している DiskSuite ユーザーは、OpenBoot の nvalias コマンドを使用して、二次ルートミラー用の「バックアップルート」デバイス別名を定義できます。たとえば、

ok  nvalias backup_root /sbus@1,f8000000/esp@1,200000/sd@3,0:a

一次ルートディスクに障害が発生した場合、次のように入力します。

ok  boot backup_root

例 - x86: 代替ブートデバイスパスの記録

この例では、ルート (/) ミラーに 2 番目のサブミラーとして接続されているスライス上で ls -l コマンドを使用することによって、代替ブートデバイスへのパスを調べます。

# ls -l /dev/rdsk/c1t0d0s0
lrwxrwxrwx 1  root root  55 Mar 5 12:54  /dev/rdsk/c1t0d0s0 -> ../.
./devices/eisa/eha@1000,0/cmdk@1,0:a

ここでは、/devices ディレクトリに続く文字列を記録します。 /eisa/eha@1000,0/cmdk@1,0:a

SPARC: 代替デバイスからのブート方法 (コマンド行)

代替ブートデバイスから SPARC システムをブートするには、次のように入力します。

# boot <代替ブートデバイス>

代替ブートデバイスの確認方法については、「代替ブートデバイスへのパスを記録する方法 (コマンド行)」を参照してください。

x86: 代替デバイスからのブート方法 (コマンド行)

この作業は、代替ブートデバイスから x86 システムをブートするために使用します。

マルチデバイスブート (MDB) フロッピーディスクからシステムをブートする。

しばらくすると、次のような画面が表示されます。

Solaris/x86 Multiple Device Boot Menu
Code    Device    Vendor     Model/Desc          Rev
============================================================
 
10      DISK      COMPAQ      C2244              0BC4
11      DISK      SEAGATE     ST11200N SUN1.05   8808
12      DISK      MAXTOR      LXT-213S SUN0207   4.24
13      CD        SONY        CD-ROM CDU-8812    3.0a
14      NET       SMC/WD      I/O=300 IRQ=5
80      DISK      First IDE drive (Drive C:)
81      DISK      Second IDE drive (Drive D:)
 
Enter the boot device code:

画面に表示された選択項目の中から、代替ディスクのコードを入力する。

次の画面が表示されます。

Solaris 2.4 for x86                Secondary Boot Subsystem,vsn 2.11
 
                  <<<Current Boot Parameters>>>
Boot path:/eisa/eha@1000,0/cmdk@0,0:a
Boot args:/kernel/unix
 
Type b[file-name] [boot-flags] <ENTER>     to boot with options
or   i<ENTER>                              to enter boot interpreter
or   <ENTER>                               to boot with defaults
 
                    <<<timeout in 5 seconds>>>

i を入力してインタプリタを選択する。

次のコマンドを入力する。
>setprop boot-path /eisa/eha@1000,0/cmdk@1,0:a >^D
Control-D を入力して、インタプリタを終了します。

SCSI ディスクの交換

この節では、DiskSuite 環境において SPARCstorage Array に含まれない SCSI ディスクの交換方法について説明します。

障害の発生した SCSI ディスクの交換方法 (コマンド行)

SPARCstorage Array に含まれていない SCSI ディスクを交換するための手順を次に示します。

交換の必要なディスクを特定
障害の発生したディスク上にあるメタデバイスの状態データベースの複製を削除
障害の発生したディスク上で「使用可能」とマークされたホットスペアの削除
障害の発生したディスク上のスライスを使用するサブミラーの探索と切断
システムを停止し、シングルユーザーモードへブート
ディスクを物理的に交換
新しいディスクのパーティション再分割
削除された、メタデバイスの状態データベースの複製を追加
障害の発生したスライスの使用方法に応じて、次のいずれかを実行

単純スライスの場合 : 通常の回復手順を使用

ストライプや連結の場合 : メタデバイス全体を newfs し、バックアップから復元

ミラーの場合 : 切断されたサブミラーを再接続 RAID5 メタデバイスの場合 : 影響を受けるスライスを再同期 (有効化)

トランスメタデバイスの場合 : fsck(1M) を実行
削除されたホットスペアをホットスペア集合に追加

/var/adm/messages と metastat の出力を調査することによって、交換すべきディスクを特定する。

障害の発生したディスクに置かれた可能性のある、ローカルメタデバイスの状態データベースの複製を探索する。

複製を見つけ出すには、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 つ以下になった場合、操作を継続する前に、状態データベースの複製を追加してください。これによって、システムが正しくリブートされます。

複製が存在するスライス名と複製の数を記録してから、状態データベースの複製を削除する。

複製の数を調べるには、手順 2 の metadb 出力におけるスライスの出現回数をカウントします。この例では、c0t1d0s4 上に存在する 3 つの状態データベースの複製が削除されます。
# metadb -d c0t1d0s4

障害の発生したディスク上のスライスを使用するサブミラーを探索して、切断する。

metastat コマンドは、影響を受けるミラーを表示できます。この例では、1 つのサブミラー d10 が c0t1d0s4 も使用しています。ミラーは d20 です。
# metadetach d20 d10 d20: submirror d10 is detached

障害の発生したディスク上のホットスペアを削除する。
# metahs -d hsp000 c0t1d0s6 hsp000: Hotspare is deleted

システムを停止し、シングルユーザーモードにブートする。
# halt ... ok boot -s ...

障害の発生したディスクを物理的に交換する。

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

format(1M) コマンドまたは fmthard(1M) コマンドを使用して、障害の発生したディスクと同じスライス情報でディスクをパーティションに分割します。

手順 3 で複製を削除した場合、適切なスライスに同じ数の複製を追加する。

この例では、/dev/dsk/c0t1d0s4 が使用されます。
# metadb -a c 3 c0t1d0s4

次の表を使用し、ディスクの使用法に応じて、次に行うべき操作を決定する。

表 7-2 SCSIディスク交換のための決定表


デバイスの種類	操作内容
スライス	通常のデータ回復手順を使用します。
ミラー化解除されたストライプや連結	ファイルシステムにストライプ / 連結が使用されている場合、`newfs`(1M) を実行し、ファイルシステムをマウントしてから、バックアップからデータを復元します。raw デバイスを使用するアプリケーションとしてストライプ / 連結が使用されている場合、そのアプリケーションには独自の回復手順が必要です。
ミラー (サブミラー)	`metattach`(1M) を実行して、切断されたサブミラーを再接続します。
RAID5 メタデバイス	`metareplace`(1M) を実行して、スライスを再び有効にします。これによって再同期が開始されます。
トランスメタデバイス	`fsck`(1M) を実行して、トランスメタデバイスを修復します。

削除されたホットスペアを交換し、適切なホットスペア集合に追加する。
# metahs -a hsp000 c0t0d0s6 hsp000: Hotspare is added

データの妥当性をチェックする。

すべてのメタデバイス上のユーザーデータとアプリケーションデータをチェックします。アプリケーションレベルの整合性チェック機能を実行したり、その他の方法でデータをチェックする必要があります。

SPARCstorage Array の操作

この節では、DiskSuite を使用して SPARCstorage Array (SSA) のトラブルシューティングを行う方法について説明します。この節には次のような作業があります。

ミラー内で障害の発生したディスクを交換
RAID5 メタデバイス内で障害の発生したディスクを交換
トレイを除去
トレイを交換
コントローラを交換
電源断からの回復

インストレーション

SPARCstorage Array は、SPARCstorage Array CD に添付の『SPARCstorage Array Software』マニュアルに従ってインストールします。DiskSuite だけを使用する場合は、SPARCstorage Array のボリューム管理機能をインストールする必要はありません。

デバイスの命名規則

DiskSuite は、SPARCstorage Array ディスクに対して、他のディスクと同じようにアクセスしますが、重要な例外が 1 つあります。つまり、非 SPARCstorage Array ディスクの場合とはディスク名が異なります。

SPARCstorage Array 100 ディスクの命名規則を次に示します。

c[0-n]t[0-5]d[0-4]s[0-7]

この名前では、

c は、SSA ユニットに接続されたコントローラを示す
t は、SSA 内部の 6 つの SCSI 列の 1 つを示す
d は、内部 SCSI 列上の 5 つのディスクの 1 つを示す
s は、ディスクのスライス番号を示す
t0 と t1 はトレイ 1 に含まれ、t2 と t3 はトレイ 2 に含まれ、t4 と t5 はトレイ 3 に含まれる

SPARCstorage Array 200 ディスクの命名規則を次に示します。

c[0-n]t[0-5]d[0-6]s[0-7]

この名前では、

c は、SSA ユニットに接続されたコントローラを示す
t は、SSA ユニット内部の 6 つのターゲット (トレイ) の 1 つを示す
d は、内部 SCSI 列上の 7 つのディスクの 1 つを示す
s は、ディスクスライス番号を示す

注 -

古いトレイでは 6 つまでのディスクを保持し、新しいトレイでは 7 つまで保持できます。

SSA100 と SSA200 との主な違いは、SSA100 では 1 つのトレイに 2 つのターゲットが配置されていますが、SSA200 ではターゲットごとに別のトレイが割り当てられているという点です。

SPARCstorage Array コンポーネントを交換するための予備情報

交換可能な SPARCstorage Array コンポーネントには、ディスク、ファントレイ、バッテリー、トレイ、電源装置、バックプレーン、コントローラ、光モジュール、ファイバチャネルケーブルがあります。

いくつかの SPARCstorage Array コンポーネントは、SPARCstorage Array の電源を切断することなく交換できますが、電源を切断する必要のあるコンポーネントもあります。詳細については、SPARCstorage Array のマニュアルを参照してください。

電源を切断する必要のある SPARCstorage Array コンポーネントを、サービスを中断せずに交換するには、電源を切断する前に SPARCstorage Array 内のすべてのトレイに対して、トレイの除去に必要な手順を実行します。これには、サブミラーをオフラインに設定、ホットスペアをホットスペア集合から削除、状態データベースの複製をドライブから削除、トレイの停止が含まれます。

これらの準備を行なってから、SPARCstorage Array の電源を切断し、コンポーネントを交換することができます。

注 -

SPARCstorage Array コントローラは、Solaris から特定される一意な World Wide Name を持っています。そのため、SPARCstorage Array コントローラの交換には特別な作業が適用されます。技術的な支援に関しては、ご購入先にご連絡ください。

ミラー内で障害の発生した SPARCstorage Array ディスクを交換する方法 (DiskSuite ツール)

DiskSuite 環境において SPARCstorage Array ディスクを交換する手順は、ディスク上のスライスの使用方法、およびディスクとシステムのケーブル接続方法によって大きく異なります。また、ディスクスライスがそのまま使用されるのか、DiskSuite によって使用されるのか、それともその両方なのかによっても異なります。

注 -

この作業は SPARCstorage Array 100 に適用されます。SPARCstorage Array 200 でディスクを交換するための手順もよく似ています。

この作業での手順を次に示します。

交換の必要なディスクを特定し、その位置を調査
取り出すべきトレイ内で「使用可能」とマークされたホットスペアを削除
取り出すべきトレイ内のディスク上にある状態データベースの複製を削除
取り出すべきトレイ内のディスクを使用するサブミラーを探索
交換中のディスク上にスライスをもつサブミラーを切断
トレイ内のディスクを使用する他のサブミラーをオフライン設定
トレイ内のディスクをすべて停止
トレイを除去してディスクを交換
トレイ内のディスクがすべて起動することを確認
新しいディスクをパーティションに再分割
トレイ内のサブミラーをオンラインに戻す
トレイ内の切断されたサブミラーを接続
削除されたホットスペアを交換
削除されたホットスペアをホットスペア集合に追加
削除されたメタデバイスの状態データベースの複製を追加

注 -

サブミラーが「保守」状態にある場合、ホットスペアによって交換された場合、またはときどきエラーが発生している場合には、この作業を使用できます。

ディスクを探索して交換するには、次の手順を実行します。

DiskSuite ツールを使用してオブジェクトの「状態」フィールドを調べるか、または metastat と /var/adm/messages の出力を調査することによって、交換するディスクを特定する。

# metastat
...
 d50:Submirror of d40
      State: Needs Maintenance
...
# tail -f /var/adm/messages
...
Jun 1 16:15:26 host1 unix: WARNING: /io-
unit@f,e1200000/sbi@0.0/SUNW,pln@a0000000,741022/ssd@3,4(ssd49):  
Jun 1 16:15:26 host1 unix: Error for command `write(I))' Err
Jun 1 16:15:27 host1 unix: or Level: Fatal
Jun 1 16:15:27 host1 unix: Requested Block 144004, Error Block: 715559
Jun 1 16:15:27 host1 unix: Sense Key: Media Error
Jun 1 16:15:27 host1 unix: Vendor `CONNER':
Jun 1 16:15:27 host1 unix: ASC=0x10(ID CRC or ECC error),ASCQ=0x0,FRU=0x15
...

metastat コマンドは、サブミラーが「Needs Maintenance」状態にあることを明らかにします。/var/adm/messages ファイルは、エラーのあるディスクドライブを通知します。ディスクドライブを探索するには、次のように ls コマンドを使用して、シンボリックリンクの名前と /var/adm/messages の出力からの名前を照合します。

# ls -l /dev/rdsk/*
...
lrwxrwxrwx   1 root     root          90 Mar  4 13:26 /dev/rdsk/c3t3d4s0 -
> ../../devices/io-
unit@f,e1200000/sbi@0.0/SUNW,pln@a0000000,741022/ssd@3,4(ssd49)
...

上の情報と metastat の出力にもとづいて、ドライブ c3t3d4 を交換しなければならないことが決まります。

DiskSuite ツールを使用して、影響を受けるトレイを判定する。

障害の発生したディスクが存在する SPARCstorage Array トレイを見つけるには、「ディスク表示」ウィンドウを使用します。

「ディスク表示」をクリックして、「ディスク表示」ウィンドウを表示する。

障害の発生したメタデバイス (この例は、ミラー) を、オブジェクトリストから「ディスク表示」ウィンドウにドラッグする。

「ディスク表示」ウィンドウでは、メタデバイスを構成する物理スライスに色を割り当てることによって、論理デバイスから物理デバイスへのマップを表示します。障害の発生したディスクを含むトレイは、一目で判断できます。

ssaadm(1M) コマンドを使用する。

host1# ssaadm display c3
         SPARCstorage Array Configuration
Controller path: /devices/io-
unit@f,e1200000/sbi@0.0/SUNW,soc@0,0/SUNW,pln@a0000000,741022:ctlr
         DEVICE STATUS
         TRAY1          TRAY2          TRAY3
Slot
1        Drive:0,0      Drive:2,0      Drive:4,0
2        Drive:0,1      Drive:2,1      Drive:4,1
3        Drive:0,2      Drive:2,2      Drive:4,2
4        Drive:0,3      Drive:2,3      Drive:4,3
5        Drive:0,4      Drive:2,4      Drive:4,4
6        Drive:1,0      Drive:3,0      Drive:5,0
7        Drive:1,1      Drive:3,1      Drive:5,1
8        Drive:1,2      Drive:3,2      Drive:5,2
9        Drive:1,3      Drive:3,3      Drive:5,3
10       Drive:1,4      Drive:3,4      Drive:5,4
 
         CONTROLLER STATUS
Vendor:    SUNW
Product ID:  SSA100
Product Rev: 1.0
Firmware Rev: 2.3
Serial Num: 000000741022
Accumulate performance Statistics: Enabled

コントローラ (c3) に対する ssaadm の出力によって、中央トレイを取り出すとき、Drive 3,4 (c3t3d4) が一番近い位置にあることがわかります。

[オプション] ディスクセットがある場合、影響を受けるドライブを含むディスクセットを探索する。

次のコマンドでは、ドライブ c3t3d4 を探索します。logicalhost2 でコマンドを実行したときには何の出力も表示されませんでしたが、logicalhost1 の場合は、名前が存在することが通知されたことに注目します。通知された出力の yes フィールドは、ディスクに状態データベースの複製が収められていることを示します。
host1# metaset -s logicalhost2 | grep c3t3d4 host1# metaset -s logicalhost1 | grep c3t3d4 c3t3d4 yes
注 -
Solstice HA サーバーを使用している場合、2 つの論理ホストの所有権を 1 つの Solstice HA サーバーに切り替える必要があります。詳細については、Solstice HA のマニュアルを参照してください。

影響を受けるトレイ上の他の DiskSuite オブジェクトを判定する。

ディスクを交換するにはトレイを取り出す必要があるため、このプロセスにおいて影響を受ける他のオブジェクトを確認します。
1. DiskSuite ツールで「ディスク表示」ウィンドウを表示する。トレイを選択し、「オブジェクト」メニューから「デバイスマップ」を選択する。
  
  「物理デバイスから論理デバイスへのマッピング」ウィンドウが表示されます。
2. ウィンドウに表示されるホットスペア、メタデバイス、状態データベースの複製など、影響を受けるオブジェクトをすべて記録する。

影響を受けるトレイに他の DiskSuite オブジェクトを作成することによって、ディスク交換の準備を行う。
1. 状態が「使用可能」であり、しかも障害の発生したディスクと同じトレイにあるホットスペアをすべて削除する。
  
  交換作業が終了したらホットスペアをホットスペア集合に追加して戻せるよう、ホットスペアについての情報をすべて記録します。
2. 取り出すべきトレイ内のディスク上にある状態データベースの複製を削除する。
  
  これらの複製は手順 14 で交換しなければならないため、この情報を記録しておいてください。同じディスク上に複数の複製がある場合もあります。各スライスから削除された複製の数を記録しておきます。
3. トレイ内に存在するスライスを使用しているサブミラーを探索する。
4. 交換中のディスク上のスライスをもつサブミラーをすべて切断する。
5. トレイ内にスライスをもつ他のサブミラーをすべてオフラインにする。
  
  これにより、DiskSuite はトレイ内のサブミラースライスの使用を停止するため、ドライブを停止できます。
  
  オブジェクトを除去するには、第 5 章「DiskSuite オブジェクトの除去」を参照してください。サブミラーを切断してオフラインにするには、「ミラーの操作」を参照してください。

SPARCstorage Array トレイ内のディスクをすべて停止する。

「ディスクの停止方法 (DiskSuite ツール)」を参照してください。

注 -
トレイ上の LED が点灯している間は、SPARCstorage Array トレイの除去を行うべきではありません。また、トレイが停止している間は、DiskSuite コマンドを実行しないでください。これを実行した場合、その副作用により、トレイ内のドライブの一部または全部が起動する可能性があります。

トレイを取り出し、不良ディスクを交換する。

ハードウェアの作業については、『SPARCstorage Array Model 100 Series Service Manual』および『SPARCcluster High Availability Server Service Manual』を参照してください。

SPARCstorage Array のトレイ内のディスクがすべて起動したことを確認する。

SPARCstorage Array トレイ内のディスクは、ハードウェアの交換作業に続いて、自動的に起動します。トレイが 2 分以内の自動起動に失敗した場合は、次のコマンドを使用してアクションを強制します。
# ssaadm start -t 2 c3

format(1M)、fmthard(1M)、またはストレージマネージャを使用して、新しいディスクをパーティションに再分割する。新しいディスクのパーティション分割は、交換されたディスクとまったく同じにする。

障害が発生する前に、ディスクフォーマット情報を保存することが望ましいです。

オフラインにされていたすべてのサブミラーを、オンラインに戻す。

「ミラーの操作」を参照してください。

サブミラーがオンラインに復帰すると、DiskSuite はすべてのサブミラーを自動的に再同期し、データを最新の状態にします。

切断されていたサブミラーを接続する。

「ミラーの操作」を参照してください。

手順 11 で接続されたサブミラー内で使用中のホットスペアを交換する。

サブミラーを切断前に、使用中のホットスペアを交換されたサブミラーがあった場合、このホットスペア交換は、サブミラーが再接続されてから有効となります。この手順によって、ホットスペアは「使用可能」状態に戻ります。

削除されたホットスペアをすべて追加する。

トレイ上のディスクから削除された状態データベースの複製をすべて追加する。

状態データベースの複製を交換するには、以前に保存した情報を使用します。

[オプション] Solstice HA サーバーを使用する場合、各論理ホストをそのデフォルトマスターに切り替える。

Solstice HA のマニュアルを参照してください。

データの妥当性をチェックする。

すべてのメタデバイスで、ユーザーデータとアプリケーションデータをチェックします。アプリケーションレベルの整合性チェック機能を実行したり、その他の方法でデータをチェックする必要があります。

RAID5 メタデバイス内で障害の発生した SPARCstorage Array ディスクを交換する方法 (DiskSuite ツール)

RAID5 メタデバイスをオンライン修復用に設定する場合、3 つの最小幅の RAID5 のスライスを使用する必要があります。これは RAID5 にとって最適の構成ではありませんが、冗長データのオーバヘッドという観点からは、ミラー化よりも若干負担の少ない方法です。各 RAID5 メタデバイスの 3 つのスライスは、それぞれ別のトレイに置いてください。SPARCstorage Array 内のすべてのディスクがこの方法で (または上述のミラーと組み合わせて) 構成された場合、どのデータに対するアクセスも失うことなく、障害の発生したディスクを含むトレイを除去できます。

注意 -

障害の発生したドライブを含むトレイ内の非複製ディスクを使用するアプリケーションは、最初に中断または終了してください。

「ミラー内で障害の発生した SPARCstorage Array ディスクを交換する方法 (DiskSuite ツール)」の手順 1 〜手順 9 を参照する。

これから障害の発生したディスクとトレイを探索し、影響を受ける他の DiskSuite オブジェクトを探索し、ディスクの交換準備を行なって、交換し、ドライブをパーティションに再分割します。

metareplace -e コマンドを使用して、トレイ内の新しいドライブを有効にする。

「ミラー内で障害の発生した SPARCstorage Array ディスクを交換する方法 (DiskSuite ツール)」の手順 12 〜手順 16 を参照する。

SPARCstorage Array トレイの除去方法 (コマンド行)

SPARCstorage Array トレイを除去する前に、すべての入出力を停止し、トレイ内のすべてのドライブを停止します。入出力要求が行われると、ドライブは自動的に起動します。したがって、ドライブを停止する前に、すべての入出力を停止することが必要です。

DiskSuite の入出力処理を停止する。

サブミラーをオフラインにする、metaoffline(1M) コマンドを参照します。トレイ上のサブミラーがオフラインにされると、ミラーは 3 面ミラーの場合を除いて、1 面ミラーだけで稼働します (つまり、データの冗長性が失われます)。サブミラーがオンラインに復帰すると、自動的に再同期が開始されます。

注 -
サブミラーを含むドライブを交換する場合、metadetach(1M) コマンドを使用して、サブミラーを切断します。

metastat(1M) コマンドを使用して、除去されるトレイ上のスライスを含むサブミラーをすべて特定する。また、metadb(1M) コマンドを使用して、トレイ上の複製を特定する。metahs(1M) コマンドを使用して、使用可能なホットスペアデバイスと対応するサブミラーも特定する必要がある。

影響を受けるサブミラーをすべてオフラインにした状態で、トレイへの入出力が停止されます。

「ディスクの停止方法 (DiskSuite ツール)」を参照する。

DiskSuite ツールか ssaadm コマンドを使用して、トレイを停止します。トレイのロックランプが消灯すると、そのトレイを除去して必要な作業を実行できます。

SPARCstorage Array トレイの交換方法

SPARCstorage Array トレイに関する作業が終了したら、シャーシ内のトレイを交換します。ディスクは自動的に起動します。

しかし、ディスクが起動に失敗した場合は、DiskSuite ツール (または ssaadm コマンド) を使用して、トレイ全体を手作業で起動することができます。SPARCstorage Array 内の起動ドライブ間には、若干の遅延 (数秒) があります。

ディスクが起動したら、オフラインに設定されていたサブミラーをすべてオンラインにする必要があります。サブミラーをオンラインにすると、最適化された再同期動作によって、サブミラーは自動的に最新の状態となります。最適化された再同期では、サブミラーがオフラインであったときに変更されたディスク領域だけがコピーされます。これは一般に、サブミラー容量全体のごく一部にすぎません。状態データベースの複製もすべて交換して、ホットスペアに追加することが必要です。

注 -

metaoffline ではなく、metadetach(1M) を使用してサブミラーを切断した場合、サブミラー全体を再同期しなければなりません。この場合、一般的にデータ 1G バイトあたりおよそ 10 分かかります。

SPARCstorage Array の電源断からの回復方法 (コマンド行)

1 つの SPARCstorage Array で電源断が発生した場合、次の現象が起こります。

DiskSuite オブジェクトに対して入出力操作を行うと、エラーが生成される。
エラーは、ドライブレベルではなく、スライスレベルで通知される。
ディスクに入出力操作が行われるまで、エラーは通知されない。
影響を受けたデバイスがホットスペアを割り当てた場合、ホットスペアアクティビティが開始されることがある。

「DiskSuite オブジェクトの状態チェック」で説明したように、metastat(1M) コマンドを使用して、これらのイベントの構成を監視しなければなりません。

電源が回復したら、次の操作を実行する必要があります。

エラーの発生したデバイスを metastat で特定する
エラーの発生したサブミラーや RAID5 メタデバイスを有効にする
影響を受けた状態データベースの複製を削除して再作成する

電源が回復したら、metastat コマンドを使用して、エラーの発生したデバイスを特定する。

# metastat
...
d10: Trans
    State: Okay
    Size: 11423440 blocks
    Master Device: d20
    Logging Device: d15
 
d20: Mirror
    Submirror 0: d30
      State: Needs maintenance
    Submirror 1: d40
      State: Okay
...
d30: Submirror of d20
    State: Needs maintenance
...

metareplace コマンドを使用して、エラーの発生したデバイスをサービスに復帰させる。
# metareplace -e <メタデバイス> <スライス>
-e オプションは、スライスの状態を「使用可能」状態に移行し、障害の発生したスライスを再同期します。

注 -
ホットスペアによって交換されたスライスは、metareplace コマンドを使用して一番最後に交換するデバイスにしてください。ホットスペアを最初に交換すると、これが使用可能になるとすぐに、サブミラー内の他のエラーの発生したスライスと交換されてしまうことがあります。

再同期は、一度にサブミラー (メタデバイス) の 1 つのスライスでしか実行できません。サブミラーのすべてのスライスが電源断による影響を受けた場合、各スライスを別個に交換しなければなりません。1.05G バイトのディスクでは、再同期の実行におよそ 10 分かかります。

サブミラーの数、およびこれらのサブミラーに含まれるスライスの数にもよりますが、再同期には相当な時間が必要なことがあります。1.05G バイトのドライブ 30 個で構成される 1 つのサブミラーでは、終了するのにおよそ 5 時間を要することがあります。5 つのスライスのサブミラーから構成されるような、通常使用される構成の場合は、終了するのにたった 50 分ですむ場合もあります。

電源断の後、影響を受けた SPARCstorage Array シャーシ上の状態データベースの複製は、すべてエラー状態となります。これらの複製は次のリブート時点で再生されますが、削除してから追加して戻せば、手動でサービスに復帰させることができます。
# metadb -d <スライス> # metadb -a <スライス>
注 -
各スライス上で削除された状態データベースの複製の数と同じ数だけ追加することが必要です。1 つの metadb コマンドで、複数の状態データベースの複製を削除できます。1 つの metadb -d で削除された複製を追加して戻すには、metadb -a を何回か呼び出さなければならないこともあります。その理由は、1 つのスライス上に複製のコピーが複数個必要な場合、-c フラグを使用する metadbを 1 回呼び出して追加しなければならないためです。詳細は、metadb(1M) のマニュアルページを参照してください。

状態データベースの複製の障害回復は自動的に実行されないため、SPARCstorage Array がサービスに復帰した直後に、障害回復を手動で実行するのが最も安全です。さもなければ、新しい障害が引き起こされて状態データベースの複製の大半がサービスを提供できなくなり、カーネルのパニックを引き起こすことがあります。使用できる状態データベースの複製の数が少なすぎる場合、このように DiskSuite が動作することがあります。

ホスト間で SPARCstorage Array ディスクを移動する方法 (コマンド行)

この作業では、DiskSuite オブジェクトを含むディスクを、ある SPARCstorage Array から別の SPARCstorage Array に移動する方法について説明します。

エラー状態のデバイス、または移動すべきディスク上のホットスペアによって交換されたデバイスを修復する。

metadb コマンドと metastat -p コマンドからの出力を使用して、移動すべきディスク上のホットスペア、メタデバイス、状態データベースの複製を特定する。

ディスクを新しいホストに物理的に移動する。その際、デバイス名が同じになるように、類似の方法で接続するよう注意する。

状態データベースの複製を再作成する。
# metadb -a [-f] <スライス> ...
手順 2 で特定された状態データベースの複製を含むスライス名と同じ名前を使用してください。-f オプションを使用して、状態データベースの複製を強制的に作成する場合もあります。

手順 2 の metastat -p コマンドからの出力を md.tab ファイルにコピーする。

md.tab ファイルを編集して、次の変更を行う。
- 移動しなかったメタデバイスを削除する。
- 古いメタデバイス名を新しい名前に変更する。
- 当分の間、任意のミラーを 1 面のミラーにし、最も小さなサブミラーを選択する (適切ならば)。

md.tab ファイルの構文をチェックする。
# metainit -a -n

移動したメタデバイスとホットスペア集合を再作成する。
# metainit -a

必要に応じて metattach(1M) コマンドを使用して、1 面ミラーを多面ミラーにする。

ブート時に自動的にマウントされるファイルシステムの /etc/vfstab ファイルを編集する。その後、必要に応じて、新しいメタデバイス上にファイルシステムを再マウントする。

SPARCstorage Array をシステムディスクとして使用

この節では、SPARCstorage Array をシステムディスク (ブートデバイス) として機能させる方法について説明します。

SPARCstorage Array をブート可能にする

SPARCstorage Array に関する最小限のブート条件を次に示します。

Solaris 2.5
ホストの SOC カードの Fcode のリビジョン：1.52 以降
SPARCstorage Array の Firmware のリビジョン：3.12 以降

Fcode のリビジョンを更新またはチェックするためには、SPARCstorage Array CD の専用サブディレクトリに提供される、fc_update プログラムを使用します。

詳細については、SPARCstorage Array のマニュアルを参照してください。

SPARCstorage Array ディスクをブートプロセスの初期段階で使用可能にする方法

SPARCstorage Array ディスクをブートプロセスの早い段階で使用可能にするには、次の forceload エントリを /etc/system ファイルに追加します。これは、SPARCstorage Array をシステムディスク (ブートデバイス) として機能させるために必要です。

*ident	"@(#)system	1.15	92/11/14 SMI" /* SVR4 1.5 */
*
* SYSTEM SPECIFICATION FILE
*
...
* forceload:
*
*  これらのモジュールは、最初の参照時ではなく、ブート時 (ルートファイル
*  システムをマウントする直前) にロードさせる。なお、forceload は、ディレ
*  クトリを含んだファイル名を要求する。また、モジュールをロードすること
*  は、必ずしもモジュールがインストールされることを意味しない。
*
forceload: drv/ssd
forceload: drv/pln
forceload: drv/soc
...

注 -

SPARCstorage Array ディスク上にルート (/) ミラーを作成する場合、metaroot(1M) コマンドを実行すると、上記のエントリが自動的に /etc/system ファイルに置かれます。

第 7 章 システムのトラブルシューティング

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

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

トラブルシューティングを行う時の注意

DiskSuite 設定の回復

md.cf ファイルを使用して DiskSuite 設定を回復する方法

DiskSuite のデフォルトの変更

メタデバイスの予備情報

デフォルトのメタデバイス数を増やす方法 (コマンド行)

例 - md.conf ファイル

ディスクセットのための予備情報

デフォルトディスクセットの数を増やす方法 (コマンド行)

例 - md.conf ファイル

状態データベースの複製のための予備情報

大きな状態データベースの複製を追加する方法 (コマンド行)

例 - 大きな状態データベースの複製の追加

エラーのチェック

メタデバイス内のスライスエラーのチェックを自動化する方法 (コマンド行)

ブート障害

ブート障害のための予備情報

不適切な /etc/vfstab エントリからの回復方法 (コマンド行)

例 - ルート (/) ミラーの回復

状態データベースの複製の不足からの回復方法 (コマンド行)

例 - 無効な状態データベースの複製からの回復

ブートデバイス障害からの回復方法 (コマンド行)

例 - ブートデバイス障害からの回復

代替ブートデバイスへのパスを記録する方法 (コマンド行)

例 - SPARC: 代替ブートデバイスパスの記録

例 - x86: 代替ブートデバイスパスの記録

SPARC: 代替デバイスからのブート方法 (コマンド行)

x86: 代替デバイスからのブート方法 (コマンド行)

SCSI ディスクの交換

障害の発生した SCSI ディスクの交換方法 (コマンド行)

SPARCstorage Array の操作

インストレーション

デバイスの命名規則

SPARCstorage Array コンポーネントを交換するための予備情報

ミラー内で障害の発生した SPARCstorage Array ディスクを交換する方法 (DiskSuite ツール)

RAID5 メタデバイス内で障害の発生した SPARCstorage Array ディスクを交換する方法 (DiskSuite ツール)

SPARCstorage Array トレイの除去方法 (コマンド行)

SPARCstorage Array トレイの交換方法

SPARCstorage Array の電源断からの回復方法 (コマンド行)

ホスト間で SPARCstorage Array ディスクを移動する方法 (コマンド行)

SPARCstorage Array をシステムディスクとして使用

SPARCstorage Array をブート可能にする

SPARCstorage Array ディスクをブートプロセスの初期段階で使用可能にする方法

第 7 章システムのトラブルシューティング

`md.cf` ファイルを使用して DiskSuite 設定を回復する方法

例 - `md.conf` ファイル

例 - `md.conf` ファイル

不適切な `/etc/vfstab` エントリからの回復方法 (コマンド行)