アカウント名:
パスワード:
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますがこういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことはそれほど難しいことなのでしょうか?
普通の障害解析って、ソフトウエアが複雑な所から疑っていくことが少なくない。そうなると、ネットワーク機器はかなり後になる。
私もスイッチが原因でのトラブルはあったけど、スイッチかぁ？ってなるまで結構時間がかかった経験がある。
確かにネットワーク周りって後回しになりがちですねぇ。
なんなんでしょうね、やっぱり物理的なシステムだと思ってしまうので、堅牢性への妙な期待感があるんでしょうか。
電気が点かなくなったら、普通は、電球か蛍光灯かＬＥＤの寿命が来たと思うわけで、停電とか、配電盤とかに思いが至るのは、その次になるかと。大元のインフラは、なんか大丈夫と思っちゃうんでしょうね。
なお、真っ先に電気代の滞納とか、自分たち以外人類滅亡とかが頭をよぎるのは、かなりの上級者ですので、ご注意ください。
ああ、そういう行動パターンもあるんですね。っていうか、どの放送局に電話かけるのかは気になります。やっぱ、NHKなんでしょうか。そして流れるように受信契約へ。だから映らないって言ってるのに〜、となるまでが、ワンセット。
スイッチが壊れていると分かればあとは交換するだけですが、「DBサーバが一台構成の場合は問題なく、複数台構成にすると問題が発生する」という現象から故障箇所がスイッチであると特定するのには時間がかかりそうです。実際に今回の場合もDBサーバ、アプリサーバそれぞれに問題が無いことを確認した後にスイッチの不具合を疑っていますから。
そういうのって自動化できないんかな。ネットワークなんだからあちこちでパケット監視すればできそうな気がするんだが。
今回の件は監視している相手が嘘ついたという話ですので。
そら一カ所しか見てないから見逃すんでは。エンドツーエンドで監視すれば色々分かるような気がする。
ここの経路が死にました！→ケーブルかIFボードかスイッチかマザボかOSかアプリかってのは変わらない気が
(サーバー側視点では)エンドツーエンドで監視してるから同期が取れてないのでフェイルオーバーするんですよ。でも通信が完全に途切れてるわけじゃないのでどこが悪いのかよくわからんのです
だからネットワーク内にいくつもノードを配置して通信状況を観測すれば自動的に故障箇所を特定できるんじゃ
なにをもってどこの故障と判定するのかが難しいんだって
とはいえ、ノード網羅して通信状況見て判定する製品というのはEMC Smartsとかであるにはある。
そんな「このゲームの敵はどうやって動かすんですか」「CPUに考えさせるんだよ」みたいな……
Aviation Wireの記事 [aviationwire.jp]の情報を見つつ…・DBサーバが止まり、複数台動かすと不安定な状態になること・1台で動かせば正常動作することこれにより比較的早期に、1台での運用による仮復旧は出来たことでしょう。ここから障害の切り分けに入ります。状況的にまず最初にシステムのOSやソフトウェアが疑われたかもしれません。夜間にパッチなどを当てていないか、変なデータを入れていないか。故障の情報は入っていないため、スイッチやルータの設定ミス等も疑ったことでしょう。そこからパケットキャプチャ等で犯人を特定して、シスコが犯人であることをシスコに認識させるために情報を整理して…ということを考えるとよく1日で交換部材を確保できたなーと感心します。
> 素人考えだと、スイッチを交換すれば
だれだよ、スイッチを強く叩いたのは！まあ、スイッチなんて安いもんだろうし、すぐ交換すればいいんじゃね？
# もっと素人はスイッチ＝赤黄青のボタンだと思ってる可能性
電話の交換機を叩かないでください。
＃by工事担任者持っている人。
どんな機械でも直せる、優れたエンジニアがいた。30年間忠実に会社に勤めた後、彼は無事引退した。数年後、数億円の機械がどうしても直せないと、会社から知らせを受けた。いろいろ試したが、彼らにはどうにも直せな いのであった。彼らは自暴自棄になって、過去に多くの問題を解決した、引退したエンジニアに連絡を取った。エンジニアは、しぶしぶ腰を上げたのであった。彼は、巨大な機械を一日かけて調べた。その日も終わろうかという頃、彼はある部品の上に小さな"x"マークをチョークで書いて、誇らしげに言った。「これが問題の個所だ」その部品は交換されて、また機械は完全に動くようになった。会社は、仕事代として5万ドルを彼から請求された。会社は、料金の明細を要求した。そのエンジニアは、ごく短い返答をよこした。チョークのマークひとつ $1それをどこに書くか知っていること $49,999料金は全額支払われ、エンジニアは再び幸せな引退生活に戻った。
どんな機械でも直せる、優れたエンジニアがいた。30年間忠実に会社に勤めた後、彼は無事引退した。数年後、数億円の機械がどうしても直せないと、会社から知らせを受けた。いろいろ試したが、彼らにはどうにも直せな いのであった。彼らは自暴自棄になって、過去に多くの問題を解決した、引退したエンジニアに連絡を取った。エンジニアは、しぶしぶ腰を上げたのであった。
彼は、巨大な機械を一日かけて調べた。その日も終わろうかという頃、彼はある部品の上に小さな"x"マークをチョークで書いて、誇らしげに言った。
「これが問題の個所だ」
その部品は交換されて、また機械は完全に動くようになった。会社は、仕事代として5万ドルを彼から請求された。会社は、料金の明細を要求した。そのエンジニアは、ごく短い返答をよこした。
チョークのマークひとつ $1それをどこに書くか知っていること $49,999
料金は全額支払われ、エンジニアは再び幸せな引退生活に戻った。
ていうコンピュータージョーク [vector.co.jp]を思い出した。
名探偵「犯人は、あなただ！」
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変それでもネットワークを二重化するとか対策はできそうだけど
いや、その2重化が仇になっている可能性も。発表されたページでは細かいことは分からないが、「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。（帯域も必要だし、fail safeも確保できる。）あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。（レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。）
ってのかなぁ。
pingは確実に通るけどtcp/udpは時々通らないという故障をしたスイッチがあってな。。それはもうはまりましたよ。実際に使用するプロトコルで「も」やった方が良いと思うんだ。
おまえは俺かよ！この件は今話題のC社のだったけど、シェアからするとまあ敢えて言うほどでもないかもしれん。
それってポートステータスにはエラーパケットとして出てなかったのかが気になる
効率は悪いけど、運用されている機能の上にウオッチドックを入れるしかないかな。ただそうすると規模が上がれば上がるほど、高層ビルのエレベーターみたいな問題が。
どういう壊れかたしたのかもう少し知りたいですよね。
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でも張るか（笑）
switchに問題があることがわかれば、あとは簡単。代替機に交換って、きっと問題のあったswitchを落とすだけじゃないかな。ふつうだったら自動的にfail overすべきところを、「不安定な状態で動作していた」ためにそれができなかったように見える。
switchでもrouterでもSANでもそういうによくやられてる。
現れるんじゃない?現れるからこそ、通信に影響が出るわけでしょう。
しかし、それに気づくことや、気づいてから原因を特定することは、口で言うほど簡単なことじゃない、って話でしょう。
よくありがちな通信不具合に関しては、「サーバ側で実装」されてますね。たとえば、TCPは、途中の経路でパケットがロスするという通信不具合に対して、それを回復するための再送と言う手段が実装されてますね。
今回の仕組みがTCPでカバーできるものだったのか、そもそもTCPを使っていたのかは、私は知りませんが、珍しい通信障害だったらしいので、それに対してサーバ側で準備しておけ、ってのは無理筋かな、と思います。
Ciscoのルーターで似たようなことは経験したことがありますが、何らかのエラーログは吐いていただろうし、トラフィックのグラフと合わせて追っていけば問題のあるＳＷを見つけるのはそれほど難しくないような気もします。あくまで日頃からログの管理をしていればですが。
kernelレベルのバグだと、ログを見ても、何も原因が出力されないことが多いかと思います。既に買収されたB社のL3スイッチでMACテーブルが不定期に破損するというバグにあたったことがありますが、問題が発生してもログには何も出ないし、コマンドからMACを確認しても、確認コマンドをトリガとして問題が解消されるのでコマンド結果からも異常が確認できない。
スイッチのブートコードをデバッグ用のコードに置き換えて、はじめて原因が分かったけど、そこに至るまでに相当時間がかかった。
基本的には同じ機種を同じ設定にして置き換えるはずだけど、バグだとまた同じこと起きそう。
#テスト環境で再現したという話もあるし
同じく素人ですが、そもそもスイッチが原因だとわかるまでにも時間がかかったんじゃないでしょうか。実際、故障時に信号を送ってくるはずのスイッチが送ってきてないわけで、一層特定がやっかいだったのかなと。
> 素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。> たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
そこで言っている「ハブ」はなにですか？
まあ、今売られている奴は、1000円切ってる奴でも、「スイッチングハブ」だからね。昔のリピータとしてのハブを知っている人はもうほとんどいない。
＃段数の制限とか懐かしい。
ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。
スイッチっていうと、インテリジェントな奴のことだとスルーするのが基本。
リピータにも「インテリジェントハブ」ってあったけどね。ま、私もリピータハブを（バカハブって呼んでたけど）
カタログとかではインテリジェント…コマンドラインインタフェイスを持つWebスイッチ…HTTPのインタフェイスとかになってて、Webスイッチも十分にインテリジェンスだと思う今日この頃。
>ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。懐かしいですね。同軸とか10BASE5とか。
(L2スイッチング)ハブだと思うけど、そんな細かいとこどーでもいい
大雑把に言いますと、人狼ゲームで、予言者（ＧＭ）が嘘ついてる状態です。原因特定には、かなり困難な状況です。
スイッチ(偽預言者): このアプリは狼です！今夜吊るしてください！
Catalyst 4948Eなので交換は簡単だと思いますが、中途半端に動いていたので予備機に切り替わらずスイッチが原因と思わなかったようですね。
こんなん突き止めるのは地獄だな
刑事ドラマにおける時間の配分
[事件発生][ 証拠の収集と犯人の特定 ][犯人逮捕]
システム障害における時間の配分
[障害発生][ 情報の収集と原因の特定 ][障害修正]
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
環境によってはハブも簡単じゃないぞ。カスケード接続してると、電源を入れ直さないと交換をした事を認識しないハブがいてつながらなくなったりするし。
＃全部電源再投入しても直らないなと思ったら、天井裏に一台残っていたのは今ではいい思い出。
> 素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。 更に素人考えですが、故障が起きる前にスイッチを交換すればもっと良かったと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
素人にわかるように、解決の難しさを教えて (スコア:0)
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
こういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことは
それほど難しいことなのでしょうか?
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
普通の障害解析って、ソフトウエアが複雑な所から疑っていくことが少なくない。そうなると、ネットワーク機器はかなり後になる。
私もスイッチが原因でのトラブルはあったけど、スイッチかぁ？ってなるまで結構時間がかかった経験がある。
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
確かにネットワーク周りって後回しになりがちですねぇ。
なんなんでしょうね、やっぱり物理的なシステムだと思ってしまうので、
堅牢性への妙な期待感があるんでしょうか。
電気が点かなくなったら、普通は、電球か蛍光灯かＬＥＤの寿命が来たと思うわけで、
停電とか、配電盤とかに思いが至るのは、その次になるかと。大元のインフラは、なんか
大丈夫と思っちゃうんでしょうね。
なお、真っ先に電気代の滞納とか、自分たち以外人類滅亡とかが頭をよぎるのは、
かなりの上級者ですので、ご注意ください。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
ああ、そういう行動パターンもあるんですね。
っていうか、どの放送局に電話かけるのかは気になります。
やっぱ、NHKなんでしょうか。そして流れるように受信契約へ。
だから映らないって言ってるのに〜、となるまでが、ワンセット。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
スイッチが壊れていると分かればあとは交換するだけですが、
「DBサーバが一台構成の場合は問題なく、複数台構成にすると問題が発生する」
という現象から故障箇所がスイッチであると特定するのには時間がかかりそうです。
実際に今回の場合もDBサーバ、アプリサーバそれぞれに問題が無いことを確認した後にスイッチの不具合を疑っていますから。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
今回であれば
・スイッチの不具合（ハード故障／ソフトウェア不具合）
・サーバのハード故障（NIC／マザーボード／メモリ／HDD）
・サーバのソフトウェア不具合（OS／ミドルウェア／その他のアプリ）
・ケーブル不良
・オペレーションミス
・電源供給不安定
みたいのが想定できます
実際にはもっとあるでしょうし要因が複数組み合わせの可能性もある
ある程度原因を絞るにしても特定作業はそれなりの時間がかかってしまうでしょうね
Re: (スコア:0)
そういうのって自動化できないんかな。
ネットワークなんだからあちこちでパケット監視すればできそうな気がするんだが。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
むしろよくあの短期間でスイッチバグだと絞り込めたな、と感心しているけれど。
まず最初にサーバ間のフェイルオーバーの仕組みの(サーバの中の)問題ではないかと、調査に時間をかけてしまうなぁ、自分なら。
よく特定したなぁ
Re: (スコア:0)
今回の件は監視している相手が嘘ついたという話ですので。
Re: (スコア:0)
そら一カ所しか見てないから見逃すんでは。
エンドツーエンドで監視すれば色々分かるような気がする。
Re: (スコア:0)
ここの経路が死にました！
→ケーブルかIFボードかスイッチかマザボかOSかアプリか
ってのは変わらない気が
Re: (スコア:0)
(サーバー側視点では)エンドツーエンドで監視してるから同期が取れてないのでフェイルオーバーするんですよ。
でも通信が完全に途切れてるわけじゃないのでどこが悪いのかよくわからんのです
Re: (スコア:0)
だからネットワーク内にいくつもノードを配置して通信状況を観測すれば自動的に故障箇所を特定できるんじゃ
Re: (スコア:0)
なにをもってどこの故障と判定するのかが難しいんだって
とはいえ、ノード網羅して通信状況見て判定する製品というのはEMC Smartsとかであるにはある。
Re: (スコア:0)
そんな「このゲームの敵はどうやって動かすんですか」「CPUに考えさせるんだよ」みたいな……
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
Aviation Wireの記事 [aviationwire.jp]の情報を見つつ…
・DBサーバが止まり、複数台動かすと不安定な状態になること
・1台で動かせば正常動作すること
これにより比較的早期に、1台での運用による仮復旧は出来たことでしょう。
ここから障害の切り分けに入ります。
状況的にまず最初にシステムのOSやソフトウェアが疑われたかもしれません。
夜間にパッチなどを当てていないか、変なデータを入れていないか。
故障の情報は入っていないため、スイッチやルータの設定ミス等も疑ったことでしょう。
そこからパケットキャプチャ等で犯人を特定して、シスコが犯人であることをシスコに認識させるために情報を整理して…
ということを考えるとよく1日で交換部材を確保できたなーと感心します。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
> 素人考えだと、スイッチを交換すれば
だれだよ、スイッチを強く叩いたのは！
まあ、スイッチなんて安いもんだろうし、すぐ交換すればいいんじゃね？
# もっと素人はスイッチ＝赤黄青のボタンだと思ってる可能性
Re: (スコア:0)
電話の交換機を叩かないでください。
＃by工事担任者持っている人。
Re:素人にわかるように、解決の難しさを教えて (スコア:1, 荒らし)
ていうコンピュータージョーク [vector.co.jp]を思い出した。
Re: (スコア: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:素人にわかるように、解決の難しさを教えて (スコア:1)
当時は「今時10Base2かよ」と思ったけど、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)
switchに問題があることがわかれば、あとは簡単。
代替機に交換って、きっと問題のあったswitchを落とすだけじゃないかな。
ふつうだったら自動的にfail overすべきところを、
「不安定な状態で動作していた」ためにそれができなかったように見える。
switchでもrouterでもSANでもそういうによくやられてる。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
現れるんじゃない?
現れるからこそ、通信に影響が出るわけでしょう。
しかし、それに気づくことや、気づいてから原因を特定することは、口で言うほど簡単なことじゃない、って話でしょう。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
よくありがちな通信不具合に関しては、「サーバ側で実装」されてますね。
たとえば、TCPは、途中の経路でパケットがロスするという通信不具合に対して、それを回復するための再送と言う手段が実装されてますね。
今回の仕組みがTCPでカバーできるものだったのか、そもそもTCPを使っていたのかは、私は知りませんが、珍しい通信障害だったらしいので、それに対してサーバ側で準備しておけ、ってのは無理筋かな、と思います。
Re: (スコア:0)
Ciscoのルーターで似たようなことは経験したことがありますが、何らかのエラーログは吐いていただろうし、
トラフィックのグラフと合わせて追っていけば問題のあるＳＷを見つけるのはそれほど難しくないような気もします。
あくまで日頃からログの管理をしていればですが。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
kernelレベルのバグだと、ログを見ても、何も原因が出力されないことが多いかと思います。
既に買収されたB社のL3スイッチでMACテーブルが不定期に破損するというバグにあたったことがありますが、問題が発生してもログには何も出ないし、コマンドからMACを確認しても、確認コマンドをトリガとして問題が解消されるのでコマンド結果からも異常が確認できない。
スイッチのブートコードをデバッグ用のコードに置き換えて、はじめて原因が分かったけど、そこに至るまでに相当時間がかかった。
Re: (スコア:0)
基本的には同じ機種を同じ設定にして置き換えるはずだけど、
バグだとまた同じこと起きそう。
#テスト環境で再現したという話もあるし
Re: (スコア:0)
同じく素人ですが、そもそもスイッチが原因だとわかるまでにも時間がかかったんじゃないでしょうか。
実際、故障時に信号を送ってくるはずのスイッチが送ってきてないわけで、一層特定がやっかいだったのかなと。
Re: (スコア:0)
> 素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
> たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
そこで言っている「ハブ」はなにですか？
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
まあ、今売られている奴は、1000円切ってる奴でも、「スイッチングハブ」だからね。
昔のリピータとしてのハブを知っている人はもうほとんどいない。
＃段数の制限とか懐かしい。
ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。
スイッチっていうと、インテリジェントな奴のことだとスルーするのが基本。
リピータにも「インテリジェントハブ」ってあったけどね。ま、私もリピータハブを（バカハブって呼んでたけど）
カタログとかでは
インテリジェント…コマンドラインインタフェイスを持つ
Webスイッチ…HTTPのインタフェイス
とかになってて、Webスイッチも十分にインテリジェンスだと思う今日この頃。
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
>ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。
懐かしいですね。
同軸とか10BASE5とか。
Re: (スコア:0)
(L2スイッチング)ハブだと思うけど、そんな細かいとこどーでもいい
Re: (スコア:0)
大雑把に言いますと、人狼ゲームで、予言者（ＧＭ）が嘘ついてる状態です。
原因特定には、かなり困難な状況です。
Re: (スコア:0)
スイッチ(偽預言者): このアプリは狼です！今夜吊るしてください！
Re: (スコア:0)
Catalyst 4948Eなので交換は簡単だと思いますが、中途半端に動いていたので予備機に切り替わらず
スイッチが原因と思わなかったようですね。
Re: (スコア:0)
こんなん突き止めるのは地獄だな
Re: (スコア:0)
刑事ドラマにおける時間の配分
システム障害における時間の配分
Re: (スコア:0)
環境によってはハブも簡単じゃないぞ。
カスケード接続してると、電源を入れ直さないと交換をした事を認識しないハブがいてつながらなくなったりするし。
＃全部電源再投入しても直らないなと思ったら、天井裏に一台残っていたのは今ではいい思い出。
Re: (スコア:0)
> 素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
更に素人考えですが、故障が起きる前にスイッチを交換すればもっと良かったと思います。