アカウント名:
パスワード:
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますがこういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことはそれほど難しいことなのでしょうか?
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変それでもネットワークを二重化するとか対策はできそうだけど
いや、その2重化が仇になっている可能性も。発表されたページでは細かいことは分からないが、「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
どういう壊れかたしたのかもう少し知りたいですよね。
LAG組んでたらLACPで凡その障害は検知できますしauto negoにしておけばL1障害も結構検出可能。BFD入れておけばIPレベルの死活もばっちり。
ほんとにちゃんと設計されてたんだろうかと気になります。DB同期ラインし適当でいいやってただデフォルト設定で突っ込んでたりして・・・。
>LAG組んでたらLACPで凡その障害は検知できますしLACP処理するチップまでの障害しか検知できないですね。LACP punt後のトランジットパスでエラーが起きたら見えない。
>auto negoにしておけばL1障害も結構検出可能。見えるのはPHYまでですね。LACPよりもっと手前。
>BFD入れておけばIPレベルの死活もばっちり。Echoだと、LAGで1リンクにしか通らなないから、ほかのリンクは見えない。IETF bfd over LAGだとAsyncしかサポートしない。AsyncだとLACPと変わらないレベル。Ciscoプロプラのbobだと全リンクでechoできますが、それでもラインカード内部で通らないデータパスがある。(そもそもXRでないと、bobサポートしてないですけど)
>ほんとにちゃんと設計されてたんだろうかと気になります。LACP、auto neg、BFD程度で、障害拾えたはず、と本気で思うのなら、あなたの経験が浅いだけです。そんなので拾える障害は「きれいな」障害で、それ以外の部分がSIerや通信キャリアのノウハウなわけです。
>LACP処理するチップまでの障害しか検知できないですね。>LACP punt後のトランジットパスでエラーが起きたら見えない。
K10のLACPがASIC処理だとは初めて知りました。てっきりCPUだとばかり。
>LACP、auto neg、BFD程度で、障害拾えたはず、と本気で思うのなら、あなたの経験が浅いだけです。
いやはやこれは手厳しい。
ただちょっと思ったのは今回oracle RACと思しきシステムの同期ライン障害できちんと切り離せないなどミドルウェア側も運用も若干お粗末に思えましたので、スイッチ側だけ凄腕SIerだの通信キャリアなみに徹底してたとは考え難かったのでそうコメントいたしました。
ずいぶん詳しそうな方ですけど、もしよければどんなテクニックがあればLACPで救えないケースを検知して切り離せるか教えていただけませんか?
個人的にはこの手のBOXスイッチでLACPとかUDLDでだめな障害は基本お手上げかなと思ってます。いっそスイッチなんか無視してE2EでMPLSやVXLANでも張るか(笑)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
素人にわかるように、解決の難しさを教えて (スコア:0)
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
こういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことは
それほど難しいことなのでしょうか?
Re: (スコア:0)
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変
それでもネットワークを二重化するとか対策はできそうだけど
Re: (スコア:5, すばらしい洞察)
いや、その2重化が仇になっている可能性も。
発表されたページでは細かいことは分からないが、
「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」
「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
Re: (スコア:1)
どういう壊れかたしたのかもう少し知りたいですよね。
LAG組んでたらLACPで凡その障害は検知できますし
auto negoにしておけばL1障害も結構検出可能。
BFD入れておけばIPレベルの死活もばっちり。
ほんとにちゃんと設計されてたんだろうかと気になります。
DB同期ラインし適当でいいやってただデフォルト設定で突っ込んでたりして・・・。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
>LAG組んでたらLACPで凡その障害は検知できますし
LACP処理するチップまでの障害しか検知できないですね。
LACP punt後のトランジットパスでエラーが起きたら見えない。
>auto negoにしておけばL1障害も結構検出可能。
見えるのはPHYまでですね。LACPよりもっと手前。
>BFD入れておけばIPレベルの死活もばっちり。
Echoだと、LAGで1リンクにしか通らなないから、ほかのリンクは見えない。
IETF bfd over LAGだとAsyncしかサポートしない。AsyncだとLACPと変わらないレベル。
Ciscoプロプラのbobだと全リンクでechoできますが、それでもラインカード内部で通らないデータパスがある。
(そもそもXRでないと、bobサポートしてないですけど)
>ほんとにちゃんと設計されてたんだろうかと気になります。
LACP、auto neg、BFD程度で、障害拾えたはず、と本気で思うのなら、あなたの経験が浅いだけです。
そんなので拾える障害は「きれいな」障害で、それ以外の部分がSIerや通信キャリアのノウハウなわけです。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
>LACP処理するチップまでの障害しか検知できないですね。
>LACP punt後のトランジットパスでエラーが起きたら見えない。
K10のLACPがASIC処理だとは初めて知りました。
てっきりCPUだとばかり。
>LACP、auto neg、BFD程度で、障害拾えたはず、と本気で思うのなら、あなたの経験が浅いだけです。
いやはやこれは手厳しい。
ただちょっと思ったのは今回oracle RACと思しきシステムの同期ライン障害できちんと切り離せないなど
ミドルウェア側も運用も若干お粗末に思えましたので、スイッチ側だけ凄腕SIerだの
通信キャリアなみに徹底してたとは考え難かったのでそうコメントいたしました。
ずいぶん詳しそうな方ですけど、もしよければどんなテクニックがあれば
LACPで救えないケースを検知して切り離せるか教えていただけませんか?
個人的にはこの手のBOXスイッチでLACPとかUDLDでだめな障害は基本お手上げかなと思ってます。
いっそスイッチなんか無視してE2EでMPLSやVXLANでも張るか(笑)