test

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

第 20 章 Solaris ボリュームマネージャの保守 (作業)

この章では、Solaris ボリュームマネージャの一般的な記憶領域管理に関連する保守作業について説明します。

この章の内容は次のとおりです。

Solaris ボリュームマネージャの保守 (作業マップ)

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

作業 

説明 

参照先 

Solaris ボリュームマネージャ構成の表示 

Solaris ボリュームマネージャの GUI か metastat コマンドを使ってシステム構成を表示します。

「Solaris ボリュームマネージャのボリューム構成を表示する」

ボリューム名の変更 

Solaris ボリュームマネージャの GUI か metarename コマンドを使ってボリューム名を変更します。

「ボリューム名を変更するには」

構成ファイルの作成 

metastat -p コマンドと metadb コマンドを使って構成ファイルを作成します。

「構成ファイルを作成するには」

構成ファイルを使用した Solaris ボリュームマネージャの初期化 

metainit コマンドを使って構成ファイルから Solaris ボリュームマネージャを初期化します。

「構成ファイルを使って Solaris ボリュームマネージャを初期化するには」

ファイルシステムの拡張 

growfs コマンドを使ってファイルシステムを拡張します。

「ファイルシステムを拡張するには」

コンポーネントの有効化 

Solaris ボリュームマネージャの GUI か metareplace コマンドを使ってコンポーネントを有効にします。

「コンポーネントの有効化」

コンポーネントの交換 (置き換え) 

Solaris ボリュームマネージャの GUI か metareplace コマンドを使ってコンポーネントを交換します。(置き換える)

「コンポーネントを他の使用可能なコンポーネントで置き換える」

Solaris ボリュームマネージャ構成の表示

ヒント –

metastat の出力はソートされていません。構成リストを編集したい場合は、metastat -p コマンドの出力を入力して sort または grep コマンドを実行してください。

ProcedureSolaris ボリュームマネージャのボリューム構成を表示する

    次のどちらかの方法でボリューム構成を表示します。

    • Solaris 管理コンソール内の「拡張ストレージ」から「ボリューム (Volumes)」ノードを開きます。詳細は、オンラインヘルプを参照してください。

    • 次の形式の metastat コマンドを使用します。


      # metastat -p -i component-name
      -p

      要約形式で出力を表示することを指定します。この出力は、md.tab ファイルを作成するときに使用するのに適しています。

      -i

      RAID-1 (ミラー) ボリューム、RAID-5 ボリューム、およびホットスペアにアクセスできるかどうかを確認することを指定します。

      component-name

      表示するボリュームの名前を指定します。ボリューム名を指定しないと、すべてのコンポーネントが表示されます。

例 20–1 Solaris ボリュームマネージャのボリューム構成を表示する

次に、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
例 20–2 マルチテラバイトのSolaris ボリュームマネージャボリュームを表示する

次に、マルチテラバイトの記憶ボリューム (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) のマニュアルページを参照してください。

ボリューム名の変更

ボリューム名を変更するための背景情報

Solaris ボリュームマネージャでは、多少の制約はありますが、ほとんどのタイプのボリューム名をいつでも変更できます。 ボリューム名の変更は、Solaris 管理コンソール内の「拡張ストレージ」かコマンド行 (metarename(1M) コマンド) から行うことができます。

ボリューム名の変更や交換は、ボリューム名を管理する上で便利な機能です。たとえば、ファイルシステムのすべてのマウントポイントをある範囲の数値内に収めることができます。あるいは、論理ボリュームの命名規則に従ってボリューム名を変更したり、トランザクションボリュームの名前にそのボリュームを構成しているボリュームと同じ名前を使用したりすることができます。

注 –

トランザクションボリュームは、Solaris ボリュームマネージャでは使用できなくなりました。トランザクションボリュームの名前を変更して置き換えることができます。

ボリューム名を変更するときは、ボリュームが使用中でないことを確認してください。ファイルシステムとして使用されている場合は、マウントされていたり、swap として使用されていないことを確認してください。データベースなど、raw デバイスを使用するその他のアプリケーションは、独自の方法でデータへのアクセスを停止できる必要があります。

ボリューム名の変更に伴う特別な考慮事項は、次のとおりです。

ボリューム名の交換

metarename コマンドに -x オプションを指定すると、親子関係のあるボリュームの名前が交換されます。詳細は、「ボリューム名を変更するには」と metarename(1M) のマニュアルページを参照してください。既存のボリュームの名前がサブコンポーネントの 1 つと交換されます。たとえば、ミラーとそのサブミラーの 1 つで、このタイプの交換を実行できます。metarename -x コマンドを使用すると、既存のボリュームのミラー化またはミラー化解除が簡単にできます。

注 –

ボリューム名の交換には、コマンド行を使用する必要があります。この機能は、現在のところ Solaris ボリュームマネージャの GUI にはありません。ただし、ボリューム名の変更はコマンド行からでも GUI からでも行えます。

ボリューム変更するときには、次の指針を考慮してください。

Procedureボリューム名を変更するには

始める前に

ボリューム名の要件 (「ボリューム名」) と 「ボリューム名を変更するための背景情報」を確認します。

  1. このボリュームを使用するファイルシステムのマウントを解除します。


    # umount /filesystem

  2. 次のどちらかの方法でボリューム名を変更します。

    • Solaris 管理コンソール内の「拡張ストレージ」から「ボリューム (Volumes)」を開きます。名前を変更するボリュームを選択します。アイコンを右マウスクリックします。「プロパティ (Properties)」オプションを選択します。画面の指示に従います。詳細は、オンラインヘルプを参照してください。

    • 次の形式の metarename コマンドを実行します。


      # metarename old-volume-name new-volume-name
      old-volume-name

      既存ボリュームの名前を指定します。

      new-volume-name

      既存のボリュームに新しい名前を指定します。

      詳細については、metarename(1M) コマンドのマニュアルページを参照してください。

  3. 必要であれば、エントリが新しいボリューム名を参照するように /etc/vfstab ファイルを編集します。

  4. ファイルシステムを再びマウントします。


    # mount /filesystem
例 20–3 ファイルシステムとして使用されているボリュームの名前を変更する

次の例では、ボリュームの名前 d10 を d100 に変更します。


# umount /home
# metarename d10 d100
d10: has been renamed to d100
(ファイルシステムが新しいボリュームを参照するように /etc/vfstab ファイルを編集する)
# mount /home

d10 にはマウントされたファイルシステムがあるので、ファイルシステムをマウント解除してからでなければ、ボリューム名を変更できません。このファイルシステムのエントリが /etc/vfstab ファイル内に存在している場合は、そのエントリが新しいボリューム名を参照するように変更します。

たとえば、/etc/vfstab ファイルにファイルシステム用の次のエントリが指定されているとします。


/dev/md/dsk/d10 /dev/md/rdsk/d10 /docs home 2 yes -

次のようにエントリを変更します。


/dev/md/dsk/d100 /dev/md/rdsk/d100 /docs home 2 yes -

その後、ファイルシステムを再びマウントします。

既存のミラーやトランザクションボリュームが存在する場合、metarename -x コマンドでミラーやトランザクションボリュームを削除しても、そのボリュームを構成するボリュームのデータは保持できます。たとえば、トランザクションボリュームの場合には、マスターデバイスが ボリューム (RAID 0、RAID 1、または RAID 5 ボリュームのいずれか) である限り、そのボリュームのデータは保持されます。

構成ファイルの使用

Solaris ボリュームマネージャの構成ファイルには、Solaris ボリュームマネージャの基本情報の他に、構成を再設定するのに必要なほとんどのデータが含まれています。次の手順で、構成ファイルに関連する作業について説明します。

Procedure構成ファイルを作成するには

    Solaris ボリュームマネージャ環境用のすべてのパラメータを適切に設定したら、metastat -p コマンドで /etc/lvm/md.tab ファイルを作成します。


    # metastat -p > /etc/lvm/md.tab

    このファイルには、metainit コマンドと metahs コマンドが使用するすべてのパラメータが含まれています。このファイルは、類似した環境をいくつも用意しなければならない場合、またはシステム障害後に構成を再作成する場合に使用します。

    md.tab ファイルの詳細については、「md.tab ファイルの概要」 と md.tab(4) のマニュアルページを参照してください。

Procedure構成ファイルを使って Solaris ボリュームマネージャを初期化するには

注意 – 注意 –

この手順は、次の状況で使用します。

状態データベースで維持していた情報が失われることがあります。たとえば、状態データベースの複製をすべて削除したあとで、システムをリブートすると、この状況が生じる場合があります。状態データベースの消失後、ボリュームがまったく作成されていない場合は、md.cf ファイルまたは md.tab ファイルを使用して、Solaris ボリュームマネージャの構成を回復できます。

注 –

md.cf ファイルには、アクティブなホットスペアの情報は格納されません。そのため、Solaris ボリュームマネージャ構成が失われたときにホットスペアが使用されていると、アクティブなホットスペアを使用していたボリュームの内容は破壊されていることがあります。

これらのファイルの詳細については、md.cf(4)とmd.tab(4) のマニュアルページを参照してください。

  1. 状態データベースの複製を作成します。

    詳細は、「状態データベースの複製の作成」を参照してください。

  2. /etc/lvm/md.tab ファイルを作成するか更新します。

    • 最後の状態でSolaris ボリュームマネージャの構成を回復する場合は、md.cf ファイルを /etc/lvm/md.tab ファイルにコピーします。

    • 保存されている md.tab ファイルのコピーを使って新しい Solaris ボリュームマネージャ構成を作成する場合は、保存されているファイルを /etc/lvm/md.tab ファイルにコピーします。

  3. 「新しい」 /etc/lvm/md.tab ファイルを編集して、次の作業を行います。

    • 新しい構成を作成している場合や、クラッシュの後で構成を回復している場合には、ミラーを 1 面ミラーとして構成します。たとえば、次のように指定します。


      d80 -m d81 1
d81 1 1 c1t6d0s3

      ミラーの各サブミラーのサイズが同じでない場合は、もっとも小さいサブミラーがこの 1 面ミラーに使用されるようにします。そうしないと、データが失われるおそれがあります。

    • 既存の構成を回復している場合、Solaris ボリュームマネージャが正常に終了しているのであれば、ミラー構成を多面ミラーのままにして回復します。たとえば、次のように指定します。


      d70 -m d71 d72 1
d71 1 1 c1t6d0s2
d72 1 1 c1t5d0s0

    • RAID-5 ボリュームの場合は、デバイスの再初期化を防止するために -k オプションを指定します。たとえば、次のように指定します。


      d45 -r c1t3d0s5 c1t3d0s3 c1t3d0s4 -k -i 32b

      詳細は、metainit(1M) のマニュアルページを参照してください。

  4. 次の形式の metainit コマンドを使用して、変更をコミットすることなく、/etc/lvm/md.tab ファイルエントリの構文を調べます。


    # metainit -n md.tab-entry


    # metainit -n -a

    metainit コマンドに -n オプションを付けて実行した場合、同じ実行中にすでに仮想的に作成されているデバイスを記憶しません。このため、md.tab 内に記述された別のボリュームに依存するボリュームを作成しようとすると、-n オプションを指定しなければ正常に実行される場合でも -n オプションを指定するとエラーになることがあります。

    -n

    デバイスを実際には作成しないことを指定します。このオプションは、予期した結果が得られるかどうかを確認する場合に使用します。

    md.tab-entry

    初期化するコンポーネントの名前を指定します。

    -a

    すべてのコンポーネントをチェックすることを指定します。

  5. 前の手順で特に問題がなければ、md.tab ファイルを使ってボリュームとホットスペア集合を作成し直します。


    # metainit -a
    -a

    /etc/lvm/md.tab file のエントリをアクティブにすることを指定します。

  6. 必要であれば、metattach コマンドを使用して、1 面ミラーを多面ミラーに変更します。


    # mettach mirror submirror

  7. ボリューム上のデータを検証し、構成が正しく再作成されたかどうかを確認します。


    # metastat

Solaris ボリュームマネージャのデフォルト値の変更

Solaris 10 リリースで、Solaris ボリュームマネージャはボリュームを動的に構成するように拡張されました。/kernel/drv/md.conf ファイルの nmd パラメータと md_nsets パラメータを編集しなくてすみます。新しいボリュームは必要に応じて作成されます。

Solaris ボリュームマネージャ構成の最大値は同じです。

growfs コマンドによるファイルシステムの拡張

UFS ファイルシステムが含まれているボリュームを拡張 (つまり、領域を追加) した場合は、追加した領域が認識されるように、ファイルシステムを拡張することも必要です。ファイルシステムの拡張は、growfs コマンドを使って手動で行う必要があります。growfs コマンドは、ファイルシステムがマウントされている場合でも拡張できます。ただし、growfs コマンドの実行中は、ファイルシステムに書き込みアクセスを行うことはできません。

データベースなど、raw デバイスを使用するアプリケーションは、独自の方法で追加された領域を組み込むことができなければなりません。Solaris ボリュームマネージャには、この機能はありません。

growfs コマンドはファイルシステムを拡張するとき、マウントされているファイルシステムを「書き込みロック」します。ファイルシステムが書き込みロックされている時間を短縮する必要がある場合は、ファイルシステムを段階的に拡張できます。たとえば、1G バイトのファイルシステムを 2G バイトに拡張する場合、-s オプションを使用することによって、16M バイト単位でファイルシステムを拡張できます。このオプションでは、ステージごとの新しいファイルシステムの総容量を指定します。

拡張処理の間は書き込みロックが機能するので、このファイルシステムへの書き込みは実行できません。書き込みアクセスは growfs コマンドがファイルシステムのロックを解除するまで自動的に中断され、ロックが解除されると再開されます。読み取りアクセスは影響を受けません。しかし、ロックが有効な間、アクセス時間は保証されません。

スライスやボリュームを拡張するための背景情報

注 –

Solaris ボリュームマネージャのボリュームは拡張可能です。ただし、ボリュームを縮小することはできません。

Procedureファイルシステムを拡張するには

始める前に

「Solaris ボリュームマネージャコンポーネントを作成するための前提条件」を確認します。

  1. ファイルシステムに対応付けられたディスク領域を確認します。


    # df -k

    詳細については、df(1M) のマニュアルページを参照してください。

  2. UFS ファイルシステムを論理ボリュームで拡張します。


    # growfs -M /mount-point /dev/md/rdsk/volume-name
    -M /mount-point

    拡張するファイルシステムのマウントポイントを指定します。

    /dev/md/rdsk/volume-name

    拡張するボリュームの名前を指定します。

    詳細は、次の例と growfs(1M) のマニュアルページを参照してください。

例 20–4 ファイルシステムを拡張する

次の例では、新しいスライスがボリューム d10 にすでに追加されています。このボリュームには、マウントされているファイルシステム /home2 があります。growfs コマンドでは、-M オプションを使ってマウントポイントに /home2 を指定し、これを raw ボリューム /dev/md/rdsk/d10 上に拡張します。growfs コマンドが終了すると、このファイルシステムはボリューム全体を占めます。ファイルシステムを拡張する前後に df -k コマンドを使用すると、ディスクの総容量を確認できます。


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

ミラーボリュームの場合、growfs コマンドは常に、最上位のボリュームで 実行します。サブミラーまたはマスターデバイスに領域を追加する場合であっても、サブミラーまたはマスターデバイスに対してコマンドを実行してはなりません。

RAID-1 および RAID-5 ボリューム内のコンポーネントの交換と有効化の概要

Solaris ボリュームマネージャは、RAID-1 (ミラー) および RAID-5 ボリューム内のコンポーネントを 交換したり、有効にしたりできます。

Solaris ボリュームマネージャでは、コンポーネントの交換は、サブミラーまたは RAID-5 ボリューム内のコンポーネントをシステム上で使用可能な他のコンポーネントと交換することを意味します。このプロセスは、コンポーネントの物理的な交換ではなく論理的な交換です。詳細については、「コンポーネントを他の使用可能なコンポーネントで置き換える」を参照してください。

コンポーネントの有効化とは、コンポーネントをアクティブにする (または、コンポーネントをそれ自身で置き換える) ことを意味します。したがって、コンポーネント名は変わりません。詳細については、「コンポーネントの有効化」を参照してください。

注 –

ディスクエラーから回復するときは、 /var/adm/messages を調べ、どのような種類のエラーが発生したかを確認してください。エラーが一時的なものであり、ディスク自体に問題がない場合は、コンポーネントを有効にしてみます。また、format コマンドを使ってディスクをテストすることもできます。

コンポーネントの有効化

コンポーネントを有効にする必要があるのは次のような場合です。

注 –

交換対象のディスクに状態データベースの複製やホットスペアがないか必ずチェックしてください。「エラー (erred)」状態の状態データベースの複製を削除してから、ディスクを交換する必要があります。さらに、コンポーネントを有効にしてから、同じサイズで状態データベースの複製を作成し直します。ホットスペアについても同じように処理してください。

コンポーネントを他の使用可能なコンポーネントで置き換える

既存のコンポーネントを他の未使用のコンポーネントで置き換える (または交換する) には、metareplace コマンドを使用します。

このコマンドを使用できるのは、次のような場合です。

「保守 (Maintenance)」状態と「最後にエラー (Last Erred)」状態

RAID-1 または RAID-5 ボリュームのコンポーネントでエラーが発生すると、Solaris ボリュームマネージャはそのコンポーネントを「保守 (Maintenance)」状態にします。これ以降、「保守 (Maintenance)」状態のコンポーネントには読み書きは実行されません。

コンポーネントは「最後にエラー (Last Erred)」状態になることもあります。RAID-1 ボリュームの場合、このエラーは通常、1 面ミラーで発生します。ボリュームにエラーが発生したとします。しかし、読み取り対象となる冗長コンポーネントはありません。RAID-5 ボリュームでは、あるコンポーネントが「保守 (Maintenance)」状態になり、かつ、別のコンポーネントで障害が発生した場合に、この状態になります。障害の発生した 2 番目のコンポーネントが、「最後にエラー (Last Erred)」状態になります。

RAID-1 ボリュームまたは RAID-5 ボリュームのどちらかに「最後にエラー (LastErred)」状態のコンポーネントがあっても、入出力は引き続き、その「最後にエラー (LastErred)」状態のコンポーネントに対して試行されます。この入出力が試行されるのは、「最後にエラー (Last Erred)」状態のコンポーネントにデータの最後の正常なコピーが含まれていると、Solaris ボリュームマネージャが判断するためです。「最後にエラー (Last Erred)」状態のコンポーネントを含むボリュームは正常なデバイス (ディスク) のように動作し、アプリケーションに入出力エラーを返します。通常、この時点では、データの一部がすでに失われています。

同じボリューム内の他のコンポーネントで次のエラーが発生した場合、そのエラーの処理方法は、ボリュームのタイプによって異なります。

RAID-1 ボリューム

RAID-1 ボリュームでは、多数のコンポーネントが「保守 (Maintenance)」状態になっても、読み取りや書き込みを継続できることがあります。コンポーネントが「保守 (Maintenance)」状態である場合、データは失われていません。コンポーネントをどのような順序で置き換え、有効にしてもかまいません。コンポーネントが「最後にエラー (Last Erred)」状態の場合は、「保守 (Maintenance)」状態のコンポーネントを置き換えてから、このコンポーネントを置き換えます。「最後にエラー (Last Erred)」状態のコンポーネントを交換したり有効にすることは、通常、一部のデータがすでに失われていることを意味します。ミラーを修復したら、必ずデータを検証してください。

RAID-5 ボリューム

RAID-5 ボリュームは、「保守 (Maintenance)」状態のコンポーネントが 1 つであれば許容できます。「保守 (Maintenance)」状態のコンポーネントが 1 つの場合、そのコンポーネントはデータを失うことなく安全に交換できます。ほかのコンポーネントに障害が発生すると、そのコンポーネントは「最後にエラー (Last Erred)」状態になります。この時点で RAID-5 ボリュームは読み取り専用になります。必要な回復処置を行なって、RAID-5 ボリュームを安定状態にし、データ損失の可能性を減らします。RAID-5 ボリュームが「最後にエラー (Last Erred)」状態の場合には、データがすでに失われている可能性が高くなります。RAID-5 ボリュームを修復したあと、必ずデータを検証してください。

必ず「保守 (Maintenance)」状態のコンポーネントを先に交換してから、「最後にエラー (Last Erred)」状態のコンポーネントを交換します。コンポーネントの交換と再同期の実行後、metastat コマンドを使用してコンポーネントの状態を確認します。さらに、データを検証します。

RAID-1 および RAID-5 ボリューム内のコンポーネントを交換または有効にするための背景情報

RAID-1 ボリュームまたは RAID-5 ボリュームのコンポーネントを交換する場合は、次の指針に従ってください。