【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part17
■ このスレッドは過去ログ倉庫に格納されています
peko作戦について語るスレです。
サーバロケーションPIEに関する話題もこちらで。
＜現在の主要なテーマ＞
・oyster243(BBQ/dnscache)の突然死対策&cobra2245セットアップによる2台体制化
・oytser902(memories)のFreeBSD 5.3化
・「雪だるま作戦」による、スケーラブルなサーバ群構築
・read.cgi/bbs.cgiの細かな調整・詰め
・携帯サーバのプライベート側スイッチのグレードアップ検討
・各種作戦・プロジェクトとの連携
・FreeBSDのさらなるチューニング詰め
＜関連スレッド＞
■新春特別企画「雪だるま作戦」liveサーバの飛躍なるか!? Part1
http://qb5.2ch.net/test/read.cgi/operate/1105035540/
■ 自動地震速報＠2ch をつくろう
http://qb5.2ch.net/test/read.cgi/operate/1106583619/
■ テレビ番組欄＠2ch をつくろう 第2話
http://qb5.2ch.net/test/read.cgi/operate/1107366393/
＜関連サイト＞
レンタルサーバー maido3.com ２ちゃんねるの転送量: http://server.maido3.com/pie/
MRTGによる統計情報: http://mumumu.mu/mrtg/
２ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html
＜前スレ＞
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16
http://qb5.2ch.net/test/read.cgi/operate/1102087698/ 取るとして
現在でどれくらい時間がかかるんだろーか? なんか、この時のことを思い出してわらた。
http://qb.2ch.net/test/read.cgi/accuse/1042084683/
76 名前：夜勤 ★ 投稿日：03/01/11 06:54 ID:???
なんか想像しちゃうとね、
来る日も、来る日も、雨の日も、風の日も、
テープにバックアップですかー。。。
もちっと なんか華々しいというかそんな日々がee。 去年5月のhe.netからの移転終盤で300GBくらいかぁ。
今なら500〜600GBくらいかなぁ？（かなりてきとー）
なんとなく1テラあってもおかしくない気もするけど、 IBMのテープオートローダは80MB/秒だそうです。 >>584
最大でも1.5TBでしょ
df -hみればわかる
まあ>>598の予想が正しければ数時間で終わるでしょう
今のテープ取りは早いから。 速くて80MB/s（非圧縮）程度らしい。安そうなのは7.5MB/s
7.5MB/s＝27GB/h
30MB/s＝108GB/h
80MB/s＝288GB/h
（圧縮）160MB/s＝576GB/h うちの会社にあるやつは47MBのバックアップに2時間かかる。
20数年前のミニコンだけど。 この際なんでバックアップシステム構築なんてどうでしょうね、と振ってみる。
金と手間がかかるからやんないでしょうけど・・・
商用だとNetvaultになるのかしら。FreeBSD対応もありますが32bit。
ttp://www.bakbone.co.jp/products/netvault.html
ttp://www.trinity-ss.com/p_strage/product/soft/netvault/netvault.html バックアップが終わらねーとか良いながら穴だらけの穿孔テープ見つめてるFOX想像してﾜﾗﾀ ぼちぼち、サーバのログをチェック中。
1024だと、やはり売り切れるみたい。
やはりlive16と20だけ1280にしておくか。
バックアップデバイスの件(そういえば、これもマニラネタ)は、後で別途。 最初から1280人待たせる必要はないので、こういうふうにしてみた。
<IfModule prefork.c>
StartServers 1024
MinSpareServers 1024
MaxSpareServers 1024
ServerLimit 1280
MaxClients 1280
MaxRequestsPerChild 1000000
</IfModule> >>606
なんか、激しく重かったみたいで、あんまりかわりばえしなかった、、、かも。
というか、肌で感じられなかったし。
しばらくこの設定で動かしてみる必要かりかも。
転送量は、ex10の場合subject.txtを圧縮してもしなくても、大きくは変わらないみたいですね。 ほうほう
転送量変化無し、の時点で収穫その１かもだすのう、、 FreeBSD5.4Rリリーススケジュール更新
もっともまた遅れる可能性大でしょうけど（苦笑
Upload to ftp-master. 17 Apr 2005 今のmemoriesの運用形態なら、月一とかぐらいでテープに落とせば十分かな。
で、FibreChannelに対応したDLTか何かで、Polywellが扱っているいいやつを、
どなたかみつくろっておいていただけると。
で、問題なのは「半ばほっといてもうまくバックアップがとられている」な気がします。
つまり、それなりにチェンジャっぽいほうが、いいかもしれない。
というわけで、今日〜明日は概ねオフラインの予定。 ちゅーか違うホストに接続している同容量のHDDにdailyでpdumpfs_sshするとかなら
すぐに出来るのでは。
RAID1は論理ミスには弱いけど、違うホストへのpdumpfsなら耐えられる。 >>611
それは予算は大体いくらかかりますか?
大雑把でいいですけど、 >>610
ポリウェルさんは残念ながら「バックアッププロダクト」をお持ちで無いようですorz
どうやら少なくともラックマウント系はオプションっぽい模様。
どうしてもpolywellさんというのであればお問い合わせしたほうがいいかもです。 >612
1年ぐらい前にpc鯖の誤消去事件があったときにroot★氏が話題にしていたけど。
要するにテープじゃなくて別のサーバーにデータをdailyで保存しておきますか。
という話。
サーバーはCPUの速度は全然いらないのでPentium3とかでもOk。
HDDの容量さえあればいい。 >>614
今はなしているのは memories(suma)の話しなんだが、 テープドライブ扱ってるメーカー少ないようですねぇ
とりあえず、有名所だけピックアップしておきます。
（日本語ページのみですけどアメリカでも扱っています。）
ＨＰ
ttp://h50146.www5.hp.com/products/storage/tape/index.html
ＩＢＭ
ttp://www-6.ibm.com/jp/storage/products/tape/ U160/320 モノのテープドライブを選ぶんじゃと
FC変換しるハブを別途買うひつようが出てくるんでなかべか？
ようﾜｶﾗﾝけんども、 じじいさん
２chの要求レベル相当のバックアップソリューションは
大抵堅牢性が強く求められるんで、
ちょっとしたものでもミリオン単位で飛びますよ
テープドライブをsuma直結にする（ってできるのかわかりませんけど）か、902につなぐのか・・・
後者のほうが管理上現実的な気がするのは私だけでしょうかね >>619
ちょっといいのじゃとsumaの倍なおねだんじゃからねぃ
（sumaは150まんえんぐらいだす）
ﾋﾞｸｰﾘすておる所だす たぶん設置場所の関係からラックマウント機器でないとつらいという制約もあるでしょうし、
そのうえ圧縮つきで1TB以上を確保しておく必要があります。
さらに>>610でrootさんが言っているけどオートチェンジャーつきとなると
sumaの数倍は●がとびまくりそうです・・・ >>621の条件を満たすとなるとこれくらいですかねー
金銭的に極めてつらいでしょうね。。。。
ttp://www-6.ibm.com/jp/storage/products/tape/lto/3581.html
ttp://h50146.www5.hp.com/products/storage/tape/ssl1016_sdlt/index.html >>622
どっちも200まんえんぐらいじゃのう
hpのはFC変換ハブがいるから、もっと高くつくかの？ >>624
ねだんはPolywell次第じゃないかのう
正規代理店として持ってこれるブツがあるなら値引きも期待出来るで、
でも、少なくともsuma並のねだんはするとおもうんじゃが
ただたんに鯖を組むだけなら100まんえん以下で済むとおもうでよ
↓の2Uのケースに、てきとうなRAIDカードでも組み込んでミラーさせて
（http://www.polywell.com/us/rackservers/poly2012ai.asp）
大きいS-ATAHDD（今は400GBが最大）を何発か入れればそんなもんで済むべ
でも、テープを持ち出すからには
何か鯖をたてるだけでは実現できないメリットがあるとおもうんじゃが、、
それはどんなんだべか？ NetVault を使うとハードディスク上にバーチャルテープライブラリを構築できますが、
そんな事するくらいなら普通に pfsdump でも使った方がましですな memoriesもう一個立てて、半手動で同期とっとけばいいんじゃない もう、RAID-5でも0+1でもいいから、HDDで堅牢性を求めた方が安上がりで、楽な気がする。
もしくは、>627みたいに、鯖間でミラーリングするとか。
テープドライブまで使う必要があるのかどうか・・・。 各鯖の空きHDDをひとつのHDDとして見立ててバックアップに使うシステムとか。
あ、一個でもクラッシュしたらパーか
つかえねーｗｗ >>628
すでにmemoriesはRAID5です
思いつきですがGoogle Inc.の中の人に相談したらいいかもね
あそこは超優秀な技術者の巣窟ですから テープの利点というんは、メディアを持ち運び出来る点かのう、
データを管理人の手元においたり、ブラジルで使ったりとかも
可能になってくるんでなかべか、
利用法によっては鯖代の足しになったり鯖負荷低減になったりしるかものう
あとは、巻き戻しポイントを複数用意出来るという点かのう
１ヶ月前のデータじゃとダメだという場合、２ヶ月前、３ヶ月前と
さらに前のデータを用意出来るのは状況によっては有意義かも試練
…ほかに利点はあるべか、 memoriesの場合は導入直後にフルバックアップをとって、
その後は各種プログラムなどの仕様変更や新規収容があったときに
差分をとるやり方をすれば問題ないかと。
そういった理由でオートチェンジャーは必要性は薄いと思います。
で、メディアはJimさんが地理的に離れたところに設置した耐火金庫へ放り込んでおく、と。 root★さんいますか?
bbs.cgi@ex10 を更新しても反映されないような仕様ですか? >>633
そんなはずはないですが、、、。
なんか、一時的に該当時間、何か様子が変だったみたい。
で、テープですが、入れ替えしないでとれると
手間がないかな、ってかんじで、チェンジャーつきがいいのかなと。
でも高いなら、チェンジャーはあきらめて、とる時はPIEに人がいて、
テープを差し替える、というのでも、十分な気がします。
上記を想定すると、オペレーションは、概ねこんなかんじかなと。
フルダンプ用のテープを2セット用意しておき(例えばAとBとする)、
1)最初にAにフルダンプをとる
2)次にmemoriesに収納があった時にBにフルダンプをとる
3)その次の収納の際にはAにとる、以下2)と3)を繰り返す
これにより、一世代前のテープが常に存在するので、
万一テープにとっている間にSumaがクラッシュしたり、
間違ってテープを上書きしてしまっても、被害を最小限にとどめられる。
で、増分とってもいいんですが、今の更新頻度と手間を考えると、
毎回フルダンプをとっても、十分(たぶん、収納のタイミングでとるだけでいいから)
なのではないかなと。 >>634
りょうかいですー < 前半
テープは見積もりとって見ます 携帯からスレ立てる事は出来ますか？
教えてください >>634
チェンジャーというよりもFC機のほうがねだんがたかいようじゃよ
FC機の場合、小容量のは種類もすくないようで、
FC-SCSIブリッジとかいうんも、とてもたかいようじゃ。。。 >>635
工工エエエｴｴ（´Д｀）ｴｴエエエ工工 バックアップは日本全国で分散されて保存さえれてるってのはだめなの？ｗ memoriesに収容されているのは.dat.gz, .html, .html.gzの３つで
他のもの全て(index.html, subject.txt)を含めても
.dat.gzさえあれば復元できるはず。
で、全てテキストな.datの圧縮率を1/3程度と仮定すると
最大1.5Tあるmemoriesのデータでも
全体の1/5、つまり300GのHDD一台でバックアップできるはず
と、暴論を述べてみる。
圧縮しての保持形態や復元作業の手間(時間ではなく手間)などを考えると
そのまま保存できるテープ等のデバイスの方が良いことは間違いないんだけど。 >644
出来ないこともないですけどＤＶＤの枚数と焼き時間がトンでもないことに（滝汗
ＤＶＤ−Ｒ １枚あたり約４Ｇ
１枚焼く時間 最速クラスで約６分
仮に１Ｔだとしたら２５０枚なので
６ｘ２５０＝１５００分 約２５時間（滝汗
しかもそこまで連続焼きにドライブが耐えられないと思われ テープにバックアップしたものを、リストアすることなんか
永久にないと考えたほうがいいですよ
ただ、保存したという自己満足だけ 国内価格だけどこのクラスなら比較的に安くてテープコストも安いみたいです。
ttp://www.plathome.co.jp/detail.html?scd=11850316 >649
アメリカだとここまで下がってます。
ttp://www.costcentral.com/proddetail/HP_StorageWorks_Ultrium_215/C7492B/D33101/ >>642
分散コンピューティングか！！
UDのHDD版。手間暇掛かりすぎな悪寒。 >>653
みんなのHDDをおらに少しだけ分けてくれ！
こんにちは。
似たようなスレに投稿してみたけど、そこよりもこっちの方が活発なので再投稿。
2ch 第二投稿なので、いまいち投稿の仕方などの雰囲気がつかみ切れていないが。
提案としては、HTML 生成圧縮済のページを URL でハッシュして、メモリ上に保存。
以下、ほぼコピペ。
基本動作は
if(URL を元に HTML ページのハッシュを生成と検索)
{ ハッシュテーブルからキャッシュを送信}
else // 見付からない
{ HTML 生成、送信して、ハッシュに保存 }
HTML 済の保存場所としては、
1. 一つのプロセスが常駐できるなら on-memory
2. mfs または tmpfs
3. local fs
ハッシュテーブルは多段式にして優先順位を元に高速アクセスできる所に生成済ページを保存
アクセス数と最終リクエストによる優先順を保持して、1 または 2 と 3 を併用できたらいいとは思うけど。
新しくアクセスされたところは 1(2) に残り古いページは 3 に移って、そのうち消去。
記事の数やメモリの量にもよるけど読者が多いところに有効。
とっても大雑把だけど雰囲気ぐらいはつかめまつか? memoriesを2機にしてバックアップ兼負荷分散がいいのでは？ >>639
お、そうなんですか。
それなら、SCSIカードを追加とかでいけるような。
今夜あたりに、適当に調達案をここにでも。 >655
DHT（分散ハッシュ）でググレ。P2P研究関係とか。
あと実績がある硬い仮想ファイルシステムじゃないと2chに導入するのはムズイような。 >>658
道楽には硬いものはいらないかとw
で、できればSolaris ZFSを投入してほしいなあと妄想してみる >>650
おおっ 安いのう
おらが>>617で出したソニーのFCなブツもこうなっておる
ソニーのブツは互換性が全くなさそうじゃからそもそもアレなんじゃが、
http://www.getplus.co.jp/product.asp?product=652039
\1,666,717(税込)
http://www.costcentral.com/proddetail/Sony_SAITe1300FS/SAITE1300FS/C92636/
$7,683.60
>>657
Reffiさんがだしたサイトをみるに、FCモノ限定じゃと
少なくとも6000ドルはみたほうがよいようじゃのう
おらには出せない金額ではない（虎の倍）ように思えるけんども、
そのへんはサンダルをこよなく愛するえらい人的にはどうなんだべなぁ？
ところで、メディアの種類には拘らないのけ？
国内の関係者が使っておるブツと互換性があるブツを選べば
今後いろいろと（新しい）使いかたがあるとおもうんじゃが、、 >>659
とりあえず過去ログ読んで来い
偽FOXもな >>658
ふ〜ん、そんなのもあるんだね。
後でゆっくり読んでみるよ。
いいたかったのとはちょっと違う。
今は「 read.cgi がリクエストが来たら、各リクエストごとに dat から HTMLを生成している。」がいまの実装であっているかい?
違っていたら、この提案は意味なし。
read.cgi がファイルにアクセスして、HTML 生成をするのはかなりの作業だと思う。それを、一回毎に HTML を生成、破棄しいないでプロセスにキャシュしておくのはどうかというのが提案。
squid などで、試しているキャシュに似ている。
Apache が read.cgi を含むプロセスと、何らかの通信をするなどして、一つのプロセスが常駐する必要がある。
一段目のキャッシュとして malloc 等で割り当てたメモリに HTML を保存する。
そこに、URL が存在したら、それをそのまま socket に流す。
一段目のキャシュに無かったら、二段目だ。
こっちもハッシュの鍵はURL。
こっちでは、HTML ではなくて、生成圧縮済の HTML へのパス。
例えば、/var/tmp/read.cgi_cache_file。
これは、一段目のキャッシュが大きくなった時にファイルに書き込む。
IO が発生するが dat を読んで、HTML を作って、圧縮するよりは、速いはず。
二段目にも無かったら、dat を読むしか無いね。
HTML を作ったら今度は送信するだけでなく、一段目のキャッシュに保存。
しばらく経つと、キャッシュも大きくなるから、何らかの優先順位を決めて、一段目のは二段目に移動。
二段目のは削除。
キャッシュにハッシュ関数を使うってだけ。P2P のとは全くの別物。
仮定としては、メモリと /var/tmp (一時保存のHD)等は余裕があって、ユーザは書き込みよりも、読者の方が多い。
アクセスの多い板はある程度限られている。 >>662
メモリキャッシュ→ファイルのキャッシュ→従来の方法 っていうことですか。
こないだ、ミニ雪だるま作戦でちょっと試したやつですね。
こないだはread.cgiの出力はノーキャッシュでやったのでsubject.txtだけでしたが、
それでも2〜3割はメモリキャッシュからヒットしました。(旧ex7の場合)
ということで、read.cgiでも同じことができるなら、
news系とかpc系とかのようにROMの多い板では、相当の節約になる気がしていたりします。 >>663
実況だとメモリキャッシュ、通常だとファイルキャッシュ重視の構成にするといいのでしょうかね。
そういう意味で膨大なキャッシュシステムを構築している、
それもクラスタリングはあくまでその補完でしかないGoogleってすごすぎですね。
できるならGoogleのエンジニアのお知恵を拝借したいぐらいでしょう＞雪だるま作戦 >>663
そんな感じです。
既に実験済でしたか。
どこをたどれば、関連記事を読めますか?
SpeedyCGI は別物ですよね?
mod_cgidso による実装ですか? >>666
ありがとです。
スレと squid の FAQ を読んでみました。
基本的に考え方は同じですね。
ただ、いまいちわからなかったのが read.cgi で生成される記事です。
こちらの方も squid がしっかり効いているのでしょうか?
CGI を通したページは最終更新日を調べられないので、キャッシュできないような気がするのですが。
>>667
read.cgiのキャッシュは、datのLast-Modified: を返すようにする、、、ってかんじにすればいいのかな。 セキュリティホール情報
ttp://home.jp.freebsd.org/cgi-bin/showmail/announce-jp/1286 >675
この修正後にリビルド推奨なのでかなり深刻なバグのようです。 655 です。
>>668
似たような試みは既にいろいろとされているんですね。
もしかして、邪魔なだけ?
>> 669
655 です。
たぶん今のままでは無理かも知れないです。
設定を見直せばうまくいくかも。
こぴぺ
ttp://squid.robata.org/ReverseProxy_top.html
CGIスクリプトやアクティブサーバページズなどの動的なコンテンツはキャッシュする事ができません。
プロキシは静的なページのコンテンツのみをキャッシュできます。
４つの尤も重要なヘッダーのタグは：
* Last-Modified: プロキシにページの最終更新日を知らせます。
* Expires: キャッシュからいつ削除するかをプロキシに知らせます。
* Cache-Control: いつプロキシにキャッシュされるべきかを指示します。
* Pragma: プロキシにページをキャッシュすべきかどうかを指示します。
http://squid.robata.org/squid2.0-conf.html
TAG: hierarchy_stoplist
このリストに記述されたワードがURLの中に見つかると、隣接キャッシュではなく直接サーバにリクエストを行います。隣接キャッシュを使いたくないオブジェクトのために使ってください。
このオプションは複数回指定できます。デフォルトは、'cgi-bin'と'?'を含むURLの場合に直接オブジェクトを持ってきます。
# hierarchy_stoplist cgi-bin ? >676
英語FreeBSD MLのnectarの投稿もよまずにあいまいなこと書くなよー。
スラッシュドットにもストーリーあるよ。
telnet使ってなければ言うほど深刻でもない。 >>675
ユーザランド(telnet)のみですね。
ぼちぼちやればいいかなと。 >>677
いや、意見・コメント歓迎です。
次の手はそのへんかなと思っているので、とても助かるです。 ■ このスレッドは過去ログ倉庫に格納されています
