この章では、Solaris ボリュームマネージャの一般的な記憶領域管理に関連する保守作業について説明します。
この章の内容は次のとおりです。
次の表に、Solaris ボリュームマネージャの保守に必要な作業を示します。
作業 |
説明 |
参照先 |
---|---|---|
Solaris ボリュームマネージャ構成の表示 |
Solaris ボリュームマネージャの GUI か metastat コマンドを使ってシステム構成を表示します。 | |
ボリューム名の変更 |
Solaris ボリュームマネージャの GUI か metarename コマンドを使ってボリューム名を変更します。 | |
構成ファイルの作成 |
metastat -p コマンドと metadb コマンドを使って構成ファイルを作成します。 | |
構成ファイルを使用した Solaris ボリュームマネージャの初期化 |
metainit コマンドを使って構成ファイルから Solaris ボリュームマネージャを初期化します。 | |
使用できるボリューム数の変更 |
/kernel/drv/md.conf ファイルを編集して、使用できるボリューム数を増やします。 | |
使用できるディスクセット数の変更 |
/kernel/drv/md.conf ファイルを編集して、使用できるディスクセット数を増やします。 | |
ファイルシステムの拡張 |
growfs コマンドを使ってファイルシステムを拡張します。 | |
コンポーネントの有効化 |
Solaris ボリュームマネージャの GUI か metareplace コマンドを使ってコンポーネントを有効にします。 | |
コンポーネントの交換 (置き換え) |
Solaris ボリュームマネージャの GUI か metareplace コマンドを使ってコンポーネントを交換します。(置き換える) |
metastat の出力はソートされていません。 構成リストを編集したい場合は、metastat -p コマンドの出力を入力して sort または grep コマンドを実行してください。
次に、metastat コマンドの出力例を示します。
# metastat d50: RAID State: Okay Interlace: 32 blocks Size: 20985804 blocks Original device: Size: 20987680 blocks Device Start Block Dbase State Reloc Hot Spare c1t4d0s5 330 No Okay Yes c1t5d0s5 330 No Okay Yes c2t4d0s5 330 No Okay Yes c2t5d0s5 330 No Okay Yes c1t1d0s5 330 No Okay Yes c2t1d0s5 330 No Okay Yes d1: Concat/Stripe Size: 4197879 blocks Stripe 0: Device Start Block Dbase Reloc c1t2d0s3 0 No Yes d2: Concat/Stripe Size: 4197879 blocks Stripe 0: Device Start Block Dbase Reloc c2t2d0s3 0 No Yes d80: Soft Partition Device: d70 State: Okay Size: 2097152 blocks Extent Start Block Block count 0 1 2097152 d81: Soft Partition Device: d70 State: Okay Size: 2097152 blocks Extent Start Block Block count 0 2097154 2097152 d70: Mirror Submirror 0: d71 State: Okay Submirror 1: d72 State: Okay Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 12593637 blocks d71: Submirror of d70 State: Okay Size: 12593637 blocks Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t3d0s3 0 No Okay Yes Stripe 1: Device Start Block Dbase State Reloc Hot Spare c1t3d0s4 0 No Okay Yes Stripe 2: Device Start Block Dbase State Reloc Hot Spare c1t3d0s5 0 No Okay Yes d72: Submirror of d70 State: Okay Size: 12593637 blocks Stripe 0: Device Start Block Dbase State Reloc Hot Spare c2t3d0s3 0 No Okay Yes Stripe 1: Device Start Block Dbase State Reloc Hot Spare c2t3d0s4 0 No Okay Yes Stripe 2: Device Start Block Dbase State Reloc Hot Spare c2t3d0s5 0 No Okay Yes hsp010: is empty hsp014: 2 hot spares Device Status Length Reloc c1t2d0s1 Available 617652 blocks Yes c2t2d0s1 Available 617652 blocks Yes hsp050: 2 hot spares Device Status Length Reloc c1t2d0s5 Available 4197879 blocks Yes c2t2d0s5 Available 4197879 blocks Yes hsp070: 2 hot spares Device Status Length Reloc c1t2d0s4 Available 4197879 blocks Yes c2t2d0s4 Available 4197879 blocks Yes Device Relocation Information: Device Reloc Device ID c1t2d0 Yes id1,sd@SSEAGATE_ST39204LCSUN9.0G3BV0N1S200002103AF29 c2t2d0 Yes id1,sd@SSEAGATE_ST39204LCSUN9.0G3BV0P64Z00002105Q6J7 c1t1d0 Yes id1,sd@SSEAGATE_ST39204LCSUN9.0G3BV0N1EM00002104NP2J c2t1d0 Yes id1,sd@SSEAGATE_ST39204LCSUN9.0G3BV0N93J000071040L3S c0t0d0 Yes id1,dad@s53554e575f4154415f5f53543339313430412525415933 |
次に、大容量記憶ボリューム (11T バイト) に対する metastat コマンドの出力例を示します。
# metastat d0 d0: Concat/Stripe Size: 25074708480 blocks (11 TB) Stripe 0: (interlace: 32 blocks) Device Start Block Dbase Reloc c27t8d3s0 0 No Yes c4t7d0s0 12288 No Yes Stripe 1: (interlace: 32 blocks) Device Start Block Dbase Reloc c13t2d1s0 16384 No Yes c13t4d1s0 16384 No Yes c13t6d1s0 16384 No Yes c13t8d1s0 16384 No Yes c16t3d0s0 16384 No Yes c16t5d0s0 16384 No Yes c16t7d0s0 16384 No Yes c20t4d1s0 16384 No Yes c20t6d1s0 16384 No Yes c20t8d1s0 16384 No Yes c9t1d0s0 16384 No Yes c9t3d0s0 16384 No Yes c9t5d0s0 16384 No Yes c9t7d0s0 16384 No Yes Stripe 2: (interlace: 32 blocks) Device Start Block Dbase Reloc c27t8d2s0 16384 No Yes c4t7d1s0 16384 No Yes Stripe 3: (interlace: 32 blocks) Device Start Block Dbase Reloc c10t7d0s0 32768 No Yes c11t5d0s0 32768 No Yes c12t2d1s0 32768 No Yes c14t1d0s0 32768 No Yes c15t8d1s0 32768 No Yes c17t3d0s0 32768 No Yes c18t6d1s0 32768 No Yes c19t4d1s0 32768 No Yes c1t5d0s0 32768 No Yes c2t6d1s0 32768 No Yes c3t4d1s0 32768 No Yes c5t2d1s0 32768 No Yes c6t1d0s0 32768 No Yes c8t3d0s0 32768 No Yes |
詳細は、metastat(1M) のマニュアルページを参照してください。
metarename コマンドに -x オプションを指定することによって、親子関係のあるボリュームの名前を交換できます。 詳細は、「ボリューム名を変更するには」と metarename(1M) のマニュアルページを参照してください。
Solaris ボリュームマネージャでは、多少の制約はありますが、ほとんどのタイプのボリューム名をいつでも変更できます。
ボリューム名の変更や交換は、ボリューム名を管理する上で便利な機能です。 たとえば、ファイルシステムのすべてのマウントポイントをある範囲の数値内に収めることができます。 あるいは、論理ボリュームの命名規則に従ってボリューム名を変更したり、トランザクションボリュームの名前にそのボリュームを構成しているボリュームが使用している名前と同じものを使用することができます。
ボリューム名を変更するときは、ボリュームが使用中でないことを確認してください。 ファイルシステムとして使用されている場合は、マウントされていたり、swap として使用されていないことを確認してください。 データベースなど、raw デバイスを使用するその他のアプリケーションは、独自の方法でデータへのアクセスを停止できる必要があります。
ボリューム名の変更に伴う特別な考慮事項は、次のとおりです。
次のものを除く任意のボリュームの名前を変更できます。
ソフトパーティション
ソフトパーティションが直接作成されているボリューム
ログデバイスとして使用されているボリューム
ホットスペア集合
ディスクセット内のボリュームの名前は変更できます。 しかし、そのボリュームは別のディスクセットには移動できません。
ボリューム名の変更は、Solaris 管理コンソール内の「拡張ストレージ」かコマンド行 (metarename(1M) コマンド) から行うことができます。
metarename コマンドの -x オプションを使用すれば、ボリュームの名前とそのボリュームを構成するデバイスの名前を交換できます。 たとえば、この交換は、ミラーとそのサブミラーの間や、トランザクションボリュームとそのマスターデバイスの間で行うことができます。
ボリューム名の交換には、コマンド行を使用する必要があります。 この機能は、現在のところ Solaris ボリュームマネージャの GUI にはありません。 ただし、ボリューム名の変更はコマンド行からでも GUI からでも行えます。
metarename -x コマンドを使用すれば、既存ボリュームを簡単にミラー化したりミラー解除したりできます。あるいは、既存ボリュームからトランザクションボリュームを簡単に作成したり削除したりできます。
使用されているボリュームの名前は変更できません。 このタイプのボリュームの例としては、マウントされているファイルシステム、 swap として使用されているボリューム、アプリケーションやデータベースのアクティブ記憶領域として使用されているボリュームなどが挙げられます。 したがって、metarename コマンドを使用する前に、名前を変更するボリュームへのすべてのアクセスを停止する必要があります。 たとえば、マウントされているファイルシステムのマウントを解除します。
障害のあるボリュームや、ホットスペアが使用されているボリュームを交換することはできません。
交換するボリュームは、親子関係のあるものでなければなりません。 たとえば、マスターデバイスであるミラー内のストライプと、トランザクションボリュームを直接交換することはできません。
トランザクションデバイスのメンバー間で交換を行う場合は、-f (強制) フラグを使用する必要があります。
ロギングデバイスの交換 (または名前の変更) を行うことはできません。 交換が必要な場合は、ロギングデバイスを切断し、名前を変更してから、トランザクションデータベースに再び接続します。あるいは、ロギングデバイスを切断してから、適切な名前をもつ別のロギングデバイスを接続します。
Solaris ボリュームマネージャのトランザクションボリュームは大容量ボリュームをサポートしません。 どのような場合でも、UFS ロギング (mount_ufs(1M) を参照) はトランザクションボリュームよりも高い性能を示します。
ボリューム名の要件 (「ボリューム名」) と 「ボリューム名を変更するための背景情報」を確認します。
このボリュームを使用するファイルシステムのマウントを解除します。
次のどちらかの方法でボリューム名を変更します。
Solaris 管理コンソール内の「拡張ストレージ」から「ボリューム (Volumes)」ノードを開き、名前を変更するボリュームを選択します。 そのアイコンを右クリックし、「プロパティ (Properties)」オプションを選択して、画面の指示に従います。 詳細は、オンラインヘルプを参照してください。
次の形式の metarename コマンドを実行します。
metarename old-volume-name new-volume-name |
old-volume-name は既存のボリュームの名前です。
new-volume-name は既存のボリュームに指定する新しい名前です。
詳細は、metarename(1M) のマニュアルページを参照してください。
必要であれば、エントリが新しいボリューム名を参照するように /etc/vfstab ファイルを編集します。
ファイルシステムを再びマウントします。
# umount /home # metarename d10 d100 d10: has been renamed to d100 (ファイルシステムが新しいボリュームを参照するように /etc/vfstab ファイルを編集する) # mount /home |
この例では、ボリュームの名前 d10 を d100 に変更します。 d10 にはマウントされているファイルシステムが格納されているため、ボリューム名を変更するためには、このファイルシステムのマウントを解除する必要があります。 このファイルシステムのエントリが /etc/vfstab ファイル内に存在している場合は、そのエントリが新しいボリューム名を参照するように変更します。 たとえば、次の行を見てください。
/dev/md/dsk/d10 /dev/md/rdsk/d10 /docs ufs 2 yes - |
上記の行を次のように変更します。
/dev/md/dsk/d100 /dev/md/rdsk/d100 /docs ufs 2 yes - |
既存のミラーやトランザクションボリュームが存在する場合、metarename -x コマンドでミラーやトランザクションボリュームを削除しても、そのボリュームを構成するボリュームのデータは保持できます。 たとえば、トランザクションボリュームの場合には、マスターデバイスが ボリューム (RAID 0、RAID 1、または RAID 5 ボリューム) である限り、そのボリュームのデータは保持されます。
Solaris ボリュームマネージャの構成ファイルには、Solaris ボリュームマネージャの基本情報の他に、構成を再設定するのに必要なほとんどのデータが含まれています。 次の各項では、構成ファイルに関連する作業について説明します。
Solaris ボリュームマネージャ環境用のすべてのパラメータを適切に設定したら、metastat -p コマンドで /etc/lvm/md.tab ファイルを作成します。
# metastat -p > /etc/lvm/md.tab |
このファイルには、metainit や metahs コマンドで使用するすべてのパラメータが記述されています。このファイルは、類似した複数の環境を設定したり、障害発生時に構成を再作成するときに使用されます。
md.tab ファイルの詳細については、「md.tab ファイルの概要 」を参照してください。
この手順は、Solaris ボリュームマネージャの構成が完全に失われた場合、あるいは、保存されている構成ファイルから新たな構成を作成する場合だけに使用してください。
状態データベースに保持されていた情報が失われた場合 (たとえば、すべての状態データベースの複製が削除された後にシステムを再起動した) でも、md.cf または md.tab ファイルを使って Solaris ボリュームマネージャ構成を復元できます。ただし、状態データベースが失われた後にボリュームがまったく作成されていない場合に限ります。
md.cf ファイルには、アクティブなホットスペアの情報は格納されません。 そのため、Solaris ボリュームマネージャ構成が失われたときにホットスペアが使用されていると、アクティブなホットスペアを使用していたボリュームの内容は破壊されていることがあります。
これらのファイルの詳細については、md.cf(4)とmd.tab(4) のマニュアルページを参照してください。
状態データベースの複製を作成します。
詳細は、「状態データベースの複製の作成 」を参照してください。
/etc/lvm/md.tab ファイルを作成または更新します。
Solaris ボリュームマネージャ構成最後の状態を回復する場合は、md.cf ファイルを md.tab ファイルにコピーします。
保存されている md.tab ファイルのコピーを使って新しい Solaris ボリュームマネージャ構成を作成する場合は、このコピーを /etc/lvm/md.tab に置きます。
「新しい」md.tab ファイルを編集してから次の作業を行います。
新しい構成を作成している場合や、クラッシュの後で構成を回復している場合には、ミラーを 1 面ミラーとして構成します。 ミラーの各サブミラーのサイズが同じでない場合は、もっとも小さいサブミラーをこの 1 面ミラーのために使用する必要があります。 そうしないと、データを失うおそれがあります。
既存の構成を回復している場合、Solaris ボリュームマネージャが正常に終了しているのであれば、ミラー構成を多面ミラーのままにして回復します。
RAID 5 ボリュームの場合は、デバイスの再初期化を防止するために -k オプションを指定します。 詳細は、metainit(1M) のマニュアルページを参照してください。
次の形式の metainit コマンドを使って、md.tab ファイルのエントリの構文だけをチェックします (実際の処理は行われない)。
# metainit -n -a component-name |
metainit コマンドに -n オプションを付けて実行した場合、同じ実行中にすでに仮想的に作成されているデバイスを記憶しません。このため、md.tab 内に記述された別のボリュームに依存するボリュームを作成しようとすると、-n オプションを指定しなければ正常に実行される場合でも -n オプションを指定するとエラーになることがあります。
-n は、デバイスを実際には作成しないことを意味します。 このオプションでは、期待どおりの結果が得られるかどうかだけを確認します。
-a は、デバイスをアクティブにすることを意味します。
component-name は、初期化するコンポーネントの名前です。 コンポーネントを指定しないと、すべてのコンポーネントが作成されます。
前の手順で特に問題がなければ、md.tab ファイルを使ってボリュームとホットスペア集合を作成し直します。
# metainit -a component-name |
-a は、デバイスをアクティブにすることを意味します。
component-name は、初期化するコンポーネントの名前です。 コンポーネントを指定しないと、すべてのコンポーネントが作成されます。
ボリューム上のデータが正しいこと確認します。
Solaris ボリュームマネージャ構成では、次のデフォルト値が使用されています。
ディスクセット当たり 128 個のボリューム
ボリュームが利用できる名前空間として、d0 から d127 まで
4 つのディスクセット
状態データベースの複製の最大サイズは 8192 ブロック
ボリュームの合計、名前空間、およびディスクセットの数のデフォルト値は、必要に報じて変更できます。 この節では、これらの値を変更する作業について説明します。
/kernel/drv/md.conf ファイルの nmd フィールドは、使用できるボリューム数と、ボリュームが利用できる名前空間を割り当てます。 この作業では、デフォルトのボリューム数である 128 と、名前空間の デフォルトの範囲である d0 から d127 までを増やす方法について説明します。 デフォルト値より大きなボリューム数を構成する必要がある場合、この値は 8192 まで増やすことができます。
この数を減らした場合、前の数と新しい数の間にあるボリュームは使用不能になり、データを失うおそれがあります。 「md: d200: not configurable, check /kernel/drv/md.conf」というメッセージが表示された場合は、md.conf ファイルを編集し、この手順に従ってボリュームの数を増やす必要があります。
「障害追跡の前提条件」を確認します。
ボリューム数として 256 が設定されている md.conf ファイルの例を以下に示します。
# #ident "@(#)md.conf 1.7 94/04/04 SMI" # # Copyright (c) 1992, 1993, 1994 by Sun Microsystems, Inc. # # #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=256 md_nsets=4; |
この手順では、デフォルトのディスクセット数 4 を増やします。
ディスクセットがすでに設定されている場合は、デフォルトのディスクセット数を減らさないでください。 この数を減らすと、既存のディスクセットが使用不能になるおそれがあります。
「障害追跡の前提条件」を確認します。
/kernel/drv/md.conf ファイルを編集します。
md_nsets フィールドの値を変更します。 設定できる最大数は 32 です。
変更を保存します。
再構成のために再起動を行なってボリューム名を作成します。
# reboot -- -r |
5 つの共有ディスクセットを使用できるように設定されている md.conf ファイルの例を以下に示します。 md_nsets の値が 6 であるため、5 つの共有ディスクセットと 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=6; # Begin MDD database info (do not edit) ... # End MDD database info (do not edit) |
ファイルシステムが格納されているボリュームを拡張 (領域を追加) したときに、そのボリュームに UFS が格納されている場合は、ファイルシステムを拡張して新しい領域が認識されるようにする必要があります。 ファイルシステムの拡張は、growfs コマンドを使って手動で行う必要があります。 growfs コマンドは、マウントされているファイルシステムも拡張できます。 ただし、growfs コマンドの実行中は、ファイルシステムに書き込みアクセスを行うことはできません。
データベースなど、raw デバイスを使用するアプリケーションは、独自の方法で領域を拡張できなければなりません。 Solaris ボリュームマネージャには、この機能はありません。
growfs コマンドは、ファイルシステムを拡張する間、マウントされているファイルシステムを「書き込みロック」します。 ファイルシステムが書き込みロックされている時間を短縮する必要がある場合は、ファイルシステムを段階的に拡張できます。 たとえば、1G バイトのファイルシステムを 2G バイトに拡張する場合は、-s オプションを使って新しいファイルシステムの合計サイズを拡張処理の各段階で指定することによって、ファイルシステムを 16M バイト単位で拡張できます。
拡張処理の間はファイルシステムが書き込みロックされるため、このファイルシステムへの書き込みは実行できません。 書き込みアクセスは growfs コマンドがファイルシステムのロックを解除するまで自動的に中断され、ロックが解除されると再開されます。 読み取りアクセスには影響はありませんが、ロックが行われている間の読み取りアクセス時間は保証されません。
Solaris ボリュームマネージャのボリュームは拡張することはできますが、縮小することはできません。
ボリュームは、ファイルシステム、アプリケーション、データベースのいずれで使用されていても拡張できます。 RAID 0 (ストライプ方式と連結方式) ボリューム RAID 1 (ミラー) ボリューム、RAID 5 ボリュームだけでなく、ソフトパーティションも拡張できます。
ファイルシステムが格納されているボリュームを連結できます。 ファイルシステムが UFS であれば、growfs コマンドを使って、このファイルシステムを、拡張された領域まで拡張できます。このとき、データへの読み取りアクセスは中断されません。
いったん拡張されたファイルシステムは、UFS の制約により、縮小することはできません。
raw デバイスを使用するアプリケーションやデータベースは、独自の方法で領域を拡張し、それを認識できなければなりません。 Solaris ボリュームマネージャには、この機能はありません。
RAID 5 ボリュームにコンポーネントを追加すると、コンポーネントはデバイスへの連結になります。 新しいボリュームにはパリティ情報は格納されませんが、 このコンポーネントのデータは、ボリュームに対して行われる全体的なパリティ計算によって保護されます。
コンポーネントを追加することによって、ログデバイスを拡張できます。 再起動時に Solaris ボリュームマネージャは新しい領域を自動的に認識するため、growfs コマンドを実行する必要はありません。
ソフトパーティションを拡張するには、そのパーティションを構成するボリュームまたはスライスから領域を追加します。 その他のボリュームはすべて、スライスを追加することによって拡張できます。
growfs コマンドを使ってローカルボリュームの UFS を拡張します。
# growfs -M /mount-point /dev/md/rdsk/volumename |
詳細は、次の例と growfs(1M) のマニュアルページを参照してください。
# df -k Filesystem kbytes used avail capacity Mounted on ... /dev/md/dsk/d10 69047 65426 0 100% /home2 ... # growfs -M /home2 /dev/md/rdsk/d10 /dev/md/rdsk/d10: 295200 sectors in 240 cylinders of 15 tracks, 82 sectors 144.1MB in 15 cyl groups (16 c/g, 9.61MB/g, 4608 i/g) super-block backups (for fsck -F ufs -o b=#) at: 32, 19808, 39584, 59360, 79136, 98912, 118688, 138464, 158240, 178016, 197792, 217568, 237344, 257120, 276896, # df -k Filesystem kbytes used avail capacity Mounted on ... /dev/md/dsk/d10 138703 65426 59407 53% /home2 ... |
この例では、新しいスライスがボリューム d10 にすでに追加されています。このボリュームには、マウントされているファイルシステム /home2 があります。 growfs コマンドでは、-M オプションを使ってマウントポイントに /home2 を指定し、これを raw ボリューム /dev/md/rdsk/d10 上に拡張します。 growfs コマンドが終了すると、このファイルシステムはボリューム全体を占めます。 拡張の前後で df -hk コマンドを使用すれば、全体のディスク容量を確認できます。
ミラーやトランザクションボリュームの場合は、サブミラーやマスターデバイスに領域を追加する場合でも、必ずトップレベルのボリューム (サブミラーやマスターデバイスではなく) に対して growfs コマンドを実行する必要があります。
Solaris ボリュームマネージャには、RAID 1 (ミラー) ボリュームおよび RAID 5 ボリューム内のコンポーネントを交換したり有効にしたりする機能があります。
Solaris ボリュームマネージャでは、コンポーネントの交換は、サブミラーまたは RAID 5 ボリューム内のコンポーネントをシステム上で使用可能な他のコンポーネントと交換することを意味します。 このプロセスは、コンポーネントの物理的な交換ではなく論理的な交換です。 「コンポーネントを他の使用可能なコンポーネントで置き換える」を参照してください。
コンポーネントの有効化とは、コンポーネントをアクティブにする (または、コンポーネントをそれ自身で置き換える) ことを意味します。したがって、コンポーネント名は変わりません。 「コンポーネントの有効化」を参照してください。
ディスクエラーから回復するときは、 /var/adm/messages を調べ、どのような種類のエラーが発生したかを確認してください。 エラーが一時的なものであり、ディスク自体に問題がない場合は、コンポーネントを有効にしてみます。 また、format コマンドを使ってディスクをテストすることもできます。
コンポーネントを有効にする必要があるのは次のような場合です。
Solaris ボリュームマネージャが物理ディスクにアクセスできない場合。 この問題は、たとえば、電源が切断されていたり、ドライブケーブルが外れていることが原因で発生します。 この場合、Solaris ボリュームマネージャは、コンポーネントを「保守 (Maintenance)」状態に変更します。 この場合には、電源を復旧したり、ケーブルを接続し直したりしてドライブを使用可能にしてから、ボリュームのコンポーネントを有効にする必要があります。
物理ディスクに、ディスクに関連しない一時的な障害があると考えられる場合。 コンポーネントが「保守 (Maintenance)」状態であれば、そのコンポーネントを有効にするだけでコンポーネントを修復できる場合があります。 これで問題が解決しない場合は、ディスクドライブを物理的に交換してからそのコンポーネントを有効にするか、システム上の他の使用可能なコンポーネントでそのコンポーネントを置き換える必要があります。
ドライブを物理的に置き換える場合は、新しいドライブを前のものと同じようにパーティション分割し、各コンポーネント上に十分な領域を確保する必要があります。
交換対象のドライブ上に状態データベースの複製やホットスペアがないか必ずチェックしてください。 状態データベースの複製がエラー状態になっている場合は、ディスクを交換する前にその複製を削除し、 交換後にコンポーネントを有効にしてから同じサイズで作成し直す必要があります。 ホットスペアについても同じように処理してください。
既存のコンポーネントを他の未使用のコンポーネントで置き換える (または交換する) には、metareplace コマンドを使用します。
このコマンドを使用できるのは、次のような場合です。
ディスクドライブに障害があり、代わりになるドライブはないが、システム上に使用可能なコンポーネントが他にある場合。
どうしても交換する必要があるが、システムを停止したくない場合には、この方法を使用します。
ソフトエラーが発生した場合。
Solaris ボリュームマネージャではミラー/サブミラーや RAID 5 ボリュームが「正常 (Okay)」であっても、物理ディスクがソフトエラーを報告することがあります。 問題のコンポーネントを他の使用可能なコンポーネントで置き換えると、ハードウェアエラーの発生を防止するための予防的保守を実行できます。
性能の調整を行いたい場合。
たとえば、Solaris 管理コンソール内の「拡張ストレージ」の性能監視機能を使用すれば、RAID 5 ボリュームの特定のコンポーネントが「正常 (Okay)」状態であっても、平均して高い負荷を処理していることがわかります。 その場合には、ボリュームの負荷を均一化するために、このコンポーネントを、これより使用率の低いディスクのコンポーネントで置き換えることができます。 このような処理は、ボリュームへのサービスを中断せずにオンラインで行うことができます。
ミラーや RAID 5 ボリュームのコンポーネントにエラーが発生すると、Solaris ボリュームマネージャはそのコンポーネントを「保守 (Maintenance)」状態にします。 これ以降、「保守 (Maintenance)」状態のコンポーネントには読み書きは実行されません。 同じボリューム内の他のコンポーネントで次のエラーが発生した場合、そのエラーの処理方法は、ボリュームのタイプによって異なります。 RAID 1 ボリュームでは、多数のコンポーネントが「保守 (Maintenance)」状態になっても、読み取りや書き込みを継続できることがあります。 RAID 5 ボリュームは、その定義からして、「保守 (Maintenance)」状態のコンポーネントが 1 つだけであれば、引き続き動作します。
RAID 0 や RAID 5 ボリュームのコンポーネントにエラーが発生したときに、読み取りに使用できる冗長なコンポーネントが存在しない場合 (たとえば、RAID 5 ボリューム内の 1 つのコンポーネントが「保守 (Maintenance)」状態になった場合)、次に障害が発生したコンポーネントは「最後にエラー (Last Erred)」状態になります。ミラーまたは RAID 5 ボリュームに「最後にエラー (Last erred)」状態のコンポーネントがある場合、入出力はこれまでどおり「最後にエラー (Last erred)」に指定されたコンポーネントに対しても行われます。 これは、Solaris ボリュームマネージャからは「最後にエラー (Last Erred)」状態のコンポーネントに最新の正しいデータコピーが含まれているように見えるからです。 「最後にエラー (Last Erred)」状態のコンポーネントを含むボリュームは正常なデバイス (ディスク) のように動作し、アプリケーションに入出力エラーを返します。 通常、この時点では、データの一部がすでに失われています。
必ず「保守 (Maintenance)」状態のコンポーネントを先に交換してから、「最後にエラー (Last Erred)」状態のコンポーネントを交換します。 コンポーネントを交換して再同期を取ったら、metastat コマンドを使ってコンポーネントの状態を確認し、データが正しいことを検証します。
ミラー コンポーネントが「保守 (Maintenance)」状態である限り、データは失われていません。 コンポーネントをどのような順序で置き換え、有効にしてもかまいません。 コンポーネントが「最後にエラー (Last Erred)」状態の場合は、「保守 (Maintenance)」状態のほかのすべてのコンポーネントを置き換えてから、このコンポーネントを置き換えます。 「最後にエラー (Last Erred)」状態のコンポーネントを交換したり有効にすることは、通常、一部のデータがすでに失われていることを意味します。 ミラーを修復したら、必ずデータを検証してください。
RAID 5 ボリューム RAID 5 ボリュームは、1 つのコンポーネントの障害に耐えることができます。 「保守 (Maintenance)」状態のコンポーネントが 1 つである限り、そのコンポーネントを置き換えてもデータが失われることはありません。 ほかのコンポーネントに障害が発生すると、そのコンポーネントは「最後にエラー (Last Erred)」状態になります。 この時点で RAID 5 ボリュームは読み取り専用になります。 必要な回復処置を行なって、RAID 5 ボリュームを安定状態にし、データ損失の可能性を減らします。 RAID 5 ボリュームが「最後にエラー (Last Erred)」状態の場合には、データがすでに失われている可能性高くなります。 RAID 5 ボリュームを修復したら、必ずデータを検証してください。
ミラーまたは RAID 5 ボリューム内のコンポーネントを交換する場合には、次の指針に従ってください。
必ず「保守 (Maintenance)」状態のコンポーネントを先に交換してから、「最後にエラー (Last Erred)」状態のコンポーネントを交換します。
コンポーネントを交換して再同期を取ったら、metastat コマンドを使ってボリュームの状態を確認し、データが正しいことを検証します。 「最後にエラー (Last Erred)」状態のコンポーネントを交換したり有効にすることは、通常、一部のデータがすでに失われていることを意味します。 ボリュームの修復後に、そのデータが正しいことを必ず確認してください。 UFS の場合は、fsck コマンドを使って「メタデータ」(ファイルシステムの構造) を検証してから、実際のユーザーデータをチェックする必要があります。 (実際には、ユーザーが各自のファイルを確認する必要があります)。 データベースなどのアプリケーションは、独自の方法で内部のデータ構造を検証できなければなりません。
コンポーネントを交換する場合は、状態データベースの複製やホットスペアが存在していないか必ずチェックします。 エラー状態の状態データベースの複製がある場合は、物理ディスクを交換する前に削除する必要があります。 そして、コンポーネントを有効にする前に、この状態データベースの複製を追加してください。 ホットスペアの場合も同じ処理が必要です。
RAID 5 ボリューム コンポーネントの交換中、データは、現在使用中のホットスペアか RAID レベル 5 パリティ (ホットスペアが使用されていない場合) を使用して復元されます。
RAID 1 ボリューム コンポーネントを交換すると、新しいコンポーネントとミラーの残りのコンポーネントとの間で、再同期が自動的に開始されます。 再同期が終了すると、新しいコンポーネントは読み書きが可能になります。 一方、コンポーネントのデータがホットスペアから復元されると、ホットスペアは「使用可能 (Available)」の状態にされ、他のスペア交換に使用できる状態になります。
新しいコンポーネントのサイズは、古いコンポーネントを置き換えられるだけの大きさでなければなりません。
「最後にエラー (Last Erred)」状態のデバイスを交換する場合は、用心のためにすべてのデータのバックアップをとってください。
サブミラーや RAID 5 ボリュームは、障害が発生したコンポーネントの代わりにホットスペアを使用していることがあります。 障害が発生したコンポーネントをこの手順で有効にしたり、交換すると、そのホットスペアはホットスペア集合で「使用可能 (Available)」状態に戻り、使用可能になります。