アカウント名:
パスワード:
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますがこういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことはそれほど難しいことなのでしょうか?
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変それでもネットワークを二重化するとか対策はできそうだけど
いや、その2重化が仇になっている可能性も。発表されたページでは細かいことは分からないが、「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
今のMC/ServiceGuardの推奨構成はHUBありですね。メーカーの人にクロスじゃダメなんですか?と訊いたら「どちらかのハード故障かケーブル故障か切り分けが出来ない場合がある」とのことまぁ、故障のポイントもお金も増えるし、どっちもどっちかなぁと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
素人にわかるように、解決の難しさを教えて (スコア:0)
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
こういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことは
それほど難しいことなのでしょうか?
Re: (スコア:0)
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変
それでもネットワークを二重化するとか対策はできそうだけど
Re: (スコア:5, すばらしい洞察)
いや、その2重化が仇になっている可能性も。
発表されたページでは細かいことは分からないが、
「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」
「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
Re: (スコア:1)
当時は「今時10Base2かよ」と思ったけど、HUBの故障を考えなくていいので、間違ってなかったのかもしれない。
Re:素人にわかるように、解決の難しさを教えて (スコア:0)
今のMC/ServiceGuardの推奨構成はHUBありですね。
メーカーの人にクロスじゃダメなんですか?と訊いたら
「どちらかのハード故障かケーブル故障か切り分けが出来ない場合がある」
とのこと
まぁ、故障のポイントもお金も増えるし、どっちもどっちかなぁと