去る21日の水曜日、Linuxで運用しているサーバで運用していたソフトウェアRAID1構成アレイの1HDDが故障しました。
今回は珍しく、使用中の突然死でした。
故障したHDDは前任のWD製(WD10EADS-00L5B1)が情けなくもたった2年弱で故障したため、シーゲートから我が家に2011年3月に颯爽とデビュー。彼|彼女の名前はST2000DL003。
故障直前までSMART情報も異常がなく、毎週の過酷なRAIDチェックに堪え、6年も連日の酷使に堪えてくれました。
故障第一報は以下でした。
Jun 21 04:20:23 hostname kernel: ata2.00: exception Emask 0x50 SAct 0x60000 SErr 0x4090800 action 0xe frozen突然まったく応答がなくなるという死に方でした。
BIOSからも見えないし、まさしくピンピンコロリ。見習いたい。
長い間どうもありがとう。
死んだHDDは、ペアを組んでいるもう一台のHDD(これもseagateのST31000528AS)が2009年デビューなので、古いほうが死んだらアレイサイズを拡張しようと目論見、元のアレイサイズの倍の製品を購入したのですが、期待むなしく新しいほうが先に故障してしまいました。
余っている領域でTSﾌｧｲﾙのエンコードをしていたので(といってもタモリ倶楽部なんですが)、その負荷が祟ったのかもしれませんし、搭載していたPRIMERGY TX1310M1のHDDスロット中で最も温度が高くなる位置に設置していたのも要因かもしれません(死んだHDDの過去一か月の平均温度は36.37度、ピーク時41度でした。相棒の平均温度は27.48度、ピーク時32度ですので確かに故障率が高まります)。
まあ、生き残ったほうもそろそろお迎えが予期されますし、アレイ上のファイルシステムも過去にext2からext3にしたままだったので、この際、アレイの再構築ではなく新HDDで新規に構築し、ファイルシステムもxfsを採用することにし、パーティションテーブルもMBRからGPTに変更して、前世紀から引きついで来たアレイを引退させることにしました。まあ、2TBを超えたらもうGPT一択なんですが。
fdiskも最新版はGPTに対応し始めているのですが、残念ながらまだ実験段階ですので、今回はpartedを使用してパーティションを切ります。
具体的には以下のようにします。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | # parted /dev/sdbGNU Parted 3.1/dev/sdb を使用GNU Parted へようこそ！ コマンド一覧を見るには 'help' と入力してください。(parted) mklabel gpt(parted) mkpartパーティションの名前? []? SDB1ファイルシステムの種類? [ext2]? xfs開始? 0GB ←開始と終了に単位をつけるのがミソ終了? 100%(parted) set 1 raid on(parted) pモデル: ATA ST3000DM008-2DM1 (scsi)ディスク /dev/sdb: 3001GBセクタサイズ (論理/物理): 512B/4096Bパーティションテーブル: gptディスクフラグ:番号 開始 終了 サイズ ファイルシステム 名前 フラグ 1 1049kB 3001GB 3001GB SDB1 raid |
また、fdiskではソフトウェアRAID自動構成の場合はパーティションIDに0xfdを指定しますが、その代わりにpertedではset 1 raid onと指定してあげてください。
続いて、アレイを構成します。
1 2 3 4 5 6 7 8 9 | # mdadm --create /dev/md1 --level=1 --raid-device=2 /dev/sd[bc]1mdadm: Note: this array has metadata at the start and may not be suitable as a boot device. If you plan to store '/boot' on this device please ensure that your boot-loader understands md/v1.x metadata, or use --metadata=0.90Continue creating array? ymdadm: Defaulting to version 1.2 metadatamdadm: array /dev/md1 started. |
途中で何か聞かれますが、このアレイからはブートしないので何でもいいので、yと入力して質問をかわします。
アレイが落ち着くまで4~5時間かかりますが、進捗状況は/proc/mdstatで確認できます。
落ち着いたら、mkfs -t xfs /dev/md1でファイルシステムを作成後に従来のRAID1(ここではmd0)からrsync -avhして移行が完了です。
その後、従来のRAID1の代わりとするので、現状のmd1から従来のmd0に名前を変更するため、
1 2 3 | # mdadm --detail --scanARRAY /dev/md0 metadata=0.90 UUID=(略。こちらが古いほうの設定)ARRAY /dev/md1 metadata=1.2 name=hostname:1 UUID=(略。新しいほう) |
として得られた内容のうち、デバイス名(md0とmd1)を逆にして/etc/mdadm.confに記録して,fstabのmd0のマウント設定をext3からxfsに変更、sync;syncしてrebootして終了です。
手順そのものはいたって単純、どうということはありません。
ただ、アレイの構築と内容のコピーにやたらと時間がかかります。
手順そのものはいたって単純、どうということはありません。
ただ、アレイの構築と内容のコピーにやたらと時間がかかります。
それにしても富士通のTX1310M1のメンテナンスの楽さはつくづくありたがいです。
横に回ってレバーを引いて側板を開けて取っ手を引いてHDDを取り出すだけ。
設置場所から取り出してドライバーを振り回してねじをあけ・・・といったような面倒なHDDの交換作業があっという間に終わってしまうのは本当に助かります。
ここからやっと表題の件に入ります。
で、今回デヴューしてもらったのがシーゲート製ST3000DM008。それも2台。
ハアッ、バカジャネーノ?という声が聞こえてくるような気がします。
というより自分でそう思います。
そもそも同一型番のHDDでアレイを構成するのは故障時期が重なる可能性、故障時に見分けがつきにくいためいかがなものか。
加えてこのHDD、猛烈な故障率で超有名なST3000DM001の型番だけ変更した製品じゃないかといううわさがある曰く付きの製品です。その故障率は驚異の32%。
3台に一台が壊れるという偉業を達成した製品の後継で、かつ単なる型番変更品かもね、というのになぜ買うのか?普段だったら絶対こんなことしないのに!?
だって\7,480だったんだもん。
それに、なぜか昔からうちはシーゲートさんを採用する決断をすることが多いんです。
多分その時々で様々な理由があったんでしょうが、今回は欲に駆られての採用となりました。
まあ、WDや買収前のHGST、東芝のHDDも運用中なんですが、大昔にシーゲートのHDDを米国にRMAで交換するために送ったときの対応の良さもあって、無意識に信頼しているのかもしれません。
気づいたら容量が小さくて使わなくなったHDDも含めてシーゲート製がむやみにある始末です。
運送会社Sさんにより納期が延びたというちょっとしたヒューマンエラーはありましたが、HDDにはとりあえずはいきなり認識できないというトラブルもなく、ネットワーク越しのファイルコピー(samba)でもGbEの転送速度上限に張り付くパフォーマンスを見せてくれています。
まあ、その代償として、回転数が7200RPMとなっているためでしょうか、当環境下ではHDDの温度が3~5度ほど従来より高くなっている様子が見えます(以前は5900RPM)。
TX1310M1の構造上、(私はケチなので設置しますが)風が当たらない第2スロットはできるなら使用しないほうがいいと思います。
SMARTの自己診断(これもえらい時間がかかります)も幸い正常終了したので、まずは出だしとしては順調です。
初期不良の心配はかなり減ったので、果たして本当に001の型番変更品なのか、そしてその驚異(脅威?)の故障率を身をもって体験する栄誉にあずかることができるのか。
楽しみです。
0 件のコメント:
コメントを投稿