アカウント名:
パスワード:
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますがこういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことはそれほど難しいことなのでしょうか?
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変それでもネットワークを二重化するとか対策はできそうだけど
いや、その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通るんだからおかしいだろ」とか開き直られても困る。
今のMC/ServiceGuardの推奨構成はHUBありですね。メーカーの人にクロスじゃダメなんですか?と訊いたら「どちらかのハード故障かケーブル故障か切り分けが出来ない場合がある」とのことまぁ、故障のポイントもお金も増えるし、どっちもどっちかなぁと
どういう壊れかたしたのかもう少し知りたいですよね。
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でも張るか(笑)
確かに、複雑なシステムほど、実際にトラブルとわかりにくいってあるよね。
DBを2重化して、複数のスイッチがたすきがけで各サーバーと接続するようにして・・と提案されたことあったけど、複雑すぎるのでやめたことあった。構築する人は最初の設定しかしないからいいけど、運用している方はトラブルあった時の対応なども考えないとダメだしスイッチやルーターにもトラブルあるから、使う機器はできるだけ減らしたいってのがあったので結局ソフトウェア側で冗長化したんだったかなw
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
※ただしPHPを除く -- あるAdmin
素人にわかるように、解決の難しさを教えて (スコア: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通るんだからおかしいだろ」とか開き直られても困る。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
当時は「今時10Base2かよ」と思ったけど、HUBの故障を考えなくていいので、間違ってなかったのかもしれない。
Re: (スコア:0)
今のMC/ServiceGuardの推奨構成はHUBありですね。
メーカーの人にクロスじゃダメなんですか?と訊いたら
「どちらかのハード故障かケーブル故障か切り分けが出来ない場合がある」
とのこと
まぁ、故障のポイントもお金も増えるし、どっちもどっちかなぁと
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でも張るか(笑)
Re: (スコア:0)
確かに、複雑なシステムほど、実際にトラブルとわかりにくいってあるよね。
DBを2重化して、複数のスイッチがたすきがけで各サーバーと接続するようにして・・
と提案されたことあったけど、複雑すぎるのでやめたことあった。
構築する人は最初の設定しかしないからいいけど、運用している方はトラブルあった時の対応なども考えないとダメだし
スイッチやルーターにもトラブルあるから、使う機器はできるだけ減らしたいってのがあったので
結局ソフトウェア側で冗長化したんだったかなw