アカウント名:
パスワード:
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますがこういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことはそれほど難しいことなのでしょうか?
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変それでもネットワークを二重化するとか対策はできそうだけど
いや、その2重化が仇になっている可能性も。発表されたページでは細かいことは分からないが、「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
pingは確実に通るけどtcp/udpは時々通らないという故障をしたスイッチがあってな。。それはもうはまりましたよ。実際に使用するプロトコルで「も」やった方が良いと思うんだ。
おまえは俺かよ!この件は今話題のC社のだったけど、シェアからするとまあ敢えて言うほどでもないかもしれん。
それ割とよくある話ではちなみに私もここ一年で二回引きました懸賞とかもこのくらい当たってくれないと不公平だ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
素人にわかるように、解決の難しさを教えて (スコア: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)
それ割とよくある話では
ちなみに私もここ一年で二回引きました
懸賞とかもこのくらい当たってくれないと不公平だ