【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 2ちゃんねるの転送量: http://server.maido3.com/pie/
MRTGによる統計情報: http://mumumu.mu/mrtg/
2ちゃんねる/PINKちゃんねる 稼動中のサーバ一覧: http://mumumu.mu/serverlist.html
<前スレ>
【Project peko】2ch特化型サーバ・ロケーション構築作戦 Part16
http://qb5.2ch.net/test/read.cgi/operate/1102087698/ もう一回 make してみた with reset
ちゃんと動いていますかね? 動いていると思います。>>119
私も確認しました。
>>120
今日は仕事すか。
私はそろそろおねむで。 桃色は2chぢゃないって建前なんだから、桃色運用情報鯖を立てるのがよろしと思ふ >>125
鯖じゃなくて板でしょ
桃色運用板を桃色掲示板にたててもらったほうがよろしいかと >>127
それは本来pink本の編纂を担う板であって運用板じゃないと思いますが。
今は事実上間借りしている状態ですけど。 管理人(責任者)とシステム弄ってる人は別だからどっちでもいいと思うけどな おぢさんがいるところに書く、悲しいけどコレ現実なのよね >>125
私にとってははつみみです
都市伝説じゃないの? >>123
おぉー。
brief impressionを報告きぼんぬで。 さらっとした肌触りと、程よいフィット感が心地よいです。 >>135
Jim Davis Sean の興奮しているさまに圧倒されました。
「200Paulが世界で一番いいばしょだろ」と Jim がいった言葉は
嘘だったようです。
免震構造(建物がフロートしてました) >>137
そうですか。
200Paul = PIE よりも良いロケーションかもしれんと。
地震対策ですが、特に日本やSF・LAのような地震のことを一番考えないといけないとこだと、
選択の重要な要素のひとつかなと。
耐震・免震・制震は全部違うアプローチです。
きちんとメンテナンスするなら、免震がデータセンターにはいちばん向いていると思われ。 まだ完成していないので
URLは・・・・
内緒だったりする。 >>140
Operation 200Paul Location (Alias: Ouroboros Killer)
発動間近・・・??? >>140
ビルの人はやたらと日本の技術を自慢していました、 ググったらあっさりページ見つけちゃったんですけど晒さない方がいいですよね? FreeBSD の総本山というか
accosiation とか society とかってどこにあるんですか? あっと
WebSite というよりは
実際にどこにあるのか知りたかったり、 >>151-152
The FreeBSD Foundation
http://www.freebsdfoundation.org/
Postal Address
The FreeBSD Foundation
7321 Brockway Dr.
Boulder, CO 80303
USA >>146
日本は対地震対策では先進国ですからね。
こんなウォーターフロントにでさえ、超巨大なデータセンター建てちゃったり。
http://www.attokyo.co.jp/ oyster243の現ディスクイメージをmemoriesにダンプ中。
ぼちぼち、cobra2245と同じRAIDカードの手配を依頼する予定。 oyster243 バックアップ完了。
halt -pで電源落としました。
Jimさんにcobra2245と同じRAID 1カードの手配とOSのインストールをお願いしました。
完成後、BBQを2台体制へと。 news18 なんですが、
FTPでloginしたとき
移動できないフォルダがあるのと
すぐ切れちゃうのに困ってます ex7が昨夜死んだ問題ですが、どうもmksnap_ffsがごくたまにうまくいかないことがある予感。
今はうまくいってちゃんとdumpが動き出したので、大丈夫かなと。
この現象はこれまでex7が一番頻度高いので、
やはり24時間いつでも忙しく書き換わっているディスクだと、
虫を踏む可能性も高まるということなのかも。 こっちの方がいいか、
>>162
RAID1化したらbackup作業しなくても良くなる?
最大能力が下がるからそんな事は考えないほうが良い?
それとも dat落ち時に二台目のHDにもコピーするとか
別の事を考えたほうが良い? ミラーリングならバックアップは無くてもいい「カモ知れません」ですね。
最大能力はシングルと変わるコトは無いと思われます。
ただ,ミラーリングだと今の高頻度アクセスが分散されるわけではないので,
2台ともどっかんという可能性も無きにしも非ず。てな感じすかねー おぉ、こっちですか。
下記に書いたこと以外には、、、。
処理能力は、それなり以上のRAID1カードを使えば、それほど落ちないはず。
datももちろんですが、例えばcgiのソースとか掲示板システムのこととかも、少し考えてました。
いつでも同じ手順でバックアップから戻せばいいのは、やはり楽なんで。
http://qb5.2ch.net/test/read.cgi/operate/1106798949/583
583 名前:root▲ ★[sage] 投稿日:05/02/21 19:13:11 ID:???0
>>580
RAID1化は系としての信頼性を向上させますが、
容量が半分になるんで、その対策が必要になりますね。
HDDの容量を倍にするかんじで。(36G x 2 => 72G x 2でRAID1)
ex7だと既に掲示板だけで10G以上使っているので(しかしみんなよく書くすね)、
合計が36Gx1になると、ちと不安かもです。
あと、間違ってばさっと掲示板システム上の何かを上書きしちゃった場合に
x日前の状態(x < 7、日曜夜が起点)に戻すのが、できなくなります。
でもこれは「そのときはあきらめましょー」という形態にする、というのも、ありです。
個人的には、掲示板側の日々のバックアップはあんまり省略したくないなぁと思っていたり。
(システム側は正直、よいのです。また入れればいいだけだから) >>164
それも、ちょっとあるですね。<どっかん
そういえば昔、私にいろいろ教えてくれた師匠は「RAIDを過信するな」が口癖でした。
確かにRAIDって、だめになるときはいきなり全部だめになりますからね。 データの保全には3つの種類があると思う。
1.リダンダト
2.バックアップ
3.アーカイヴ
RAID1ミラーリングはredundantで堅牢性をあげるだけ。
つまり故障に対する対策だけ。これをリダンダントという。
そしてバックアップとは。
OSやソフトや操作をヘクって間違ったデータを書き込んだり誤消去することへの対策。
過去に名pcサーバーの移転で誤消去があったので必要性は十分。
アーカイブとは、蓄積されたデータを何らかの形で保存すること。
1.はどの段階にも必要な要素。
しかし1.が出来ているからといって2.が不必要なわけではない。
同様に1.と2.が出来ているからといって、3.が不必要なわけではない。
つまり「RAID1でミラーリングしているからバックアップはいらない」というのは
バックアップという言葉の意味に2.や3.が含まれてしまっている。
本当はリダンダントが実現しているからといってバックアップは不要ではない。 find.2ch.net
210.135.97.161 -> 210.135.97.29
変更お願いします
http://qb5.2ch.net/test/read.cgi/operate/1108830303/592
592 :ひろゆき@どうやら管理人 ★ :05/02/22 17:15:19 ID:sNJciQmQ ?##
2chのzoneファイルを
find A 210.135.97.29
に変えてもらおうと思ったら、ジムがいない。。。 >>168ですけど、
(今)
+find.2ch.net:210.135.97.161
(設定後)
+find.2ch.net:210.135.97.29
になるんでしょうか?
違ったらスマソ>root先生 find.2ch.net のMXレコードの内容をどの様な
内容に修正すれば良いかご指示下さい。
@find.2ch.net:210.135.97.162:300
修正前の登録情報では、AレコードのIP
アドレスは 210.135.97.161、MXレコード
では1番違いの 210.135.97.162 となって
おりました。
現在Aレコードは指定のIPアドレスに変更
しましたが、MXレコードは未修正のまま
となっております。
>>169
It's correct.
>>171
これは、ひ(りゃ の指示待ちすね。私にはわかんないです。
user@find.2ch.net のメールを、どう扱うか。
今のままでいいのか、あるいは帰るのか。 >>177
ノシ
工事の明確な時間とかわかればお願いしますです。。。(´・ω・`) >>177
local-host-namesにいままでfind.2ch.net無かった‥orz
足しときました。 >>182
あ、ブ(りゃ の中の人だ。
ごぶさたです。 ちわちわ。
色々お手間かけてすみません。
&ありがとうございます。 >>177
aa5の代わりの新型牡蠣鯖マダ―(・∀・)―ン 物凄い低コストで実行中のプログラムから LA を取る方法ってありますか?
C , Perl おっ
そりつかって、、、
高LA時のread.cgiの挙動を変えるのに挑戦してみよう。
意味無かったら止めるけどさ、
お、これは例の ex9 的対策(半自動で人大杉にするとか)かしら。
LAだけだと、微妙かもですね。
bananaのLA=10は今の状況だと正直もうだめぽだけど、
tiger/cobraのLA=10はまだ余裕とか、そのへんのバランスは考慮したいかも。
(昔なつかしい「お茶飲め」と同じ理屈です)
このへんは、何らかの形でconfigurableにすればいいのかな。 ex7で「ミニ雪だるま」の実験をはじめた。
具体的には、port 80にsquidをかましてみた。
squid + mod_rpaf を利用。
httpdは、127.0.0.1経由でアクセス。
どのくらいキャッシュが効くかとか、果たして意味があるのかとかは、未知数。
しばらく観察ということで。 >>191
mrtgはとってますでしょうか
・・・とおもったけど、既存のex7の統計の変化でわかりますねw というわけで、備忘録。
【ミニ雪だるま作戦】ex7で15:30ごろまで書けたのに急に書けなくなった人はこちらへ
http://qb5.2ch.net/test/read.cgi/operate/1110179194/
で、
117 名前:root▲ ★[sage] 投稿日:05/03/07 16:43:34 ID:???0
今のまとめ:
・YBBから書き込めない、スレ立てできない
・一部2ちゃんねるビューワでスレ取得時に416エラーが出る
・〃スレ取得ができない場合がある(たぶん原因は上と同じか)
・i.i2ch.netとかt2 t3とかから見られない・読めない・書けない、c.2ch.netからは正常
といったところか。
一部.jpなISPからも、書けない人がいたのかも。 YBBから書き込めない、スレ立てできない、は、なんとなく理解できたんで、
対策できると思います→設定の問題
416エラーは、Apacheとsquidの相性の問題とか設定の問題がありそう→精査が必要
i2ch.netやt2/t3からだめなのも、たぶん上と同じか。
あと、squidの状況としては、
httpd_accel_with_proxy on
で
cache_dir aufs /usr/local/squid/cache 128 16 256
の方が、
cache_dir null /tmp
の時よりも圧倒的にシステムの負荷が少なかったので、
ローカルキャッシュありの方が、やはりよさげか。
MRTGのほうは、どうだろう。 refresh_patternのところの、override-lastmod と reload-into-imsは、
やめたほうがよさげ。< 416 エラー対策 negative_ttl 0
にしないといけないっぽい。 いろいろ検索していたら、こんなの出てきた。5年前か。
2chのサーバとしてFreeBSDを採用してみる例
http://piza.2ch.net/log/unix/0008251/957884791.html ミニ雪だるま実験 続き
ex7.2ch.netだけでなく、tiger503.maido3.comや206.223.150.110でもアクセス可能にした。
YBB書けない問題は、mod_rpafにパッチをあてて対応した。
416エラーは、squidをrange_offset_limit -1にしたら出なくなった。 これからのチェックポイントと解決すべき課題
・雪だるまのローカルキャッシュが、どのくらい働くのか
・雪だるまのhttpアクセラレーションが、どのくらい働くのか
・i.i2ch.net / t1 t2 t3 が動かない問題の解決 残るTODO:
・携帯プライベートネットワーク用スイッチの件
・oyster243の件
本日は、ここまで。 squid のソースをざっと見てみると,どうやら HTTP/1.0 ベースで作られているようですね.
HTTP/1.0 では,リクエストに Connection ヘッダがない場合のデフォルトが close なのが
http://qb5.2ch.net/test/read.cgi/operate/1109941496/845-847n の原因かと.
また,chunked 転送ができないので Content-Length 指定のない CGI 出力などは
Keep-Alive にはできない,と.HTTP/1.1 利用なら Apache の mod_proxy となりますか.
あと,read.cgi 出力の効果的なキャッシュのためには,やはり Last-Modified 吐いた方がいいのかも...... >>202を見ると、ローカルキャッシュのヒット率が30%ぐらいですね。
ディレイ0秒、しかもcgi出力のキャッシュなし(下記)でこの成績なのは、なかなか。
acl QUERY urlpath_regex \.cgi cgi-bin \?
no_cache deny QUERY
確かにHTTP/1.1なら、Apacheのほうがいいかもしれないですね。
Apacheでやるとなると、客の相手するやつはやっぱりworker MPMですかね。
別サーバなら、preforkでもいいのかもですが。
そういえば、Last-Modifiedがないんですね。
だとするとキャッシュさせても、あんまり意味がない予感。
以降は、雪だるま作戦かな。 TODO: memoriesのアクセスログを1つに出力する
難易度: 楽
★★★ ひさびさにPV(ページビュー)当てクイズでも・・・ Part1
http://qb5.2ch.net/test/read.cgi/operate/1104955745/194-195 ディスクキャッシュは、掲示板型だと(特にex7やlive系だと)、
逆に重荷になるらしい。
雪だるま作戦のスレでもSunOsさんが書いていたけど、メモリキャッシュにいかに乗せるか、
が、重要なポイントらしい。
あと、後ろに回したhttpdは、KeepAliveをそのままで動かしていると、
Kばっかりになって逆効果になる場合も、どうやらあるらしい。
といったところか。 # request_header_max_size 20 KB
# for long URL of offlaw.cgi
request_header_max_size 40 KB
と、
# reply_header_max_size 20 KB
# for long URL of offlaw.cgi
reply_header_max_size 40 KB
を、増やした。下のほうは、念のため。 で、
liveb1をフロントエンド化へと。親はlive15で。 menu.2ch.net 土地作りしました。
PV計測の仕掛けを導入済み。
とりあえず、これで見えます。
http://menu.peko.2ch.net/
ということで、以下のDNS登録依頼を。
+menu.2ch.net:206.223.151.10 >>212
確認したです。
http://menu.2ch.net/
さて、これからアカウント情報発射しておきます。
・ひ(りゃ
・おじさん
・まほらさん
・サザンさん
・ボヤッキーさん こっち向きの話なので
いつの間にか正式リリース予定が近づいていたり
Upload to ftp-master. 2 Apr 2005
ttp://www.freebsd.org/releases/5.4R/schedule.html >215
暇だったのでさらに調べたところ、6.0も今年中に来そうでしかもその際にGCC4.0を
標準搭載する模様です。 もう、5.4-PRERELEASE ぐらいのはず。
こんどのはかなり安定度上げる方向みたいですね。
個人的には、ひそかに期待していたりします。 いや5.4Rは4/4の予定だけど、順調に遅れてます。
■ このスレッドは過去ログ倉庫に格納されています