雪だるま作戦のスレを待ち続けるスレ Part11

1) 別の雪だるま用過去ログ専用サーバ(ぼっとん)を立てる
2) NFS 等でdat落ちのときはぼっとんに落とす。
3) read.cgi はいちいちぼっとんに聞きに行く。

専用ブラウザは、、、
4) liveなdatが無いときはぼっとんに取りに行く。　←　要改造かな?

NFSなしの6.1R/cobraって安定して動いていませんでしたっけ？

>>899
今もあるか不明ですが、read.cgiについては、
find_kakodirあたりをmod_proxy対応すればよいのかも。

ただ、フロントから過去ログディレクトリへのhttpアクセスが
できることが前提になりますが。

古過去ログ鯖
新過去ログ鯖

を作ってリンクさせるって琴？>>907

>>907
> 2) NFS 等でdat落ちのときはぼっとんに落とす。

現状のNFSはかなり不安があるような．
NFS以外で渡せば良いんでしょうが．

>>907
2) をどうやるか、という感じですね。
NFS でやるのは筋が悪そうなので、何らかの仕掛けが必要そうな。

あとは、フロント版 offlaw.cgi (ぼっとんに過去ログをとりにいく)と、
read.cgi 改良版(過去ログはぼっとんを参照する)が、必要というかんじですか。

>>907
3) read.cgi はいちいちぼっとんに聞きに行く。

バックエンドがぼっとんに変わっただけのような。

>>908
> NFSなしの6.1R/cobraって安定して動いていませんでしたっけ？

まだ、実績といえるほどのものはないですね。

>>909
基本的にはバックにもdat落ちしたdat置かないってこと、

4) は工夫&負荷との兼ね合いで専ブラの改造なしでいけそうかな?

>>912
バックが落ちるのが今の弱点かと、
だからバックからの分離っすね。

バックにdat落ちを置かないのは、リフレッシュ工事不要を狙ってるのかな？
不安定うんぬんってのは全然変わってないな

うーん403　エドウィン。

tiger507 復帰した模様。

作業にいくです。
議論の結果をたのしみに。

cobra2244 の KVM も復活した模様。

少しずつ、作業にかかります。

バックが落ちるのが問題でなく(いやそれも問題は問題なんですが)、
それによって系全体に影響が出ているのが問題なんじゃないかなと。

バックエンドの負荷がどれくらい変わるんだろうか…

むたんがんばって!

バックが落ちる原因

・6.1R+amd64+NFS
・6.1R+amd64

どっちなんでしょ。


[　 tiger2522.maido3.com ]　live22.2ch.net live24.2ch.net　
[　 cobra2244.maido3.com ]　live23b.2ch.net　　 バックエンド２
[　 cobra2247.maido3.com ]　news20b.2ch.net　　 バックエンド３

tiger2522はNFSでも落ちてないんだよなー。
んで cobraはNFS無しでどうなるかはこれからと。

>>923
kbdmux 事件(amd64 の SMP でのみ不具合)以降、
6.1R/amd64 + SMP の可能性を一番疑っているです。

安定性のためにぼっとんを作るのは無駄に思えるな。
rsyncで同期するのが失敗だからといって、過去ログをフロントに置くことが失敗とは限らない。

dat落ちしたらぼっとんに移すんじゃなくて、フロントに移したほうが、
read.cgiとofflaw.cgiは改造しなくて済む=安定性が高い。

そもそも、なんでdat落ちした datをフロントに転送はしているのでしたっけ。

offlaw.cgi が対応していないから？

フロントは10台〜20台
最低でも10台を考えているけど
それでも?

>>926
たぶん


>>927　は >>925 あて

おいちゃん若いんか…

けっこう

直接フロントに過去ログ移すのは

・ 過去ログが膨張するとフロントの HDD 容量が逼迫する．
・ フロントを増やすと過去ログ転送もその数だけ必要になる．

なんで，ぼっとん（過去ログ専用バックエンド）はムダでもないような．

>>926
していた、ですね。

で、それはあまりにもコストが高かったので、ちょっと前に既にやめているです。
雪だるまサーバが日増しに弱くなっていく様子が、手に取るようにわかった。

理由は、offlaw.cgi とかモリタポとか公式p2とか、いずれにせよ過去ログ関連と。

過去ログサーバを別に作って、
そちらに過去ログを置くのは、
意味があると思うですね。

んで　落とす方法は
普通に http経由にして dso でゴリゴリ書いたほうが良い予感。

専用ブラウザのdat参照のシーケンスわすれちまったなぁ

offlaw.cgiやread.cgiの過去ログ参照については、ローカルなのが(=雪だるま以前と同じ)
一番安定してるだろうということで>>925を書いたんですが
そんな将来をにらんだ話だとは思わなかった。>>927

将来を見据えた話なら、ぼっとんの必要性は賛成です。

>>935
とてもざっくりだと、

dat 参照 => 302 が返る => offlaw.cgi を起動する

ではないかと。

dat 落ちの時は scp か何かでも使えばいいんですかね．
read.cgi は，HTTP で取ってくるライブ dat のやり方を過去ログにも流用すると．
offlaw.cgi も，同様に改造できればそれでいいんでしょうけど，さて......

>>936
そろそろ「安定」がキーワードなので
とんがった設定よりは台数投入してこなす段階化と、

フロント四台のそれぞれを 75%稼動にする = 一台追加する
と、

>>938
なるほど、mv の替わりに単に別サーバに scp すると。

エラー処理とか考えないといけないと思いますが、
筋は悪くないかも。

scp って何?
cp のsuperなやつ?

昔、rcp (remote copy) と言っていたやつです。
今は ssh のプロトコル使って、scp (secure (remote) copy)になったと。

おおっ

scp ../../dat/news/aaa/bbb/ccc/9999999999.dat botton.2ch.net/なんたら
とかやれば良いんですか?

もし offlaw.cgi のソースがないとすると......open(), close(), read() あたりを
横取りして HTTP でファイル取ってくるようにするライブラリ作って LD_PRELOAD かますとか．

>>940 まぁリモート転送となるとどの方法でもエラーは要考慮でしょうけど，
エラーならいったん転送留保して，あとで再挑戦とかですかね．

>>943
scp localfile [user@]remotehost:remotedir
とかですね．

http://www.freebsd.org/cgi/man.cgi?query=scp

mtime とかも保存した方がよければ -p オプションも使うとか．

>>944
私が書いたやつだから。。。
どっかにあるはずー

というか、 AMD とかで再度コンパイルしているんだから
絶対にあるよ、きっと(←絶対といいながら、、、)

>>943
で、通常だとパスワード聞かれますが、
あらかじめ秘密の鍵を作っておいて、それで認証するようにすれば、
それをパスワードの替わりにすることで、パスワードなしで転送できます。

秘密の鍵を作ってあらかじめセットしておくのは、
スロー同期のところで、同じしくみ使っているです。

なるほど、

scp をdat一個一個に発行するのは負荷どうなんでしょか?
多いときで 100スレ/minくらいかしら?

>>950
localfile のところで複数ファイル指定も可能ですし，あるいは -r オプションで
指定したディレクトリ以下を recursive に転送ってのもできますんで．

なるほど、なるほど、
りょうかいですー

いろいろ工夫できるということか、

んじゃ >>907 は案１ということで、

他に案ありますかねぇ

そろそろ次スレの季節
次スレも待ち続けるのかな？

>>952
read.cgi/offlaw.cgiなどの過去ログの取得部分を
httpベースに変えれば、過去ログサーバを分けなくても
よいのかなと。

あんまり複雑にするのも障害時の対応が大変そう。

現在の率速というかネックはスケールできないバックなんですよね、
つまりどこの負荷を下げたいかというと、

バックなんです。

雪だるま作戦のスレを待ち続けるスレ Part12
http://aa5.2ch.net/test/read.cgi/nanmin/1150047996/l50

ﾄﾞｿﾞ

お、乙

>>956
過去ログのアクセスがどの程度なのですかね。
負荷を上げるほどあるのかどうか。

絶対的な負荷を下げるためという意味では
分けるというのはそうなのだと思います。
(というか、そういったものの積み重ねですかね。)

>>936
なるへそ

>>956
ひとつの板でひとつのバックエンドがあふれる事態を今から想定？

>>960
既に一台→三台にわけてるわけで、
たぶん秋には倍とは言わないけどさらに追加が必要だと重いますー

さらに安定化を目標としたいから
若干性能下げても台数追加で望みたいという希望も先ほど書きましたが、

「さらに」を二回書いてくどい文になっちまった　ｼｸｼｸ

おっちゃん、フランシスコ・ザビエル化したんか？

あと，ストレージに要求されるものも違いますね．

ライブな dat -> 速度 > 容量
過去ログ -> 速度 < 容量

んで，過去ログを分離できれば，将来的にジンギスカンとかやらなくても，
容量は小さくとも高速なストレージを使うとかいう選択肢も出てくる，とか．

>>964
バッテリバックアップされたメモリディスクとか、そのへんを使うとか。< ジンギスカン用に

>>965 そんな感じですね．

速度的にはどうなんでしょか?

ざっとぐぐってみると，例えばこんな製品があって
http://journal.mycom.co.jp/news/2005/06/17/003.html
こんなベンチマーク結果らしいと．
http://journal.mycom.co.jp/photo/news/2005/06/17/003dl.jpg

>>968
i-RAM ですか。SATA HDD の16倍と。

前に特化型スレでも、話題になったですね。

それは MD よりははるかに遅いような、、、

>>970
メインメモリのほうが、速さではかなり上ですね。

しっかり、誤爆しました。

996 名前：root▲ ★[] 投稿日：2006/06/12(月) 04:04:46 ID:???0 ?#
個人的には、i-RAM とかは
ジンギスカンII にするのの代替(dat 部分だけ)というかんじに思うですね。

通常の動的なファイルは、通常ジンギスカンで特に問題ないので、
ライブな dat を置く場所、ぐらいですか。

HDD よりは高速だけど、メインメモリには劣ると。
というか SunOS さんも書いていますが、たぶんこれは「高速な HDD」ぐらいのしろものかなと。

まぁ，外部デバイスとして使う限りは I/F の転送速度が限界となりますからね．
その点で通常の RAM より劣るのは致し方ないと．>>972 のように dat の置き場所
として考えればメリットはあるかな，ということで．

I/F の転送速度といえば LAN の速度もあるんで，ネットワークサーバとして考えれば
LAN の速度と比較して爆速である必要もそんなにないかな，ということも．

´･ω･`)つ旦~旦~旦~旦~

ここまで読んだ

adhocに過去ログをフロントのHDDに入れてたけど
そのへんちゃんとやろうよ、という話だと理解しました。
memoriesがだいぶ前からいっぱいいっぱいのようなので、
bottonもかなり負荷がかかるんじゃないかなあと。
実況の過去ログにクロウラーが来るかどうかはわかりませんが
news20になら来そう。

C:をsystem、D:をdataにしてあるのにD:がいっぱいになったので
C:に一部の動画とか移してなにがどこにあるかわからなくなった
うちのマシンと同じようなことですか？　ぜんぜん違いますねすみません。