カスタム検索

Mdadm

提供: HelloKitty68

編集中

 基本的に実行・出力例。どちあらかというとmdadm寄り。  mdそのもの寄り(→RAID(Linux Software Raid))。

目次



基本構築(RAID1例)

# mdadm --create /dev/md0 --raid-device=2 --level=1 /dev/sdc1 /dev/sde1
mdadm: array /dev/md/0 started.

# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sde1[1] sdc1[0]
      57665216 blocks [2/2] [UU]
      [>....................]  resync =  0.7% (451520/57665216) finish=67.4min speed=14132K/sec

startした時点でresyncが開始される。

devices記述

 /dev/sdc1・/dev/sdd1などと1個づつ記述する他,sd[cd]1としても/dev/sdc1・/dev/sdd1と同じように解釈する。無論,パーティーションを切らない場合/dev/sd[cd]でも /dev/sdc /dev/sddと同じ。

missing

missing使用例
# mdadm -C /dev/md100 -l10 -n4 /dev/sdb missing /dev/sdc missing

    Number   Major   Minor   RaidDevice State
       0       8       20        0      active sync   /dev/sda
       1       0        0        1      removed
       2       8       32        2      active sync   /dev/sdc
       3       0        0        3      removed

 必ず後ろの書く物ではなく,抜いておく場所に書くため,例えばRAID10(4dev/near/2copeisつまり普通のRAID10)の場合,Minor値の小さいところから所から

 [RAID1-1][RAID1-2][RAID2-1][RAID2-2]

という配置になるのでmdadm --createする時にミラー無のRAID0で立ち上げたい場合,右図のようになる。

/etc/mdadm.conf

 YaST上から行えばYaSTが更新してくれるが,手動でmdadmで構築した場合は更新されないっぽいので自分で追記する必要がある。

 自分で追加する場合は,

# mdadm --detail --scan
ARRAY /dev/md0 level=raid5 num-devices=3 metadata=0.90 UUID=cb807503:2eea93c3:9a421fc5:615716e2

で表示できるので,

# mdadm --detail --scan >> /etc/mdadm.conf

とでもして追記してから編集するなりすれば手間は省ける。

 現状だとlevel/num-devices/metadetaの記述はアレイが崩壊していない限りは,メタデータを読んで自動的に構築されるので,崩壊アレイの修復などいったイレギュラーな状況を除いて記述する必要が無い。むしろ,明確に記述した事を忘れていると,RAID1→RAID5に変換したとかスペアを追加したとかいう場合に正常に起動しない場合がある。

initrd

 initrd起動(?)の段階でmdが有効になっていれば自動的にassemble/scanされ/dev/md/(dev/md*のリンク)に追加されるので,特別に何か指定する必要が無いのならmdadm.conf自体を作る必要も無い場合がある。この機構は127番からディクリメントされながら追加されてゆく。

アレイボリューム群の物理的なの移動

Suselinux-green.png
 システムを再インストールするなり,元々RAIDの無いシステムにドライブ群を移動させた場合,boot.mdが有効なっておらず起動時に認識しない場合があるので,以下の手順で有効にしmdadm.confに追加する。
例1:
# /etc/init.d/boot.md start
Starting MD Raid mdadm: /dev/md/0 has been started with 3 drives.  done

例2:
# mdadm --assemble -scan
# mdadm --detail --scan >> /etc/mdadm.conf

 RAID1/RAID5といった冗長性のあるアレイでボリュームが欠けている場合は,その時点で認識するボリュームを使い縮退状態で開始する。

汎用

full 短縮 機能
--metadata= -e -e imsm metadataを参照

metadata

 大雑把に4種類ある。

Devices
version
start 1.1
4K 1.2
 
 
end 0.9, 1.0

 普通の?version 0.9のメタ-データ。デフォルトではこれになる。メタデータ自体はボリュームの後ろの方に書かれる。1アレイ当り28ボリュームと,1ボリューム中2TiBまでという制限ある(?)。

 内容自体はVersion 1.0規格なのだが,それぞれ書く位置が違う。1.0は0.9と同じようにendに,1.1はstart(0sectors),1.2はstartから4K(512byte/sector,8sectors)の所に書く。実際のSuper/Data Offset Sectorはmdadm -Eで確認できる。0.9よりメタデータそのものが若干大きくなっている。

 Industry Standard DDF(Disk Data Format)という規格のメタデータ。container用。

 Intel(R) Matrix Storage Managerと互換のあるメタデータ。container用。

create/build/grow

full 短縮 機能
--raid-devices= -n -n 4 デバイスの数を入れる。最低数1。
--spare-devices= -x
--size= -z -z max 単位:KiB。。最大指定:max。デフォルトではアレイを構築しようとしている最小ボリュームに合わせられる(複数の場合)小さくする事もできるが,ファイルシステムのチェックをしていないのでアレイいっぱいのファイルシステムを使っている時に小さくすると当然,破壊される。
--chunk= -c -c 128 単位:KiB。デフォルトは64KiB。有効なのはRAID0/4/5/6/10の時のみ。
--rounding=
--level -l -l multipath linear, raid0, 0, stripe, raid1, 1, mirror, raid4, 4, raid5, 5, raid6, 6, raid10, 10, multipath, mp, faulty, containerから指定できる。また,raid0, 0, stripeのように同義でありどれで指定しても同じRAID0になる。
--layout

--parity

-p -p left-asymmetric-6 下のレイアウトを参照。
--bitmap= -b -b internal internal, none, /で,デフォルトではnone
--bitmap-chunk= --bitmap=512 単位はKiB。internalの場合は自動的に決められるがアレイのチャンクサイズの適当な倍数に合わせるように指定する事もできる。最小4KiBから,2^21まで。実際に設定できる最小サイズはメタデータのバージョンとボリュームの容量で決まる。
--write-behind=   --write-behind=128 既定値は256。RAID1アレイにwrite-behindを設定する。write-behindオプションを有効にするには--bitmap設定時に書くと有効になる。無効にするには--write-mostlyで設定する。

grow

 オンラインのままアレイの設定変えたりできる。

 アレイレベルを維持したまま,RAID1の2重→3重(または逆)やRAID5/3ボリューム→4ボリュームといった拡張ができる。

 特定の条件下ではRAID1→RAID5, RAID5→RAID6変換という事もできる。 また,アレイサイズが収まるのであればRAID5→RAID1といった変換もオンラインでできる場合もある。

 rebuild時を除いてbitmapの設定を変える事ができる。bitmap-chunkサイズの再設定は一度-b noneしてから再設定する。

レイアウト

 レイアウト構造そのものの一部はRAID(Linux Software Raid)を参照。

  • left-asymmetric, la
  • left-symmetric, ls
  • right-asymmetric, ra
  • right-symmetric, rs

 デフォルトではleft-symmetric。

parity-first
    Number   Major   Minor   RaidDevice State
       0       8       66        0      active sync   /dev/sde
       1       8       48        1      active sync   /dev/sdd
       3       8       16        2      active sync   /dev/sdb
  • parity-first/parity-last

 RAID4ライクなレイアウトとして2つある。parity-firstはRaidDevice0をパリティ専用にし,parity-lastはRaidDevice-Nをパリティ専用にする。

 書き込みはパリティを含むストライプ全体に書くが,アレイが正常の時の読み込みは,右の場合,RD1/2を使ったストラピングで読み込みRD0を読み込みに使わない。活用方法としては,こういうアレイへのアクセスが参照が多い場合でSATA2が2ポートしかないマザーでもパリティボリュームをiSCSIなりUSBなり遅いデバイスにしてしまっても正常時には読み込みに影響する事が少ない。。
 DDF RAID5コンパチなレイアウトとしてはddf-zero-restart, ddf-N-restart, ddf-N-continueがある。

 left-symmetric-6, right-symmetric-6, left-asymmetric-6, right-asymmetric-6, pairty-first-6の5種類。

  • near, n
  • far, f
  • offset, o

 コピー数を指定できるので,3copeis-offsetの場合,例:-p o3となる。デフォルトはn2。

 write-transient, wt, read-transient, rt, write-persistent, wp, read-persistent, rp, write-all, read-fixable, rf, clear, flush, none。

bitmap

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [linear] 
md127 : active raid1 sdc[1] sdb[2](F) sda6[0]
      16779776 blocks [2/2] [UU]
      bitmap: 10/129 pages [40KB], 64KB chunk

 1bit=1bitmap-chunkで現し,アレイに何かしら書き込まれるとボリューム単位でbitmapが通常5秒毎に更新される。例えば512KB bitmap-chunkの場合ボリュームを512KBで分割し1bit=512KBで管理する。アレイのchunkサイズとは別なので64KB array chunkで1ストライプだけ更新しても,そのストライプを含む512KB分を更新した物とする。

# mdadm -X /dev/sda6
        Filename : /dev/sda6
           Magic : 6d746962
         Version : 4
            UUID : 166a1426:3e338787:f31a64e9:13fa25b3
          Events : 587999
  Events Cleared : 587996
           State : OK
       Chunksize : 64 KB
          Daemon : 5s flush period
      Write Mode : Normal
       Sync Size : 16779776 (16.00 GiB 17.18 GB)
          Bitmap : 262184 bits (chunks), 22 dirty (0.0%)

 作っておくことでrecoveryなどの時間が短縮される。例えばRAID1の片方を一時的に外して書き込むと外していないボリュームのbitmapだけが更新される。後で外した同じボリュームをre-addすると,それぞれにbitmapに違いが出るので,そのbitmapを元に変更された部分だけrecovreyするといった具合になる。これを利用した短時間のバックアップをする事できる。

 mdadm --examine-bitmap(-X)でそれぞれのボリューム状態を知る事ができる。

 また,スーパーブロックが空いているのなら(稀になぜか埋まっている),mdadm --grow -b internalで既存アレイにbitmapを付ける事ができる(--bitmap-chunk=でサイズ指定も可能)。オンラインのまま-b noneでbitmapを消したりもできる。bitmap-chunkサイズの再設定は一度-b noneしてからするとできる。

 PVにしている場合,bitmap-chunkが小さいとpvmoveが極端に遅くなる場合がある。--bitmap-chunk=で大きいサイズ(32768KBとか)にして試してみること。

write-behind

# mdadm --examine-bitmap

write-mostly時
Write Mode : Normal

write-behind=256時:
Write Mode : Allow write behind, max 256

 RAID1アレイのみに有効。通常のLinux software RAID1の挙動は,書き込みは全てのボリュームに同じデータを同時に書き込むが,読み込みはRAID1の複数のボリュームになっている全体に負荷分散しようとする。

 write-behindはさらに書き込みも分散しようとする。例えば極端な例としては同一アレイ上でファイル複製をしようとすると,片方のボリュームから読み,もう片方のボリュームに書き込む事で分散し,後でbitmapをチェックし同期する。この為,一時的にボリューム毎に中身が異なる事に注意。

 有効にしたボリュームは--examine-bitmap(-X)で見ると右のようになる。

その他

 リカバリー中にbitmapの更新はできないのでエラーが出る。

 -zでアレイサイズを変更しようとした時にbitmapがあるとエラーになるので一度外してからサイズ変更をし,大抵の場合サイズ変更すすると拡張部分をresyncするので,その後でbitmapを付け直す。

アレイ情報

簡略情報

# mdadm --misc -Q /dev/md0
/dev/md0: 800.02GiB raid5 3 devices, 0 spares. Use mdadm --detail for more detail.

詳細情報

# mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Sun Jan 18 13:34:21 2009
     Raid Level : raid5
     Array Size : 976764928 (931.52 GiB 1000.21 GB)
  Used Dev Size : 488382464 (465.76 GiB 500.10 GB)
   Raid Devices : 3
  Total Devices : 3
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Sun Jan 18 13:35:08 2009
          State : active, resyncing
 Active Devices : 3
Working Devices : 3
 Failed Devices : 0
  Spare Devices : 0

         Layout : left-symmetric
     Chunk Size : 8192K

 Rebuild Status : 3% complete

           UUID : bf5fae26:b319ee3c:9a421fc5:615716e2 (local to host vmsrv)
         Events : 0.3

    Number   Major   Minor   RaidDevice State
       0       8       17        0      active sync   /dev/sdb1
       1       8       49        1      active sync   /dev/sdd1
       2       8       81        2      active sync   /dev/sdf1

raidの状態をリアルタイム?で見る

例:再構築中
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4] [raid0] 
md1 : active raid5 sde2[3] sdc2[1] sdb2[0]
      137890816 blocks super 1.0 level 5, 128k chunk, algorithm 0 [3/2] [UU_]
      [=====>...............]  recovery = 27.5% (18971776/68945408) finish=14.3min speed=57992K/sec
      bitmap: 0/132 pages [0KB], 256KB chunk

 watchで使う事も可能で,X11上の適当なターミナルなり,リモートなりから,

# watch -n 1 cat /proc/mdstat

とでもしておけば,リビルドの状態が1秒毎に更新される。

rebuildステータス

recovery
   RAID1
HDD1   HDD2
 A1  => A2    COPY
 |      |
 C1  => C2
resync
   RAID1
HDD1   HDD2
 A1     A2    IF A1==A2
 B1     B2     ELSE write A2
 C1     C2
resync

 ストライプの全てのボリュームから読み比較し,一致しなければ書き込む。一致していれば書き込まないので,構築前にzeroで初期化した物や,元々同じアレイで再構築した場合等に書き込まない場合がある。

recovery

 スペア以外の正常なボリュームから読み,スペアに一方的に書き込む。

resharp
  RAID1              RAID5
HDD1 HDD2        HDD1 HDD2 HDD3
 A1   A2          A    B    P1
 B1   B2     =>   C    P2   D
 C1   C2          P3   rs   rs
 D1   D2          rs   rs   P4
resharp

 特にRAID5/6の場合配置そのものの変換を行う。RAID1の2重ミラー→3重ミラーの場合recoveryとほとんど変わらない。

 例えばRAID1/2dev→RAID5/3dev変換の場合,RAID1エンド地点はRAID5の1/2付近になる。この為,進むにつれてランダムシーク時間がどんどん長くなる。RAID5の1/2まで変換を終えると残りはRAID5としてのresyncがされる。

新規構築時の短縮

 新規構築時にresyncするとは当然としても,アレイの種類によってはその仕様の問題からフラットにアクセスするより2倍以上の時間がかかる場合があるが,recoveryであればほぼ一方的に読んで書き込むので,意図的にrecoveryで構築すれば新規構築の時間短縮が出来る。

 resync時に時間がかかる問題点としては,各々のボリュームをアレイに使う前にシングルなどとして使っていて,比較時に不一致となり各々のボリュームに書き戻す為に起こる。これはチャンクサイズにも比例するが,小さめだといくらHDDの物理的な密度が上がったとしても同じ所に書き戻す為には最低でもディスクが1周してくるのを待つ必要があるという物理的な問題(7200rpmで8.3msec)。

 できない物としてはRAID10/3dev以上や(前後ブロックを持つ為)といったもの。こういった物は一度/dev/zeroで空にしてからresyncすれば並列読み出しで済む。

例:RAID10/2vol/2copeis-far

 resyncの挙動的には,

  1. A Vol Add0 read
  2. B Vol Add0 read
  3. 比較
  4. 不一致>B Vol write

でさらにA/B双方向にアクセスするので,3倍ほど時間がかかる。しかし,構築時に1ボリューム+missingで組みmkfsするなりしてからホットスペアを追加しrecoveryをさせると,A volの前半をそのままB Vol後半にフラットにコピーし,連続してA volの後半をそのままB Vol前半にコピーしようとするのでほとんどランダムアクセスする箇所がなく1ボリュームをフルリードする時間と同じというわけにはいかないが,近い時間までに短縮できる。

例:RAID5

 RAID5を新規縮退構築しrecoveryした場合,元から各々のボリュームに入っているデータを正常なデータとパリティ値として読んで復元する為,結果的に壊れたデータと正常なパリティがスペア上に復元されるという事になり,アレイとしては正常だがファイルシステム(やLVM)としては全く意味の無いものが復元される。

/proc/sys/dev/raid

 リカバリーなどのsoftware RAIDの転送速度に影響するので書き換えを勧める事が多いのだが,少なくともopenSUSEの場合,デフォルトで

speed_limit_max = 200000(つまり200MB/s)
spped_limit_min = 1000(1MB/s)

となっているので,それらが遅い場合別な所に原因がある。

rebootとcontinue

 バックグラウンドで再構築中にシステムの再起動なりで中断された場合は再構築情報は保持され,次回起動時にmdadm.confが記述されていれば自動的に再開する。


リカバリー中のアクセス

 リカバリー中のボリュームにR/Wが発生した場合は次のようになる。

 正常な方ボリュームから読み込みを行う。RAID5などの複数ある場合はリカバリー中のボリュームの除いたボリュームだけを使って読み込む。

 リカバリー済み・未処理全ての領域でリカバリー中のボリュームを含めて全体に書き込みを行う。未処理部分が更新されたとしても,リカバリーが進み再度更新さるだけに過ぎず,大量に更新しないのであればさほど気にするほどの物でもない。

 また,R/W両方の処理が発生した場合,リカバリー処理を数秒間だけ一時停止する状態になり,アイドルになるとまた再開。


関連リンク

リンク

パッケージ検索 man検索

[■Edit]

[■Edit]

案内
ツールボックス