タグ別アーカイブ: mdadm

WesternDigital春のRMA祭り

さて、今年もやって参りましたRMA祭りの開催です。
今回はサーバ機で2本、個人用マシンで1本、いずれもWesternDigital社製ハードディスクに異常が検出されました。

いい加減にしろよくそがおいこのゴミカスマジで紀伊店のか。

あ、すいません、思わず心の声が聞こえてしまったようで。
お気になさらず先へ進みましょう。

いつからでしょうか、そう遠くない頃合いに、サーバ機のrootあてにsmartctlからメールが届いていました。
smartctlからのメールなんて良いことが書いてあるわけがないわけでして、案の定SMART値に異常があるよというお話でした。
でまあ確認してみたところ

Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: read failure       90%      2317         17715224

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
197 Current_Pending_Sector  0x0032   195   195   000    Old_age   Always       -       1461

おい、Current_Pending_Sector 1461ってどこまで深刻化してから通知よこすんだよ、もうこんなディスクつかえねーから。
そして一通りディスクをしらべてみると、別のディスクでも144でてる。
こいつも交換対象だな。

だがサーバ機ははRAID5で運用しているので、二本同時に引っこ抜くのは当然できない。
どう見ても重度な方のディスクをとりあえず引っこ抜いて、縮退モードで運用し、RMA申請して帰ってきたら再構築、そしたら次に危ない子を引っこ抜いて。。。という流れで対処しようと思う。
金持ちじゃないんで、代替ディスクを用意してすぐに交換するなんてことはしません。

で、デスクトップの方ですが、こちら2Tのディスクを2本使っているうちの1本で不良セクタが発生。
最近なんか調子悪かったのでRAID0を解除してデータを整理してスキャンディスクしたら判明。
一本は元気なようで、とりあえずはその一本で間に合うので、調子の悪い子はサーバ機のHDDのRMAが終わってからRMAすることに。

ということで、それぞれのディスクがRMA申請できるか保証をチェック
したところ、一匹できないのがまざってた。
デスクトップのやつ。

CFDでRMA申請を可能にする申請をだす

こいつはまあどうせ後回しだし。
別の二台のRMAが終わった頃にはRMAできるようになってるでしょ。

ということで、一番重傷な子をとりあえずRMA申請。

んじゃ、取り外そう。

。。。てどのディスクなんだっけ。
いや、諸々の問題からDom0上でRAID5を構築しているわけではなく、DomUで構築しておりまして。
んと、Dom0では/dev/sdeだから。。。DomUでは。。。/dev/xvdb4らしい。
xm conでDomUにコンソール接続して。。。

# mdadm /dev/md3 --fail /dev/xvdb4
[1799713.802196] md/raid:md3: Disk failure on xvdb4, disabling device.
[1799713.802198] md/raid:md3: Operation continuing on 4 devices.
mdadm: set /dev/xvdb4 faulty in /dev/md3

# mdadm /dev/md3 --remove /dev/xvdb4
[1799899.247128] md: unbind<xvdb4>
[1799899.247142] md: export_rdev(xvdb4)
mdadm: hot removed /dev/xvdb4 from /dev/md3

# mdadm -D /dev/md3
*snip*
          State : clean, degraded
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

*snip*

    Number   Major   Minor   RaidDevice State
       6     202       17        0      active sync   /dev/xvdb1
       1     202       18        1      active sync   /dev/xvdb2
       2     202       19        2      active sync   /dev/xvdb3
       3       0        0        3      removed
       4     202       21        4      active sync   /dev/xvdb5

さて、xenのDomUの設定ファイルのストレージの記述からも外して、物理的にHDDを引っこ抜く。

前SeagateのRMAで返送されたときの箱をとってあるので、それにHDDをつっこむ。
RMA手順指示書を二部プリントアウトして、一部は二カ所ほど署名をして箱に同梱。
一部は郵便局で送り状やらインボイスやらを記入するときの参考資料として持って行く。
RMA labelは張った方が早くなるらしいといわれているけど、張って1ヶ月、張らずに2週間を経験してるので面倒だからもう張らないことにした。
Western Digitalの人と直接やりとりしたときも、ラベルつくって張ってね、とか一言も言われなかったし。

じゃ、郵便局行ってくるか。
おかげで英語で住所書くの慣れた。

mdadmで構築したRAID5のチャンクサイズを変更してみた

やり方は簡単で

# mdadm -G -c512 --backup-file=/path/to/backup /dev/mdX

これでチャンクサイズが512kbになる。
ストライピング(RAID0)でも同じだろう。

ところで、5台構成(うち一台欠落中)のRAID5でやるとえらい遅いんだが。。。
renice -20 -p xxx
とかやって優先度かえても遅い。

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md3 : active raid5 sda3[0] sde1[4] sdd1[2] sdb3[1]
      5857284096 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [5/4] [UUU_U]
      [>....................]  reshape =  0.2% (4300800/1464321024) finish=6868.2min speed=3542K/sec

3.5Mしかでてないっすよ。。。
5日ほどかかるようで。。。

reshape中にマシン停止するとどうなるのかは怖くて試せない。

しらべてみると、reshape中に再起動とかさせても平気らしいです。
こちらで実験してました。
いやー、mdadmよくできてる。

mdadmでRAID ARRAYのホームホストや名前を変える

レスキューディスクでアレイを作ったらホームホストがそのときのレスキューのホスト名になっちゃってて、ようするにdebianになっちゃってたんで、なんとかしたいと思ったわけですはい。

アレイを組み立てるっていうかassembleするときに–update=で指定できるようで。
でもシステム領域含まれてるんでまたレスキュー使わないといけないんですね、はい。

ということでレスキューに潜り込んで、ホスト名を目的のものにちゃんと設定します。
じゃなかったらassembleの時にオプションで–homehost=で指定します。

# mdadm -A /dev/md1 /dev/sd[ab]1 --update=homehost

ホスト名ちゃんとしたの指定してなかったら

# mdadm -A /dev/md1 /dev/sd[ab]1 --homehost=hogehoge --update=homehost

みたいな感じ。
アレイがすでに起動してたら一回停止してからやりましょう。
アレイのメタデータのバージョンが1系ならmdadm -Dで出てきます。

Name : hogehoge:2  (local to host hogehoge)

のところ。
homehostと今のホストが正しければlocal to host hogehogeのところが出てきます。
mdadm -Dsでかぶってる名前のやついたら一回アレイをとめて

# mdadm -A /dev/md1 /dev/sd[ab]1 --update=name

とかしましょう。
解消されるはずです。

ちなみにmd1とかmd2とかのデバイス名を変えたい場合も同じ感じで、アレイが動いていれば停止して、アセンブルしてやって名前更新かけてやればいいです。

できあがったらシステムをルートにしてシェルを実行して、mdadm -Ds>>/etc/mdadm/mdadm.confたたいて今までのアレイ情報はコメントアウトしましょう。
念のためupdate-initramfs -uk allたたいておいた方が良いかもしれません。
特にデバイス名を変更した場合は必須だと思います。

4KBセクタのことを考えずにパーティション切っちゃってたことに気づいて何とか切り直そうとしてみる

最近4KBセクタのHDD増えましたよね。
ってか割と今更感もあると感じる人も多いかと思うけど、実際のところうちのサーバ機の構成HDDはちょっと前まで4KBセクタのHDDは混じってなかったんです。
でも、HDDの寿命やら故障やらで交換してたら、気づかぬうちに6 本中3本が4KBセクタものになっていました。
そして、そのことに気づいたのが昨日。

さて、パーティションは普通にfdiskで切ってましたよ、ええ。
パーティション開始位置みたら先頭パーティションおもいっきり63セクタですよええ。

ということで、パーティションを切り直す必用がある、というか、必用ではないけど切り直した方がいいのは間違いないわけで。

あ、何が問題なのかわからない人のために一応4KBセクタのお話をすっげー簡単にしておきます。
HDDは基本的に一セクタ512byteでした。
でも大容量化に伴い、一セクタ512byteだと非効率になってきたんで、一セクタ4KiBのHDDが出てきました。
なんだけど、BIOSとかドライバとかまあ根本的なところがHDDの一セクタは512byteっていう前提のものがまだまだ多いんで、内部的には4KiBだけど外面は今まで通り512byteな奴らが出てきました。
でもその関係でなんも考えずに従来通りのパーティション切りをしてると、書き込み性能が低下することがある問題が発生しました。
これ以上詳しい話はこちらのエントリをご覧ください。
そして今まさにその状態なわけです。

さて、そうすると、まず何をしなければならないか。
今のHDDの内訳を作ろう。

sda – ST2000DL003-9VT166
sdb – ST2000DL003-9VT166
4KBセクタ
/bootをミラーリングで構築
各種システムパーティションをLVMミラーで構築
各1.5TずつファイルサーバのRAID5へ組み込み

sdc – WDC WD10EADS-00M2B0
非4KBセクタ
バックアップ用

sdd –  WDC WD15EADS-00P8B0
sde – WDC WD15EADS-00S2B0
sdf – WD15EARS
sdfが4KBセクタ
ファイルサーバ用でRAID5くんでる
このうちsdfは不良により現在失踪中

んーと。
とりあえずRAID5が致命的にやばそうなんだが。。。
sdaの状態を確認してみる。
単位はシリンダじゃなくてセクタに変更してある。

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63      546209      273073+  fd  Linux raid autodetect
/dev/sda2          546210   976751999   488102895   8e  Linux LVM
/dev/sda3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

はい、第一、第二パーティション開始セクタが8の倍数じゃないですね。
んーと。
sda1の開始位置を64にして終了位置を546199に
sda2の開始位置を546200にして終了位置はこのまま
とかやれれば良さそうだ、とりあえず。
ところで今までresize2fsとか結構やってきたけど、それで変わるのってパーティションの終了位置なんだよね。
開始位置の変え方を知らないことに気がついた。

で、resize2fsのmanページにこんなことが書いてある。

resize2fs プログラムは、パーティションのサイズは操作しない。 ファイルシステムを大きくしようとする場合は、 そのファイルシステムがあるパーティションのサイズを大きくできるかを 最初に確認しなければならない。 これは、 fdisk(8) を使ってパーティションを削除した後に より大きなパーティションを再作成することで確認できるし、 論理ボリュームマネージャ lvm(8) を使っている場合は、 lvextend(8) を使って確認できる。 パーティションを再作成する場合、 必ず以前と同じ開始ディスクシリンダで作成すること! そうしないと、サイズ変更の操作は絶対にうまく行かず、 ファイルシステム全体を失ってしまう。 fdisk(8) を実行した後、resize2fs を実行すること。 これにより、ext2 ファイルシステムのサイズを変更し、 拡大した新しいパーティションの全ての領域を使うことができる。

あ、はい。
要するに、一回ファイルシステム消せってことですね、わかります。
とりあえずRAID5の構成要素である第3パーティションはふれないでいいのは幸いだった。
ほんと1/8の偶然。

ということでまずシステムのバックアップとる。
sdb1, sdb2のパーティションを切り直す。

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048      546199      272076   fd  Linux raid autodetect
/dev/sdb2          546200   976751999   488102900   8e  Linux LVM
/dev/sdb3       976752000  3907024064  1465136032+  fd  Linux raid autodetect

再起動。
死んだ。
LVMボリュームがみつからねーっていわれた。
ブートしない。
さすがに無茶だったか。
LVMのミラーリングってじゃあ役に立つのか?
どうせミラーリングするんだからmdにしてしまいたいな。
まあ、この展開になったならもういいわ。
レスキューモードに入ってsda1とsda2のパーティションもぶった切る。
ということでぶった切り。
sda2もLVMじゃなくてLinux RAID autodetectに変更。
で、論理ボリュームとかぼこぼこ削除していったら、vgremoveがうまくいかず、vgreduce –removemissingをしてみろてきな。
あれ、もしかしてこれやれば良かった?
でももうおそい、あとには引けない。
削除。
そして綺麗に掃除したあと、アレイを作り直す。

# mdadm --create /dev/md1 -l1 -n2 --metadata=0.9 /dev/sd[ab]1
# mdadm --create /dev/md2 -l1 -n2 /dev/sd[ab]2

md1にファイルシステムを作ってバックアップを流し込む。
md2はLVMに。

# pvcreate /dev/md2
# vgcreate ms09 /dev/md2
# lvcreate -L 32G -n ms09 ms09

あとはmke2fsしてバックアップから流し込む。

これでとりあえずsdaとsdbはおっけー。

と思ったら起動しない。
grub loading
error 17
でました。
update-grubでいけるかと思ったけど駄目だったのでインストールし直す。
grubの画面までいくようになったけど今度はカーネル選択するとUnknown filesystemでマウントできないっていってerror 17。
レスキューから確認するとmd1がsdb1の方肺になっててgrubはsda1(hd(0,0))みにいってたっていうことでした。
まじね。
ということでmdadm /dev/md1 -a /dev/sda1して同期かけてgrubコマンドで確認して認識したので再起動。
漸くブートきたと思ったら、rootファイルシステムがみつからねーよっていうかmdadmでRAID ARRAY起動失敗っつーてこける。
きてる、きてるよくそはまりパターン。
んーと、なにをやりのがしてる?
んー、initramfsか?initramfsだろ。

update-initramfs -uk ‘all’

と。
はあ、やっと起動した。

とりあえず一旦ここで休憩。

mdadmでRAID5構築

LinuxでソフトウェアRAID5をくむならmd使うことになるわけで、作った。
色々と問題があったんだけども。

とりあえず、LVMと組み合わせようかとも思ったけど、組み合わせたところでメリットが見あたらなかったので今回は普通に構築した。

まず、RAID5に利用するパーティションを用意。
今回は1.5Tのパーティションを5つ。
sda3, sdb3, sdd1, sde1, sdf1
である。
パーティションタイプは0xfd(linux RAID auto detect)。
で、

# mdadm --create /dev/md2 --verbose --level=5 --raid-devices=5  /dev/sd[ab]3 /dev/sd[def]1

で最初作ったんだけど、アレイのリビルドが異常におそい。
4M/sくらいとか。
8000分以上とかなめてんの。

[>....................] resync = 1.6% (23715200/1465134592) finish=8221.9min speed=2921K/sec

チャンクサイズの問題だろうと思ったんだけど、まあ一旦構築したアレイのチャンクサイズは変更できないぽい。
ということで、チャンクサイズを指定して作り直す。
細かい容量なんて気にしないでどんと1024指定。

# mdadm -S /dev/md2
# mdadm --create /dev/md2 --verbose --level=5 --raid-devices=5  --chunk=1024 /dev/sd[ab]3 /dev/sd[def]1

当然作り直したらファイルシステムもなくなっていた。
まあ仕方ない。
これでいいだろう、と、様子をみてみると、なぜか一本スペアマークがついている。

md2 : active (auto-read-only) raid5 sdf1[5](S) sde1[3] sdd1[2] sdb3[1] sda3[0]
      5860536320 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [5/4] [UUUU_]

んーと。
とりあえずメタデータを掃除してやろう。

# mdadm -S /dev/md2
mdadm: stopped /dev/md2
# mdadm --misc --zero-superblock /dev/sda3
# mdadm --misc --zero-superblock /dev/sdb3
# mdadm --misc --zero-superblock /dev/sdd1
# mdadm --misc --zero-superblock /dev/sde1
# mdadm --misc --zero-superblock /dev/sdf1
# mdadm --create /dev/md2 --verbose --level=5 --raid-devices=5  --chunk=1024 /dev/sd[ab]3 /dev/sd[def]1

今度はうまくいったようだ。

# cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md2 : active (auto-read-only) raid5 sdf1[4] sde1[3] sdd1[2] sdb3[1] sda3[0]
      5860536320 blocks super 1.2 level 5, 1024k chunk, algorithm 2 [5/5] [UUUUU]
        resync=PENDING

md1 : active raid1 sda1[0] sdb1[1]
      272960 blocks [2/2] [UU]

ということでアレイの情報を/etc/mdadm/mdadm.confに記述する。

# mdadm -Ds | grep md2 >> /etc/mdadm/mdadm.conf

mdadm.confにDEVICEの記述がないなら

DEVICE partitions

とでも記述しておけばいい。
個別に記述しても良いけどめんどくさい。

あとは普通にmke2fsとかしてファイルシステムを作ってfstab書いたりして使えばOK。

リビルドの速度は10倍になった。

[>....................]  resync =  2.4% (36325084/1465134080) finish=557.6min speed=42699K/sec

ブートパーティションをミラーリングする

mdadmを用いてブートパーティションをRAID1で運用するように切り替える。
既存運用の/bootをsda1, 新規追加パーティションをsdb1とする。
とりあえずやる前に/bootのバックアップはとっとこね。

ということでまずsdb1をレイドアレイとして構築する。
まず、fdiskでsdb1のパーティションシステムIDをLinux raid auto(0xfd)に設定する。
やり方がわからなかったらぐぐろう。
そしraidアレイを構築する。
(結論から言うとこれにさらに –metadata=0.9 のオプションが必要だった)

# mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb1

構築できたら情報をmdadm.confに記録する。

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

/etc/fstabのを環境に合わせて修正。

/dev/sda1 /boot ext3 defaults 0 2
から
/dev/md1 /boot ext3 defaults 0 2
みたいな

initramfsの更新。

# update-initramfs -k all -ut

必要があればgrub関係の修正をしてupdate-grub。
(rootデバイスがmdになる場合など)

sdb1だけで構築されている方肺のmd1にファイルシステムを作成して/bootの内容を移す。

# mke2fs -t ext3 /dev/md1
# mount -t ext3 /dev/md1 /mnt/temp/
# cp -pr /boot/* /mnt/temp/
# umount /mnt/temp

最後にsda1をRAIDに追加する。

# mdadm --add /dev/md1 /dev/sda1

fdiskでファイルシステムIDもfdに変えておく。
でいけるかと思ったんだけども、error 2が発生して起動しない。
grubをMBRに再セットアップしようとしてもfilesystem type unknownと言われたりしてうまくいかない。
果てさて、どうしてこうなった。

ということで調べていたらこんな記事を見つけた。
同じ現象だ。
要約すると、mdadmで構築するRAIDのメタデータのバージョンがデフォルトだと1.2だけど、grubは1.2に対応してないから0.9で作ろうね、っていうことらしい。
ということで、RAIDを構築する時のオプションに –metadata=0.9 を付け加えてやり直した。
いけた。
罠すぎた。

既存のパーティションをミラーリングする方法

すでに運用に入っているパーティションをミラーリングする方法。

一つは、LVMで運用されているならlvconvertで簡単にできる。
普通にext3なんかのパーティションの場合はどうするか。
sda1, sda2がすでに運用に入っていて、sdb1, sdb2をミラーリングディスクとして追加する例を考える。

ここではmdadmを使うことにする。

で、今回の作業の流れ。

  1. ブロックデバイスの作成
  2. 新規追加するディスクを方肺でミラー化
  3. 既存運用のディスクからデータを移行
  4. 既存運用のディスクをRAID1に参加

ということでブロックデバイスの作成。

# mknod /dev/md1 b 9 0
# mknod /dev/md2 b 9 1

sdb1, sdb2はsda1, sda2と同じサイズでパーティションを切る。
パーティションのタイプはsda1, sda2も含めてすべてfd(Linux raid autodetect)にする。
で、新しく追加する方のディスクを方肺でミラー化する。

# mdadm --create /dev/md1 --level=1 --raid-devices=2 missing /dev/sdb1
# mdadm --create /dev/md2 --level=1 --raid-devices=2 missing /dev/sdb2

ミラー化したら、ファイルシステムを作成して、既存運用のディスクからデータを移行する。
この辺は/dev/md1, md2をmkfsしてsda1, sda2からmd1, md2にデータをcpする。

コピーが終わったら、元のディスクもミラーリングに参加させる。

# mdadm --add  /dev/md1 /dev/sda1
# mdadm --add  /dev/md2 /dev/sda2

っていう感じだろうか。