■ サーバリフレッシュ工事 連絡・作業スレッド7
■ このスレッドは過去ログ倉庫に格納されています
TBananaサーバやら新型TigerやらE-banana(ぞうさん)サーバやらT-banana64やらと 新型サーバ( http://server.maido3.com/ )の投入で、しばらくの間だらだらと続けていく予定の、サーバリフレッシュ工事に関する 連絡・作業用のスレッドです。 ○ サーバリフレッシュ工事とは 同一サーバにおける掲示板のバーチャルホスト(名前)を変更することにより (基本的には番号を一つ増やす)、サーバの負荷を軽減し、 またHDDの容量を稼ぐことで、サーバの寿命を延ばすための工事のことです。 移転作業が始まると ・移転元サーバで書き込みができなくなります ・更に移転元サーバの板・スレが見えなくなります ・移転先サーバには最初スレッドがない状態になります ・待っているとそのうちスレッドも移転します bbsmenuはいつ更新されるの? 待っていればそのうち(一日以内)に更新されます。 携帯からはhttp://u.la/ に臨時メニューがあるのでそこから見れます(^_^;) bbsmenuが更新されたら、専用ブラウザの板一覧も更新しましょう。 過去スレ ■ サーバリフレッシュ工事 連絡・作業スレッド6 http://qb5.2ch.net/test/read.cgi/operate/1197714924/ ■ サーバリフレッシュ工事 連絡・作業スレッド6 http://qb5.2ch.net/test/read.cgi/operate/1197714206/ ■ サーバリフレッシュ工事 連絡・作業スレッド5 http://qb5.2ch.net/test/read.cgi/operate/1196924126/ ■ サーバリフレッシュ工事 連絡・作業スレッド4 http://qb5.2ch.net/test/read.cgi/operate/1193498210/ ■ サーバリフレッシュ工事 連絡・作業スレッド3 http://qb5.2ch.net/test/read.cgi/operate/1169662973/ ■ サーバリフレッシュ工事 連絡・作業スレッド2 http://qb5.2ch.net/test/read.cgi/operate/1168090804/ ■ サーバリフレッシュ工事 連絡・作業スレッド http://qb5.2ch.net/test/read.cgi/operate/1119623185/ 54 root▲▲ ★ 2007/12/16(日) 14:08:48 ID:???0 BE:?-PLT(80222) 64 bytes from 207.29.253.230: icmp_seq=119 ttl=253 time=0.996 ms 64 bytes from 207.29.253.230: icmp_seq=120 ttl=253 time=1.072 ms 64 bytes from 207.29.253.230: icmp_seq=121 ttl=253 time=1.033 ms 64 bytes from 207.29.253.230: icmp_seq=122 ttl=253 time=1.108 ms 64 bytes from 207.29.253.230: icmp_seq=124 ttl=62 time=1.009 ms 64 bytes from 207.29.253.230: icmp_seq=125 ttl=62 time=0.963 ms 64 bytes from 207.29.253.230: icmp_seq=126 ttl=62 time=1.036 ms 64 bytes from 207.29.253.230: icmp_seq=127 ttl=62 time=7.233 ms 64 bytes from 207.29.253.230: icmp_seq=128 ttl=62 time=46.657 ms 64 bytes from 207.29.253.230: icmp_seq=129 ttl=253 time=1.138 ms 64 bytes from 207.29.253.230: icmp_seq=130 ttl=253 time=186.718 ms 64 bytes from 207.29.253.230: icmp_seq=131 ttl=253 time=1.161 ms 64 bytes from 207.29.253.230: icmp_seq=132 ttl=253 time=1.243 ms 56 root▲▲ ★ 2007/12/16(日) 14:09:08 ID:???0 BE:?-PLT(80222) で、しばらくしてまた、 64 bytes from 207.29.253.230: icmp_seq=151 ttl=253 time=1.185 ms 64 bytes from 207.29.253.230: icmp_seq=152 ttl=253 time=1.390 ms 64 bytes from 207.29.253.230: icmp_seq=153 ttl=253 time=1.211 ms 64 bytes from 207.29.253.230: icmp_seq=154 ttl=253 time=1.295 ms 64 bytes from 207.29.253.230: icmp_seq=155 ttl=253 time=1.117 ms 64 bytes from 207.29.253.230: icmp_seq=156 ttl=253 time=1.315 ms 64 bytes from 207.29.253.230: icmp_seq=157 ttl=62 time=1.272 ms 64 bytes from 207.29.253.230: icmp_seq=158 ttl=62 time=2.223 ms 64 bytes from 207.29.253.230: icmp_seq=159 ttl=62 time=1.423 ms 64 bytes from 207.29.253.230: icmp_seq=160 ttl=62 time=1.362 ms 64 bytes from 207.29.253.230: icmp_seq=161 ttl=62 time=1.451 ms 64 bytes from 207.29.253.230: icmp_seq=162 ttl=62 time=1.152 ms で、動きは music8/tv11 = banana3215 もほぼ同じですね。 でもネットワークパフォーマンス的には健康に動いている。 スイッチというかネットワークの動きは変だけど、 どのポートも同じように変なのか。 で、パフォーマンスが出ていないのは banana3216 だけで、 かつ、同一サブネットではないところに行くときだけか。 >>91 は、日本語がアレだった 4回ほど連続でタイムアウト=リブートが入り? その後数秒間は、TTL240のち>>91 になった このログは流れちゃった その後のbanana3216状況 Reply from 207.29.253.235: bytes=1 time=309ms TTL=53 Reply from 207.29.253.235: bytes=1 time=187ms TTL=240 Reply from 207.29.253.235: bytes=1 time=150ms TTL=240 Request timed out. Request timed out. Request timed out. Reply from 207.29.253.235: bytes=1 time=151ms TTL=240 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 Reply from 207.29.253.235: bytes=1 time=155ms TTL=240 Request timed out. Request timed out. Reply from 207.29.253.235: bytes=1 time=182ms TTL=240 〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜 Reply from 207.29.253.235: bytes=1 time=172ms TTL=240 Request timed out. Reply from 207.29.253.235: bytes=1 time=141ms TTL=53 Reply from 207.29.253.235: bytes=1 time=170ms TTL=53 原因特定されたっぽいんで、監視中止しますね と思ったら、、、あれ? Reply from 207.29.253.235: bytes=1 time=144ms TTL=53 Reply from 207.29.253.235: bytes=1 time=137ms TTL=53 Reply from 207.29.253.235: bytes=1 time=159ms TTL=240 Reply from 207.29.253.235: bytes=1 time=152ms TTL=240 これは他の鯖でも起こるかもしれない? たまたまbanana3216の運が悪かっただけ? tiger504 から banana3216 に ping かけながら、 ifconfig em0 link 00:16:76:b0:32:16 を banana3216 で実行すると、その瞬間に、 64 bytes from 207.29.253.235: icmp_seq=4 ttl=62 time=269.331 ms 64 bytes from 207.29.253.235: icmp_seq=5 ttl=62 time=289.114 ms 64 bytes from 207.29.253.235: icmp_seq=6 ttl=62 time=252.973 ms 64 bytes from 207.29.253.235: icmp_seq=8 ttl=62 time=269.371 ms 64 bytes from 207.29.253.235: icmp_seq=9 ttl=253 time=1.113 ms 64 bytes from 207.29.253.235: icmp_seq=10 ttl=253 time=1.313 ms 64 bytes from 207.29.253.235: icmp_seq=11 ttl=253 time=1.374 ms 64 bytes from 207.29.253.235: icmp_seq=12 ttl=253 time=1.081 ms となりました。 やはり、PIE のスイッチで何かやってますね。 banana3215も、リブート中はTTL255の応答は返るのかな? ping に関する結論: 少なくとも 207.29.253.* のサブネットについては、 ping ではサーバの状況はきちんとつかめない。 特に、64 より大きな TTL の ping (FreeBSD が作っていない)は、 サーバがリブート中であっても来る。 現在の PIE のネットワークは、そういう設定になっている。 r 、 i `、 ', ', /´`, , -‐'~_-、i、 ハ ! ',_ .ror‐ 、/し`, ',Y´,' ', '、`iし'、_rノ`ー'ノ'i_ノ ` - ..._>i',ィエ工工エェ、j ` iー、 ̄r―イ / ',` .〉 .i, ! i ,' i ', `、 Y ノ', i 'ヘハjハN´ノ ', / `ー=ニ、 j ´'ー-'´ r'ェ、_'ュ >>129 了解。MACアドレス(3者交代?)から攻めるべきかな? で、>>122 からすると、 ネットワークの設定よりも、サーバに固有の問題のような気もしてきました。 ★banana3215 とソフトウェア的な動作はほぼ同じだが、 banana3215のネットワークは健康で、banana3216のネットワークはおかしい ★banana3215とbanana3216の接続するスイッチを物理的にスワップしても 問題は変わらなかった >>132 管理上の問題なんでしょう、きっと。 banana3216 = 00:16:76:b0:32:16 b0 … たぶん「banana」? 32:16 … たぶんサーバの番号 >>129 それって、もしかしてこの前のUDPfloodでそういう対策したとか? 全部鯖に渡すんじゃ無くて、ある程度はスイッチレベルで対応しちゃうとか。 >134 ですです(^_^;)NICのMACって重複してることがあるです>オリジン なので、PIEの内部での重複発生を避けるため、サーバネームにしたがって変更してます。 bananaのマザーだと、BIOSで設定できるんですが、T-bananaのマザーはそれができないので 起動後に変更かけてるです。 >>137 じゃあ、本来はオリジンのMACアドレスは出てこないはずなの? ん?分からなくなってきた。 >>115 の3回MACアドレスが変わる現象は >>120 により問題なし、って事でOK? で、今は3216はMACアドレス書き換えていない状態? MACがダイナミックに変わるのは勘弁してね。って機器やドライバコードはたくさんありそだ。 ソフトイーサがイマイチなのはそーゆー点だと思う。 で、不思議なことに、 banana3215 は banana3216 のことを今でも、 00:19:d1:a4:cd:1e だと、時々思うようです。 banana3216.maido3.com (207.29.253.235) at 00:19:d1:a4:cd:1e on em0 [ethernet] このときは、255オリジンのpingがかかります。 で、 00:16:76:b0:32:16 (今ifconfig で設定したやつ) だと、同一サブネットでもpingがかからなくなります。 banana3214完成(^_^;) T-banana64bit IPは207.29.253.220 スイッチはbanana3215,3216とは別なところに接続 >>137 なるほど、了解です。 出荷時にMACアドレスが重複しているってことですか。 何百台・何千台と入れるとはじめてわかることかも。 >>139 第一段落 今はそう考えています。 第二段落 書き換える状態に戻しました。 で、手で ifconfig link して、rc.local でやっているのと同じ設定にしました。 >>142 アドレスは 207.29.253.* ですか。 スイッチは別と。 で、ネットワークパフォーマンステストは、、、。 >143 んだす(^_^;)最初はかなりびっくりでした >145 これからやるですー(^_^;) 3214と同じサブネット内との相互転送 3216と違いかつ3214と違うサブネットとの相互転送 3216と同じサブネットとの相互転送 うへーMACアドレス重複ってあるんだ ためになった >>142 の個体のネットワークが 別サブネットとの通信でも高パフォーマンスを発揮するかどうかに、 これからの動きというか、命運がかかっている気がします。 NIC標準装備でマザー上に乗る前はカードで買ってくるので 安物を選ぶと時々あったな。同一ロットなのにだぶってるやつ。 30枚同時購入で3組(6枚)がって経験があるw >>147 207.29.253.* ですね。3214 / 3216 両方とも。 %telnet banana3214 Trying 207.29.253.220... Connected to banana3214.maido3.com. Escape character is '^]'. Trying SRA secure login: User (root): あれれれれ? >>152 そっか、これであってるのか。 ごめんなさい。 >>144 rootさん、回答thxです。 でも、>>141 の問題があると。 3215については他鯖がMACアドレスを思い違い することは無いんですよね? 3214が増えたようなので、その動き次第ですか。 設定でお忙しいようなので、ROM専に戻ります。では。 Cygwin のやつからやれば、 Escape character is '^]'. FreeBSD/amd64 (banana3214.maido3.com) (ttyp3) login: こうなるから、問題ないですね。 # BSDとかに入っている頭のいい telnet はいろいろネゴする。 >>154 コメントは継続してどうぞです。 というか、私は所詮趣味の世界だし。 ある意味日曜大工のようなものです。 中の人達にとっては趣味じゃないかもですが。 >147 あー(^_^;)3214と3216は同じサブネットか・・・・ 206.223.148.***との100Mbpsでの相互転送テスト 1GBのファイルの転送は、双方向とも問題なく速度が出た。 >>158 おー、、、。 ちなみに、どのプロトコルでしょう。 あと、NICは100Mbps接続ですか。 であれば、10MBytes/sec 出れば問題ないです。 で、>>158 に 100Mbps って書いてありますね。 だとすると、単に banana3216 が「ぽんこつ」だった、 っていうことなのかしら。 >159 FTPです(^_^;)10MByte/secです >>161 了解です。 ううむ「banana3216がぽんこつだった」説を裏付けつつあるのか、、、。 違いといえば・・・・3216はnamidameが入っていて、負荷がかかっている状態 3214は無負荷状態ってことですか(^_^;) banana3214 のネットワークがうまく動くなら、 banana3214 に namidame を丸ごと移して、 banana3216 にはとりあえずお引取り願うのが、2ちゃんねる的には一番シンプルな気がします。 rootさんが直に確認した方が良いと思う。 マヴァさんを疑う訳じゃなくてインテリジェントなネットはルーティング等も 賢く処理するので、、、 T-bananaの固体差は、ハードということになるんかな? CPU,RAMはそんなに固体差はないとすると原因はマザー?? >>163 httpd 切って試してみるですか。< namidame ν即民で溢れ帰る予感 >>165 root権限付いてないんで無いかい 3216と3214のNICのチップ名と、 OSのkernelおよびNICドライバのバージョン に違いはありますか? httpd 切っても、パフォーマンス出ないですね。 < namidame ftp> get kernel local: kernel remote: kernel 229 Entering Extended Passive Mode (|||60662|) 150 Opening BINARY mode data connection for 'kernel' (3911497 bytes). 100% |*************************************| 3819 KB 748.61 KB/s 00:00 ETA 226 Transfer complete. 3911497 bytes received in 00:05 (748.58 KB/s) ftp> get kernel local: kernel remote: kernel 229 Entering Extended Passive Mode (|||61973|) 150 Opening BINARY mode data connection for 'kernel' (3911497 bytes). 100% |*************************************| 3819 KB 650.63 KB/s 00:00 ETA 226 Transfer complete. 3911497 bytes received in 00:05 (650.61 KB/s) ftp> put kernel local: kernel remote: kernel 229 Entering Extended Passive Mode (|||64385|) 150 Opening BINARY mode data connection for 'kernel'. 100% |*************************************| 3819 KB 1.31 MB/s 00:00 ETA 226 Transfer complete. 3911497 bytes sent in 00:02 (1.30 MB/s) ftp> put kernel local: kernel remote: kernel 229 Entering Extended Passive Mode (|||49822|) 150 Opening BINARY mode data connection for 'kernel'. 100% |*************************************| 3819 KB 329.47 KB/s 00:00 ETA 226 Transfer complete. 3911497 bytes sent in 00:11 (326.48 KB/s) >>169 rootさんならたぶん一般権限でも現象の確認は出来る。 ftp等で試せば良い。 シェルアカウントがあればマシンの空気も読めるはずw macアドレスの重複は俺も初めて聞く現象だ・・・ そりゃ、考え付かないわ・・・ >>170 banana3216 の NIC は、マザボに標準装備のやつですね。 Intel製。 マザボ: INTEL DQ965GF ドライバは、最初 FreeBSD 6.2R/amd64 に標準のやつでやってパフォーマンス出なくて、 今は Intel が提供している最新のものです。でも症状は変化せず。 最初 em0: <Intel(R) PRO/1000 Network Connection Version - 6.2.9> 今 em0: <Intel(R) PRO/1000 Network Connection Version - 6.6.6> banana3214 にアカウント(一般ユーザでおk)作っていただければ、 ファイル転送テストを試すことはできますです。 >>175 RA経由とかで自動でつけてたら、いきなり死にますね、、、。 >>172 あ、ネットワークパフォーマンスの確認云々の話だたのか 勘違いしてました失礼 >170 NICはIntel PRO1000(オンボード) OS同じ ドライバも同じ(百式のものを持ってきた) です(^_^;) >>179 了解です。 やっぱり、banana3216がぽんこつだったのかしら。 というところで、私、一度タイムアウトです。 ちとおでかけ。夜には戻れる予定。 amd64 x86_64 をgentooで2年ほど使ってるがamd64のドライバは怪しい事が多い気がするんだよね。 カーネルコアとの相性って言うのかな? 枯れるのに時間がかかる。 解析した訳じゃなく経験からくる事だから相性って言ってるけど、ハードな環境で使う気にならん。 んと、色々と考えて思い当たったこと(^_^;) 1 3216で書き換えたMACアドレスの上位の桁はIntelとは似ても似つかない(エリートと同じ)値 2 Intelのマザーは遠隔監視用の仕組みがあって、これが有効になっていると、ひとつのNICに二つ目のMACアドレスを振るらしい 3 その際に振るMACアドレスはオリジンの+1らしい 4 現在3216は監視システムが有効になっている(使ってはいない) rootさん、マァヴさん回答thxです。 全部同じですか。。 私もFreeBSDは素人ですが、 分かる範囲で調べてみます。では。ノシ >>183 使う予定無いならとりあえず止めて様子見でいいんじゃないかなー お出かけ前。 >>183 おーー、、、。 あやしい、あやしすぎる。 banana3215 でもその現象、確かに確認しているです。 上位の桁をIntelのにするとか、したほうがいいんじゃないですかね。 あるいはIntelを信用して、そのまま使用するか、 監視システムをオフにするか。 # 今回の原因には関係しなさそうですが。 ドライバ更新って百式のnicが認識しないから更新したんだっけ。 性能比較まではしていないでOK? 沢山鯖を運用してると 俺なんかじゃ考えつかない珍現象が大量に発生するのねぇ・・・ >>188 そのはず(たぶん百式のマザボが新しすぐるから)。 >>182 こんな所で同士発見!(w <同じくgentoo/amd64ユーザー 64bitといっても、linuxカーネルのNICドライバは もうそろそろ大丈夫だと思うけどなぁ。 (メーカー提供のドライバは使った事が無いから分からん。) >186 止め方調べる(^_^;) >187 で、3214は上位がintelだったんで、これをエリートの上位に書き換えるようにして リブート→再び転送実験ってのをやるー(^_^;) >190 了解ですー。 (orzの鯖も似たような環境なので試してみようかしら) pingの件は、FreeBSD-6.2-p7/32bitでIntel/Pro1000(v6.2.9)なやつ3台と、 L3スイッチがExtremeの48Siで確認しているので、多分スイッチ側じゃないかなぁと思います。 どう設定したら直るのかはわかりませんけどw PIEのは確か200-48でしたっけ。 変なMACが現れるとスイッチ側でスパニングツリー再計算とかポートセキュリティが働くとか それで不安定になるのかな >>198 ロジック次第。 中身が判らんと永遠の仮説。 でも、解析なんてやってらんねー 乱暴だけどエンドユーザーとしては正しい姿勢。 まあ、偽装MACの検出・排除はL2レベルの一般論だけどね さて、b3214はこのまま2chに投入になる気がする(^_^;) サブドメインはなんにする? ↓ そう言えば、前々スレでおもしろいのがあったなぁ gomidame.2ch.net hakidame.2ch.net ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる