【カッパドキア】memories 2.0建造委員会２【過去ログ倉庫】
■ このスレッドは過去ログ倉庫に格納されています
２ちゃんねるの過去ログを一手に引き受けている
oyster902.peko.2ch.net+sumaもデビューから３年。
1.5TBのストレージはそろそろ満杯だし、フロントエンドも結構いっぱいいっぱい
そろそろ次の過去ログ倉庫を作らないとまずいなぁ・・・・
ってことで、RAID 6 8TBのbanana3000.maido3.comを作ってるんです
開発日記
http://www.maido3.com/server/zousan/
お姿
http://www.maido3.com/server/ebanana/
転送量グラフ
http://traffic.maido3.com/jfj1/McNh/nXAg/
■ ぞうさんからのお知らせ part1
http://qb5.2ch.net/test/read.cgi/operate/1197634004/l50
--------------------------------------------------------------
ここまでのお話
いよいよその姿を現した「ぞうさん（花子）banana3000.maido3.com」
しかし、過酷な試験に花子はくじけてしまいそうなのだった。
負けるな花子、がんばれ花子！ >>287
いや、そうすれば自動でいくんじゃないかなと。
u0 の中にホットスペアがあることがわかっているわけで。
そしてそれは、オペレータが「自動にしてもいい」時にする設定項目のような気がします。
これは直感というか、多分にコントローラの気持ちになってしゃべっていますが。 あと
1 一本抜く
2 ホットスペア起動→リビルド開始
3 リビルド中にホットスペア追加（が成功したとして）
4 更に一本抜く
どうなる？(^_^;)とか・・・・
ここいらあたりまでは確認したい。 >>287それが重要だとは思ってないけど、重要なら仕方ないね。
>>288ホットスペアはＲＡＩＤのunitの外部にあるんじゃないかと思うんだが・・・つまりスペア指定されたunitの所属 >288
なるほど(^_^;)
ちと考えます。
いや、だいたいの方向は決めてるんだけど、熟考するところなんで。
おおざっぱな思考
・現状で（いくつかの動作試験は残っているものの）要求を満たす動作をしている
・自動でホットスペアを動かすことで得られるメリットとデメリットはよくて±０
・自動でホットスペアを動かすための仕組みつくりと、その実証は結構大変（しかもできるかどうかもわからない）。
そうしなければならない強い理由があればやらないと・・・・って感じですね(^_^;)おいら的に
今、最優先でやりたいのは
「実際の運用上知っておかなければならないことの体験」と思います(^_^;) 不良クラスタ続発でハネたドライブがフォーマットされちまって再び登場。
ってのがホットスペアとして待機してたって経験が一度ある。
在庫ドライブの無い時に担当者が勝手にやった。
新品だから安全って事は無いんだけどー >>290
> >>288ホットスペアはＲＡＩＤのunitの外部にあるんじゃないかと思うんだが・・・つまりスペア指定されたunitの所属
なるほど、、、3wareのはそうなるですか。
私が本業方面で昔触ったやつとかoyster902についているSumaとかは、
確かそうではなかった記憶があるです(手元にマニュアル無いのでうろ覚えですが)。
>>291
「体験が重要」には同意です。
Experience の値を上げる方向で。
あと、自動でやるにせよやらないにせよ、
ヒューマンエラーを防止する策については、くれぐれもというかんじで。 >>292投入チェックの時に自動で調べてくれないんだ・・・それは怖いな。
＞新品だから安全って事は
昔のＩＢＭで初期不良率４０％とかいう記録が残ってんのを見たことがあるｗ
だから差し替えたら全部書き込みチェックするもんだとばかり・・・（´･ω･`）ｼｭﾏｿ ディスク挿入したらメディアスキャンぐらいは、かかるんじゃないですかね。
もちろん設定次第ですが。 Unit 1 を設定し、ホットスペアとしてHDD#1が認識された(^_^;)
//banana3000> info c0
Unit UnitType Status %RCmpl %V/I/M Stripe Size(GB) Cache
AVrfy
------------------------------------------------------------------------------
u0 RAID-6 OK - - 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 u1 465.76 GB 976773168 6QG14N85
p2 OK u0 465.76 GB 976773168 6QG11Z7M
p3 OK u0 465.76 GB 976773168 6QG15ZP5
p4 OK u0 465.76 GB 976773168 6QG16SGK
p5 OK u0 465.76 GB 976773168 6QG15EYR
p6 OK u0 465.76 GB 976773168 6QG16SAM
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>
Unit Maintenance (Controller ID 0)
Unit 0 15 drives RAID 6 5.91 TB OK
Port 14 ST3500630AS 465.76 GB OK
Port 13 ST3500630AS 465.76 GB OK
Port 12 ST3500630AS 465.76 GB OK
Port 11 ST3500630AS 465.76 GB OK
Port 10 ST3500630AS 465.76 GB OK
Port 9 ST3500630AS 465.76 GB OK
Port 8 ST3500630AS 465.76 GB OK
Port 15 ST3500630AS 465.76 GB OK
Port 6 ST3500630AS 465.76 GB OK
Port 5 ST3500630AS 465.76 GB OK
Port 4 ST3500630AS 465.76 GB OK
Port 3 ST3500630AS 465.76 GB OK
Port 2 ST3500630AS 465.76 GB OK
Port 7 ST3500630AS 465.76 GB OK
Port 0 ST3500630AS 465.76 GB OK
Unit 1 1 drive SPARE 465.75 GB OK
Port 1 ST3500630AS 465.76 GB OK
Available Drives (Controller ID 0)
NO DRIVES
>293
＞ヒューマンエラーを防止する策については
ここですよね(^_^;)はい
いずれにしても自動化についてはもうちっと考えて見ます
つーか、おいらしか抵抗してないってことは自動化するのが普通なのかな？(^_^;) 今悩むのはナンセンスかと、
両方できるようになってから悩むべし >>297ﾓﾚは、管理のヒューマンエラーより現場のヒューマンエラーの方が単純で頻度が高いんで、現場での人間の作業はなるべく減らした方がいいという見解。
何せ現場だと常に時間が無いから、担当者が軽いパニックに陥り易い。順番間違えとか処理忘れとか確認忘れとかｗ
ミスが凡ミスのわりに事態が深刻になるからね。可能な限り機械にやらせるべきだと思ってる。
やることが赤ランプのディスクを抜いてゴミ箱（不良ボックス）に捨て、新規ディスクを持ってきて差すというだけなら、並や大抵の馬鹿ならミスは起こせないでそ
で、そのまま待機室に戻っても、チェック後にまた使えないディスクを交換汁メッセージが入ってきて同じことを繰り返すｗ
>>298でも自動化するなら、自動化に必要になりそうな実験のフルログを今のうちにチェックしておかなきゃならないわけで・・・ >298
んだすな(^_^;)
ここまでにできたこと
・１本抜いたときの振る舞いの確認
・２本目抜いたときの振る舞い確認
・３本目抜いた時の振る舞いの確認
・４本目抜いてしまった時の振る舞いの確認(^_^;)
・逆手順の振る舞いの確認
・ホットスペアの復旧手順の確認 腹回りと言われなかっただけ、マシなんじゃないかと。 マァヴだって昔はアレだったんだぞ！きっと、多分…もしかしたら…… http://www.maido3.com/server/zousan/nikki3.html
＞(^_^;)：「おおっ、1号機(manidame)よりも凄く安定しているぞっ！」
まにだめｗｗｗｗｗｗｗｗ まにだめﾜﾛﾀ
てか、誤字をよく見かけるｗプレスリリースとかにもあったような なんか、mamonoと何度か入力してたせいで手が自然にmaと入力してしまっているきがする ＿＿ _
／ ．＼__ノ )
（＿ノ ﾌ__,ノ
ﾉ ( ´∀`)
/ 凵 |コ
(. ｌ
∪､, _ ,,ノ
凵 凵 さしずめ、百式は桃か。名の通り魔物か。
この連休、花子の調教も無さそうだし、余興、余興。 VIPをyutoriへ移転させないのかな。
年末年始、とくに年越しのVIPに対応するためという意味も持たせて百式作ってたような気がするんだけど。 確か進捗状況は
抜き差しのテストも終わって、ホットスペア追加等の手順も分かった
しかしSumaのようにガチャポンだけで行けないけどどうするよ？
ってな感じだったかと
負荷がかかっている状態でのテストは済んでいますが
この先もテストをする必要があるかどうかは、情勢によって変わるでしょう。 このあとの予定(^_^;)
あと１つだけ実験やります。予定は明日午前中。
1 一本抜く
2 ホットスペア起動→リビルド開始
3 リビルド中にホットスペア追加（が成功したとして）
4 更に一本抜く
どうなる？(^_^;)
これが終わって、１６本すべてが所定の状態に戻ったら実験終了です。 マァヴさん
2つほど質問させてください
・実験中、サーバーは停止しますか
・今回の勝算はいかほどでしょうか >337
・停止するかもしれないししないかもしれない(^_^;)それを確認するための実験だし
・勝算って、どうなったら勝ちなんだろう？(^_^;)動作を確認できればいいわけなんで、勝ち負けはないと思う 停止どんとこい
VIP931で他に行けない奴らが鯖落とされたらどうなるか
いとをかし >>338
回答ありがとうございます
実験の趣旨をよく理解してませんでした、ごめんなさい
実験が成功するよう願っています 本日の実験結果(^_^;)
やること>336
初期状態
UNIT0 ０-２-３-４-５-６-７-８-９-10-11-12-13-14-15
UNIT1 １ （ホットスペア）
#2を抜いた
UNIT0 ０-2X-３-４-５-６-７-８-９-10-11-12-13-14-15
UNIT1 １ （ホットスペア）
ホットスペアが起動し、#1のリビルドが始まった
UNIT0 ０-1R-2X-３-４-５-６-７-８-９-10-11-12-13-14-15
抜いた#2に新品のHDDを入れ、ホットスペアに設定（#1のリビルドは進行中）
UNIT0 ０-1R-３-４-５-６-７-８-９-10-11-12-13-14-15
UNIT1 ２ （ホットスペア）
#3を抜いた（#1のリビルドは進行中）
UNIT0 ０-1R-3X-４-５-６-７-８-９-10-11-12-13-14-15
UNIT1 ２ （ホットスペア）
ホットスペアが起動し、#2のリビルドが始まった(#1と#2のリビルドは平行して進む)
UNIT0 ０-1R-2R-3X-４-５-６-７-８-９-10-11-12-13-14-15
抜いた#3に新品のHDDを入れ、ホットスペアに設定(#1と#2のリビルドは進行中
UNIT0 ０-1R-2R-４-５-６-７-８-９-10-11-12-13-14-15
UNIT1 ３ （ホットスペア）
今ここ(^_^;)
毎回ホットスワップの場所変わるの？
エラーランプとか無いみたいだし交換要員が間違ったりしないのかな？ わかったこと
１ 障害が発生し、ホットスワップが起動したら、障害HDDを新品に交換し、ホットスワップに設置できる
２ リビルド中に新たな障害が発生しても、ホットスワップがあれば機能する
ということで
「実行されているリビルドが２つ以下ならば、故障したHDDをホットスワップ化する」
ことで、連続した障害に対する耐性を向上できることが判明(^_^;)
ただし、現状（つまりリビルド２つ＋ホットスワップ）では冗長性は０です。 >343
毎回変わります(^_^;)
ランプは点灯しない（というかない）ので、デッキ番号とポート番号で管理します。
デッキ番号とポート番号は一致しています。 >346
実験はこれで終了ですー(^_^;)ってことでいよいよ本題の「memories 2.0建造」かな？ 現在まだリビルド中(^_^;)ちょいと待ってね
RAIDアレイがすべて平常に戻って、予備HDDがすべて準備完了したら終了宣言の予定 お。お。お。お。（ ＾ω＾）
いよいよ本編スタート お疲れ様です
実験は大成功だったようで、喜ばしいことです
花子のささやきも働いていて心強いですね
２．０いよいよ始動ですか 今回は予測通りの動きを示しました(^_^;)
予想外だったのは、リビルドが２つ平行して進む点。
よくできてます＞花子 >>351
> 予想外だったのは、リビルドが２つ平行して進む点。
ふむー。RAID 6だからってことですかね。 >352
RAID5では二つてこと自体発生しないわけで(^_^;)その状況では破綻してるし
RAID6の実装として、一台づつ順次リビルドではなくて、両方同時にリビルドするようになっているようです。
どっちがいいのかっていうと、一台づつのほうが、冗長性+1に速く到達する気もするんですが(^_^;) 1TBのデータ転送、気が遠くなるくらい時間かかりそう。 なるほど、rebuild の間は wait するんじゃないか、って思っていたということですか。>>353
その動作はなんとなくですが、configurable な気がします。
設定を変えるかどうかは別にして、マニュアルをあたっておくといいかも。 >355
あいあい(^_^;)確認します
とはいえ、現状で満足な状態なので、あえて１台づつモードは目指しません
原則、デフォルト（つまりメーカー推奨）を使いこなします。 >>353原理的に０→＋１→＋２よりも０→＋２の方が、ざっと40%程度早いです。
０→＋１と０→＋２の差はだいたい6%ぐらいしかないはずなので、気にするほどではないと思われます。 >>356
> とはいえ、現状で満足な状態なので、あえて１台づつモードは目指しません
はい、それで問題ないと思います。
>>357
ほほう。 さて、次のアクションは、、、。
memories2、本格スタート? 記憶では、
1) システムディスクどうしようか
2) 使ってないネットワークカードが入ってるみたいだけど・・・
3) 長く使い続けるものだから当初から 64bit化、4G mem化 したほうがいいんじゃね
ぐらいが課題として出ていたはず。 >>366
で、
1) は、あえてこのままいく、という手もあるかな、という話をしていたと思います。
もちろん他の T-banana 同様に RAID 1 にするのもありだと思います。
2) は、気にする必要はないでしょう。
3) は個人的には、やっておきたい気がしますね。 ドライバーとかがちゃんとあるんだろうか・・・64bit >>368
twa の amd64 用ドライバがあるのは確認済です。 HDD大量に積んでるから、エアフローとか考えても
不必要なカード類は外した方がいいんじゃね？ 作業完了予定(^_^;)明日の正午
残り作業
・予備HDDのフォーマット
花子自身は完璧に動作しています(^_^;) >>371
ハードウェアの予備体制も含め、明日正午にて準備完了と。
ということは、このまま過去ログ倉庫として2chにリリースする、
ということでおｋなのかしら。 仕様はこのままで行こう。
つまり再インストールとかはなし、当然32bitのまま
ん? 64bitじゃなかったっけ? >>372
その方向でここで話し合いをつつけたいなと、 >>373
今は32bit版ですね。
banana3000:~$ uname -m
i386 一回も落ちずにいい仕上がりだと思うな
堅牢そのものに見える。 現在のスペックは、
標準T-banana - (250G HDD x 2) + 80G HDD + Realtek Network IF x 2
+ (RAID card + 500G HDD x 16)
ということになりますね。
標準T-bananaと同じ、メモリは2Gで、32bit版ということになるです。 へへへ(^_^;)おいらもそう思います
で、システムディスクですが・・・・
１RAID 1にする
２RAID 6にユニークデータを置いて、システムディスクはいつでも入れ換え可能にする
３RAID 6にユニークデータのコピーを置いて、システムディスクが壊れたら、そこを読み出せるようにして復旧させる
４このままでいく
５もっと凄いアイデアを考える
３が一番手っ取り早い上に、確実な気がします(^_^;) >>377
システムディスクがふっとぶリスクは旧banana程度にはあると思いますが、
その時には単純に HDD 交換(その間は収容している過去ログが見られない)
ってことですね。
RAID 6 のほうは、
ちゃんと設定ができてからは、きちんと動いている様子。 >>380
2 と 3 の違いは、、、。
symbolic link する、ということかしら。
だとすると、あんまりおすすめできないですね。
RAIDカードに異常が発生すると、復旧作業がしにくいです。
直感的に、1 か 3 じゃないでしょうか。 >383
ですです(^_^;)方法論は色々あるかもだけど
ユニークデータをRAID 6上に配置して、そこから読み込んで動くってことです。
というかきっと、
A) 1 と 3 の組み合わせ
B) 3
のどっちかがいい気がしますね。
1 と 2,3 は互いに独立な手法ですから。 くらべてみると(^_^;)
１のメリット
既知の手法（T-bananaで経験済み）
１のデメリット
両方ふっ飛ぶことがある(T-bananaで経験済み)
３のメリット
RAID1より堅牢である
現状から改変が不要
３のデメリット
始めてやることである
１に比べて復旧手順がちょっと複雑 ■ このスレッドは過去ログ倉庫に格納されています
