【カッパドキア】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」
しかし、過酷な試験に花子はくじけてしまいそうなのだった。
負けるな花子、がんばれ花子！ 停止どんとこい
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より堅牢である
現状から改変が不要
３のデメリット
始めてやることである
１に比べて復旧手順がちょっと複雑 あと、思うんですが、
基本的には旧 banana サーバのシステムディスクだけがこわれた時の
リカバリーオペレーションと、
本質的には同じなんではないでしょうか。
単に、データディスクが堅牢になって、
容量がばかでかくなっただけではないかと。
そしてその際のリカバリー手法やノウハウはさすがに、
既に蓄積されているんじゃないですかね。 んじゃそれで(^_^;)
どっちにしても４から始まるわけだし
なにはともあれ４でスタートってことで >388
です(^_^;)
４の状態である間は、bananaと同じですー >>387
それでいきますか。
>>381 の第一段落の運用ポリシーでいくんであれば、
わたし的には特に異論ないです。 んじゃ >>387 でいこう。
始まりはあした。それまで特に反対意見が出なければ
memories2 は船出 !! 明日VIPがyutoriに戻る
でよろしいですか？ >>393
「かもね」くらいです。
大掃除、大掃除。 今のバーチャルホストを banana3000 に移したら、
旧 tiger/cobra 達は OS から入れ直して、
いよいよバックヤード系の旧 banana の置き換えにかかろうかと。
年始あたりからぼちぼちと。 ちなみにroot付き？ rootなし？(^_^;) お薦めはrootなしなんだけど（RAIDまわりの扱いがあるので）
過去ログ倉庫の建造ってやったことがないんで、ちと不安(^_^;) >404
あー、普通にアカウント作るだけでいいのか(^_^;)了解了解 なるほど、
そういうことであれば、なしでいいんではないでしょうか。
基本は同じです。
２ちゃんねるには土地を出していただければいいはず。
あとは収容班(私とか)が作業して、
支障があればここで調整でいいんではないかと。 で、ぱっと思いつくところでは、
ページビュー計測のところですね。
「２ちゃんねるセッティング」して土地を出すということは、
おのおののバーチャルホストごとにページビューが計測される、
というかんじになるですね。
今の memories では httpd.conf を少し細工して、
teri.2ch.net で全部のページビューが計測されるようにしているです。
バーチャルホストが将来、100とかのオーダーになってくると、
今のしくみだと100個、ログ処理プログラムが常駐することになるので、
ここのところは何か、考えておいたほうがいいかもです。
ということで個人的には memories2.2ch.net という、
それ用のバーチャルホストを作って、
ページビュー用のログはもっぱらそこでとられるようにする、
とかいう手法がいいのかもな、と思いました。
いずれにせよこのへんは、実際の収容段階での調整事項ということで。 過去ログが整備されたのなら、一番アクセスが多い過去ログランキングとか出してくれると
累計・年・月・日計ぐらいででると面白いかもー
あったらすまそ、 ちなみに今のmemoriesには、250個のバーチャルホストが収容されているです。 >>410
あぁ その計画もすすんでいるんだった。
スレどだったかぁ 予備HDD出来上がり(^_^;)全て完了ー
花子、完成です こういうことこそ”壷”で宣伝しなきゃ
先日のポストでも呼ばれたけど とついにVIP出戻りか〜ｗ
そして >>395 のイミがVIPの前に姿を現すｗ >>417
ということは、過去ログ収容用のアカウント作成依頼をしてもよい、
という話なんですかね。 >>424
了解です。
私のほうではまず一つ分収容作業をすすめてみて、
収容作業の流れを確立しようかと。
で、それより news4vip の移転が先の予感も。 ひとつ質問です。>>424
そろそろ年末年始休暇になると思うのですが、
アカウントの作成とかDNSの変更とかについては、
通常作業系としては、年内はいつまでおｋでしょうか。
1) 今日
2) 明日
3) その他 >426
28日(本日) 28:00までOK 18:30までなら大量に来ても大丈夫
29日 18:00-28:00までOK
2日 10:00-18:00までOK
４日以降は普段通りー(^_^;)
ちなみにアカウントを作ってDNS通す以外にやることありますか？
DSOのセッティング
/mdのセッティング
pv計測のセッティング
などなど >>427
了解です。
んでは、必要な土地だけ作っておきますか。
要領ですが、基本的にはバーチャルホスト引越しのときと同じです。
ただし、DNS変更を＊移動作業後＊にしていただけると助かります。
1) banana3000 上にアカウントを作成いただく
* アカウント名はこちらで指示します。
* 例えば game11 なら ch2game11 とかになります。
2) アカウントの準備ができたら、
アカウント情報をアカウント作成依頼者までお送りいただく
* ただしこの時点では、DNSの変更はしないでください。
3) 作成依頼者がログインできることを確認し、必要な中身をコピーし、
過去ログサーバとしてのセットアップをする
(dat落としとか、64bitサーバから移動する場合はバイナリCGIの入れ替えとか)
* この作業の前に、該当サーバへのF22/F35、Rock54丁稚どん等が止まっていることを確認しておくこと
4) 作業終了後、DNS変更依頼を出す
5) DNSが変われば、めでたしめでたし あいあい(^_^;)了解です
で、アカウントに施す特殊なセッティングは？ で、アカウント作成時のセッティング内容ですが、
・DNSはアカウント作成と同時には＊通さない＊(>>428 参照)
・dsoは通常通り設定いただく
・メモリディスクのセッティングは＊必要ない＊
・PV設定は通常通り設定いただく
で、おながいいたします。
以上、といった流れを考えております。 で、PVについては将来、何か考えたほうがいいかもしれないけど(>>409 参照)、
今はまず、たんたんとそのまま収容の方向ということで。 で、music8/tv11 の作業が終わったら、
土地作成をまとめて依頼しようかなと。 >>427
マァヴ、働き者だなぁ
今日は官庁御用納めなのに サーバ屋には盆も正月もないのだ(^_^;)まいったか でも毎日が祭日なんだろうなぁ♪＠きゅうり踊りとか象さんの曲芸とか ■ このスレッドは過去ログ倉庫に格納されています
