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

さて、901のドライブだけど(^_^;)どうする？
置き換え速度優先なら36GB(たぶん15K.3)
今後のことを考えたら73GB(15K.x)
時間かかっても高性能を狙うなら15K.5指定の73GBなわけだけど

>>857
ふむ。

36G だと、news4vip をやった場合、半年ぐらいしかもたないですね。
HDD がおなかいっぱいになってしまうです。

(今落ちているけど)tiger507 でつないでおいて、
大きな HDD をつけたいところです。

うほぅ

あと、危惧しているのは、
oyster901 の不安定の理由が、HDD ではなかった場合ですね。

HDD だと完全に特定できたわけではないので、
そのあたり、ちょっと不安だったりします。

でも仮にそうであっても、73G を手配することは、
無駄にはならないと思います。別のサーバにつけることもできるし。

ということで私としては、

・73G 15,000rpm HDD x 2 を手配してもらう
・Cheetah 15K.4 にするか新製品の 15K.5 にするかは、ここでわいわいして決める

というのを希望します。

>860
73GBなら一年半くらい？(^_^;)

>>862
vip が現在の大きさのままだったら、、、。

K.5かK.4はでたとこ勝負ってのもありかと(^_^;)
手に入るものを入れるっつーことで

>>864
確かに。

ところで、半年なのか一年半（あるいはそれ以下）なのかで何が変わるんだろう？(^_^;)

vipは一年後に閉鎖

くおりてぃー

あ、吉祥寺到着(^_^;)ちと落ち

>>866
リフレッシュ工事の作業は、意外にめんどいんですよね。
だから、あんまり進んでいなかったり。

・新しい土地作り
・掲示板システムの入れ込み
・板の移転
・memories 土地作り
・memories にデータ移動
・DNS 設定変更

で、今、掲示板サーバって、結構な台数あるわけです。

ということでできれば、リフレッシュ工事は
2年に1度ぐらいにしたいかなぁと思っていたり。

で、ほとんどのサーバはそのぐらいでいけるわけですが、
なにぶん news4vip だけは、1枚の板でその状況と。

リフレッシュ工事が必要なくなるまでに、exは何番まで行くかな

そろそろ次の一手を考える時期なのかなぁ
とりあえず、夢を馳せるのは自由なので案だけでも
あくまでも素人考えなのであまり突っこまないように

簡易雪だるま
雪だるまよりも構造が単純でメンテや鯖変更が楽になる
ＨＤＤラックの搭載ＨＤＤにもよるけどフロント3〜4台とラック1台で
1セット


フロント（ディスク無しもしくはＯＳディスクのみ）
↓
リアＨＤＤラック
ＳＡＳ辺りを使ったＨＤＤラック

datキーごとに鯖をわけてみるとか

/home 用に、容量の大きい(かつ NFS ではない)
外付けディスクをつける感じですか。

NAS だと高速かつ書き込みアクセスのためには現状いまいちなので、
SCSI とか FiberChannel あたりですかね。

んー、ライブなdatは全部RAMディスクにおいて、dat落ちしたら低速なNASに送っちゃえば

>875
そんな感じです。
アクセスの厳しい鯖には無理かもしれないけどそれ以外の大多数
の鯖に使えると思います。

NAS にはサーバからどうアクセスするのか、ですね。

NFS だと、現状きわめて不安が。

>>877
無理でもないと思うですね。

高速な外部ストレージを装着すれば、今のしくみなわけで。

帰宅(^_^;)

徒歩26分っと・・・

>>880
おかえりー

>>881
バスとか、タクシーかもしれないぞ？

徒歩だと30分くらいでないかな？(^_^;)

>870
なるほど(^_^;)

26分だから競歩とでも言うのか・・・

たまには歩け

雪だるまだとどうしてもroot権限が必要になっちゃうから・・・

73GB 15K.x x2でいきますか(^_^;)これが一番スムースで現実的だし
15K.5は入ったら入ったで使う方向で。

>>888
そうですね。それで。

で、OSですが、しばらくは 6.0R かなと。
6.1R は cobra では、現状問題を抱えているので。

>>855
いまさらですが、それは良い体験をされましたねー。

んで offlaw.cgi read.cgi をどうすればいいのか

討論会
↓

とりあえずお祓いをする

「dat落ちした datをフロントに転送はしない」は決まりかと、

↑カウンター

ＳＤさん元気？

ﾁｯ

>>894
たぶん

>>896

おいちゃんも元気でね。

●が使えないのはたいへんー
金払ってる分ｺﾞﾙｧも大きくなっちゃう

現在の read.cgi の実装:

・ライブな dat: バックエンドにもらいにいく(http で)
・過去ログ: ファイルをローカルに検索しにいく(雪だるまではエラー)

現在の offlaw.cgi の実装:

・過去ログ: ファイルをローカルに検索しにいく(雪だるまではエラー)?

# そういえば、offlaw.cgi のソースは一度も見たことがなかったり。

鱈子が出てくるまで様子を見ることにして、薄野へＧＯ！

offlaw.cgiってなんれすか＞＜

過去ログもバックエンドでフロントにhttpdで公開して
実績のあるread.cgiのライブdat方式でとりにいく

もちろんフロント以外からの過去ログリクエストはなんらかの手段で拒否。

（＾ω＾；）

んでofflaw.cgiをそもそもいま生きてる人がいじることって可能なんですか？

VIPの過去ログってどれくらい参照されてるんだろう

>>901
過去ログのdatの中身を●ユーザーに送信するCGI

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:に一部の動画とか移してなにがどこにあるかわからなくなった
うちのマシンと同じようなことですか？　ぜんぜん違いますねすみません。