アカウント名:
パスワード:
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますがこういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことはそれほど難しいことなのでしょうか?
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変それでもネットワークを二重化するとか対策はできそうだけど
いや、その2重化が仇になっている可能性も。発表されたページでは細かいことは分からないが、「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
pingは確実に通るけどtcp/udpは時々通らないという故障をしたスイッチがあってな。。それはもうはまりましたよ。実際に使用するプロトコルで「も」やった方が良いと思うんだ。
おまえは俺かよ!この件は今話題のC社のだったけど、シェアからするとまあ敢えて言うほどでもないかもしれん。
それ割とよくある話ではちなみに私もここ一年で二回引きました懸賞とかもこのくらい当たってくれないと不公平だ
それってポートステータスにはエラーパケットとして出てなかったのかが気になる
効率は悪いけど、運用されている機能の上にウオッチドックを入れるしかないかな。ただそうすると規模が上がれば上がるほど、高層ビルのエレベーターみたいな問題が。
追加すると「通信自体来てない」ことになってた。
もしかしたらハード選別した86系PCにLinuxやWindowsで役割特化させて作った方がリスク低いのでは?と思うようになった。
今の時代、アップデート不可/無しではだめなので、切り詰めた専用ハード/ソフトより無難じゃないか?と。。
サイズや速度は兎も角、モノカルチャー化もリスクですけどね。。
ヤスモン HUB が壊れてですね、 Path MTU Discovery blackhole になった時に、ハマりました。web も一部出る、画像も一部でる、 ping は(オプションなししか試してなかったので)通るという症状で、時間がかかりました。PC をケーブルモデム直結でつながる、ブロードバンドルータにつなげてもつながる、使いたい場所で使おうと思うと使えない、天井裏にある HUB が問題でした。メーリングリストで聞いたら、 ping のサイズをだんだん大きくしたらどうか?というので、試してわかりました。
他にはファイルサーバのそばにあるヤスモン HUB が壊れてですね、セキュリ
スイッチの故障じゃないけど似たような経験が。
オフィスの末端機器だけどpingは通るのに通信ができないと激怒りで呼び出された。確かにpingは通るけど、TCPと使った通信は全滅。pingのパケットサイズを大きくするとこけた。調べていくと、イーサケーブルをテスターであたると導通のない線があり、客が自分でコネクタを圧着したイーサケーブルの断線か圧着不良が原因・・・。イーサケーブル交換で復旧。
#テスターで導通ないんだから「ping通るんだからおかしいだろ」とか開き直られても困る。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
素人にわかるように、解決の難しさを教えて (スコア:0)
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
こういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことは
それほど難しいことなのでしょうか?
Re: (スコア:0)
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変
それでもネットワークを二重化するとか対策はできそうだけど
Re: (スコア:5, すばらしい洞察)
いや、その2重化が仇になっている可能性も。
発表されたページでは細かいことは分からないが、
「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」
「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
Re:素人にわかるように、解決の難しさを教えて (スコア:2, 参考になる)
pingは確実に通るけどtcp/udpは時々通らないという故障をしたスイッチがあってな。。
それはもうはまりましたよ。
実際に使用するプロトコルで「も」やった方が良いと思うんだ。
Re: (スコア:0)
おまえは俺かよ!
この件は今話題のC社のだったけど、シェアからするとまあ敢えて言うほどでもないかもしれん。
Re: (スコア:0)
それ割とよくある話では
ちなみに私もここ一年で二回引きました
懸賞とかもこのくらい当たってくれないと不公平だ
Re: (スコア:0)
それってポートステータスにはエラーパケットとして出てなかったのかが気になる
Re: (スコア:0)
効率は悪いけど、運用されている機能の上にウオッチドックを入れるしかないかな。
ただそうすると規模が上がれば上がるほど、高層ビルのエレベーターみたいな問題が。
Re: (スコア:0)
追加すると「通信自体来てない」ことになってた。
もしかしたらハード選別した86系PCにLinuxやWindowsで役割特化させて作った方がリスク低いのでは?と思うようになった。
今の時代、アップデート不可/無しではだめなので、切り詰めた専用ハード/ソフトより無難じゃないか?と。。
サイズや速度は兎も角、モノカルチャー化もリスクですけどね。。
Re: (スコア:0)
ヤスモン HUB が壊れてですね、 Path MTU Discovery blackhole になった時に、ハマりました。
web も一部出る、画像も一部でる、 ping は(オプションなししか試してなかったので)通るという症状で、時間がかかりました。
PC をケーブルモデム直結でつながる、ブロードバンドルータにつなげてもつながる、使いたい場所で使おうと思うと使えない、天井裏にある HUB が問題でした。
メーリングリストで聞いたら、 ping のサイズをだんだん大きくしたらどうか?というので、試してわかりました。
他にはファイルサーバのそばにあるヤスモン HUB が壊れてですね、セキュリ
Re: (スコア:0)
スイッチの故障じゃないけど似たような経験が。
オフィスの末端機器だけどpingは通るのに通信ができないと激怒りで呼び出された。
確かにpingは通るけど、TCPと使った通信は全滅。pingのパケットサイズを大きくするとこけた。
調べていくと、イーサケーブルをテスターであたると導通のない線があり、
客が自分でコネクタを圧着したイーサケーブルの断線か圧着不良が原因・・・。
イーサケーブル交換で復旧。
#テスターで導通ないんだから「ping通るんだからおかしいだろ」とか開き直られても困る。