| ■ 【ぷろじぇくと ぞうさん】 〜E-Bananaサーバ 構築日記〜
|
第７３日目：【花子】コツコツとリビルド実行中です・・・
|
どうも、('A`)です。
今日は短めの日記になりますが、ちょっと報告を。
先週末の社員研修という名の「強化合宿」から無事帰ってきました。
ふだんはそんなに気にならないのですが、あまり体を使っていないんだなあ、という事が
いろんな所で改めてひしひしと感じました。。。
(少し体を鍛えないとなあ・・・)
サーバ達も順調に稼働していましたが、唯一「花子」(banana3000)だけがぐずっていまして。
どうも0番〜15番まであるHDDのうち、6番が壊れました。
しかも、たちの悪い事に、完全に壊れたのなら、ホットスペアと切り替わって切り離されて
隔離されるのですが、時々アクセスできる状態に戻ってしまうようで、何度も何度も
リビルドしようと処理が繰り返される、という動きをしていました。
「花子スレ」でも何度かメッセージが書き込まれていましたが、繰り返し同じ様な
メッセージだったので、「おかしいなあ」と思われた方も多いようです。
で、今朝(8/11：月曜日)の午前10時50分から以下の方法でおかしくなった6番HDDの
交換処理を行ないました。
その時の「花子」の状態遷移をスレ上のメッセージを使って以下で説明しますね。
1) 6番HDDが「DRIVE ERROR」で利用できない状態として認識される
589 ：花子 ★：2008/08/11(月) 10:51:22 ID:???0 ?PLT(15002)
3ware 3DM2 alert -- host: banana3000.maido3.com
20080811015117 - Controller 0
ERROR - Drive timeout detected: port=6
2) 6番HDDを本体から取り外す
590 ：花子 ★：2008/08/11(月) 10:52:54 ID:???0 ?PLT(15002)
3ware 3DM2 alert -- host: banana3000.maido3.com
20080811015246 - Controller 0
WARNING - Drive removed: port=6
3) すると「6番HDDが故障しているよー(degrated)」と認識される
591 ：花子 ★：2008/08/11(月) 10:52:54 ID:???0 ?PLT(15002)
3ware 3DM2 alert -- host: banana3000.maido3.com
20080811015248 - Controller 0
ERROR - Degraded unit: unit=0, port=6
4) するとホットスワップがRAID 6を構成しているユニットに追加され、
リビルド処理が始まる
592 ：花子 ★：2008/08/11(月) 10:53:54 ID:???0 ?PLT(15002)
3ware 3DM2 alert -- host: banana3000.maido3.com
20080811015351 - Controller 0
INFORMATION - Rebuild started: unit=0
5) 空になっている6番HDDに新しいHDDを差し込む
593 ：花子 ★：2008/08/11(月) 10:58:23 ID:???0 ?PLT(15002)
3ware 3DM2 alert -- host: banana3000.maido3.com
20080811015811 - Controller 0
INFORMATION - Drive inserted: port=6
|
なんでこんな事をしたのかと言いますと、ホットスワップとして待機している
HDDをRAID 6を構成しているユニットに入れる為に、6番HDDが「完全に壊れている」と
RAIDコントローラーに認識させないといけないからです。
先週末の時には6番HDDにアクセスできない(タイムアウトになる)状況が何度か発生
しましたが、HDDそのものはサーバ内に存在し、通電された状態になっていました。
その後「何故か良く判らないけれど」何度かのリトライ後にアクセスできた時に
「一時的にアクセスできなくなっていたみたいだから、改めて復旧かけておこう」と
RAIDコントローラーが認識し、6番HDDに対してリビルドが行われていました。
なので、ホットスペアはそのまま組み入れられる状態にならなかったのです。
で、 2) で行なった様に「物理的に」HDDを本体から取り除く事で、RAIDコントローラが
「ああ、6番HDDは"本当に"ダメになったのね。じゃあホットスワップを使いましょ」と
認識し、4) の処理が実行開始されるようになるのです。
4) の段階ではRAID 6本体は15本構成になりますが、ホットスペアは無い状態になるので
5) で新しいHDDを6番HDDのポートに差し込みます。
但しこの場合ただ単にHDDを差し込んだらホットスペアにはなりません。
日記の「ささやき作戦(第4、第7、第8日目 参照)」でも書きましたが、管理システム
(3dm2とか)を使って設定して、初めてホットスワップとして使える様になります。
で、リビルドの進捗状況はどうなっているか見てみますと・・・時間がかかっています。
(今日の午前11時〜午後3時の4時間で、約3%終了したところです。)
リビルド処理が全部終わるには数日かかる見込みです。
[15:30時点のリビルド進捗状況]
banana3000# tw_cli
//banana3000> info c0
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache AVrfy
----------------------------------------------------------------
u0 RAID-6 REBUILDING 3%(A) - 64K 6053.47 ON OFF
u1 SPARE OK - - - 465.753 - OFF
Port Status Unit Size Blocks Serial
----------------------------------------------------------------
p0 OK u0 465.76 GB 976773168 6QG15YS8
p1 OK u0 465.76 GB 976773168 6QG14N85
p2 OK u0 465.76 GB 976773168 6QG0T4RJ
p3 REBUILDING u0 465.76 GB 976773168 6QG0TLHT
p4 OK u0 465.76 GB 976773168 6QG16SGK
p5 OK u0 465.76 GB 976773168 6QG15EYR
p6 OK u1 465.76 GB 976773168 9QG3956R
p7 OK u0 465.76 GB 976773168 6QG15DFL
p8 OK u0 465.76 GB 976773168 6QG12MYG
p9 OK u0 465.76 GB 976773168 6QG12NSB
p10 OK u0 465.76 GB 976773168 6QG15YP4
p11 OK u0 465.76 GB 976773168 6QG14N7G
p12 OK u0 465.76 GB 976773168 6QG10SS5
p13 OK u0 465.76 GB 976773168 6QG14N66
p14 OK u0 465.76 GB 976773168 6QG14N34
p15 OK u0 465.76 GB 976773168 6QG10PGX
//banana3000>
まあ、RAID 6本体(記録可能領域：5.7TB)には約2.5TBのデータが格納されていますから
データの再編成及びパリティデータの再作成を行なう範囲は膨大になる訳で、時間が
かかるのは仕方が無いです。
Webサーバ(Apache)をオンライン状態にしていますが、たとえApacheを一時的に停止に
しても、たいして変わりません・・・
最近では動物園の飼育係の人たちと同じ様に「花子」とつきあっている心境です。
とりあえずはリビルド処理が終わるまで様子を観察しながら、気長に待ちます('A`)
で、それと並行してIPv6のお勉強を進めようかな、と思っています。
(人に説明するにも、どうもイメージがいま一つ掴みづらいところがあるので・・・)
まあ、お盆の時期を迎えますので、本屋巡りの時間もできるかなあ、と。
それでは、また。
[17:30 追記]
「IPv6のお勉強をしようかな」と思ったら、背後から(^_^;)が現れまして・・・
なんでも花子が最近頻繁にダウンしているから、そろそろ「改造」を考えないか、と。
で、今どこをどう改造すれば良いか、原案を考え中です。。。
ハードウェアもそうですが、ソフト(OS)の入れ替えもちょっと検討してみます。
あ、でも7.0Rのカーネルではドライバ(twa0)は標準に対応しているのかなあ？
ちょっと調べてみますが、誰か詳しい人がいたら、教えて下さい。
なお「改造」は何段階かに分けて、極力ダウンタイムが短くなる様に努力しますです・・・
[18:10 追記]
えーと、花子のリビルドの進捗状況を見ているのですが、結構時間がかかりそうです。
泣きたい位に遅いです・・・
今日のだいたい午前11時からスタートで、現在午後6時(つまり7時間経過)ですが、
全体の5%リビルドが終わったところです。
で、この進捗率を基にリビルド処理全体にかかる時間を計算すると、140時間とでます。
(5日と20時間です、ハイ)
とすると・・・リビルド処理が終わるのは日曜日(8/17) 午前7時頃になる
見込みです。あくまでも今のペースでリビルドが進めば、の話ですが。。。
まあ、花子自体は現在も正常にデータにアクセスできる状態ですので安心なのですが、
これから1日数回のペースで１週間観察を続ける必要が出てきました。
(何か小学校の頃のアサガオの観察日記を付ける感覚に陥りそう・・・)
[8/18 13:45 追記]
花子のリビルドですが、当初予定されたよりも早く、8/16(土) 17:02に完了しました。
(終了の際に、花子の方からスレ上に「ささやき」がありました。)
その後、昨日(8/17 日曜日)の13:47前後にセクタ修復の知らせが1度入りましたが、
現在は全HDD正常に稼働しています。御安心下さい。
それにしても、昨年末に花子のリビルド試験(「ささやき作戦」の事です、ハイ)の
時と比べると、結構時間がかかりました。
まあ、当時と比べると格納されているデータ量が違いますから、リビルドの際に
生成されるパリティデータや、細分化されたデータもかなりの量あったはずです。
ただ、時間がかかったとは言え、「サービスを稼働させた状態」でデータ復元できる
という事はとてもありがたい機能です。
引き続き花子については監視を続けます。これでしばらくは順調に稼働し続ける事を
願うばかりです。
|
|
|
|
|
72日目に戻る。 74日目に続く。
解析
|