全日空のシステム障害、シスコ製スイッチの「初めて確認された」不具合が原因 128
ストーリー by hylom
どうしてこうなった 部門より
どうしてこうなった 部門より
あるAnonymous Coward 曰く、
3月22日に全日空のシステムで障害が発生し、搭乗手続きなどが行えなくなるという問題が起きた。この原因が、Cisco Systemsのイーサネットスイッチの故障だったことが公表されている(日経ITpro)。
このシステムではスイッチの故障時にその旨を伝える信号が発信されるはずだったが、それが正しく機能しなかったために故障を検知できず、予備機への切り替えが行えなかったという。また、スイッチは完全に故障したわけではなく、不安定な状態で動作していたようだ。
問題が発生したスイッチは「Catalyst 4948E」で、今回のような不具合は初めて確認されたとのこと。代替機に交換したことでシステムを復旧できたという。なお、全日空では2013年2月にシステムの刷新を行っているが、それ以前の2007年にもCiscoのスイッチが原因による大規模なシステム障害が発生していた。
改善策を検討 (スコア:2)
http://www.aviationwire.jp/archives/85999 [aviationwire.jp]
障害発生を受け、スイッチがシグナルを出さない状況でも、DBサーバーからスイッチの故障を検知できるよう、24日にシステムを改修。不具合が発生したスイッチは、製造したシスコが解析して故障箇所が判明したため、シスコが改善策を検討しているという。
減給 (スコア:2)
シスコのせいなのに、CIOと取締役執行役員が減給になるんだ。
Re:減給 (スコア:1)
「Chief Information Strategic Consolidation Officerが原因でした」
-- う~ん、バッドノウハウ?
スゴイ (スコア:1)
ホントのニュ−スみたいだ!
the.ACount
素人にわかるように、解決の難しさを教えて (スコア:0)
素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
こういった充分な資金力のある、大規模で信頼性が求められるシステムで
長時間、停止してしまうことを防ぐことは
それほど難しいことなのでしょうか?
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
普通の障害解析って、ソフトウエアが複雑な所から疑っていくことが少なくない。そうなると、ネットワーク機器はかなり後になる。
私もスイッチが原因でのトラブルはあったけど、スイッチかぁ?ってなるまで結構時間がかかった経験がある。
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
確かにネットワーク周りって後回しになりがちですねぇ。
なんなんでしょうね、やっぱり物理的なシステムだと思ってしまうので、
堅牢性への妙な期待感があるんでしょうか。
電気が点かなくなったら、普通は、電球か蛍光灯かLEDの寿命が来たと思うわけで、
停電とか、配電盤とかに思いが至るのは、その次になるかと。大元のインフラは、なんか
大丈夫と思っちゃうんでしょうね。
なお、真っ先に電気代の滞納とか、自分たち以外人類滅亡とかが頭をよぎるのは、
かなりの上級者ですので、ご注意ください。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
ああ、そういう行動パターンもあるんですね。
っていうか、どの放送局に電話かけるのかは気になります。
やっぱ、NHKなんでしょうか。そして流れるように受信契約へ。
だから映らないって言ってるのに〜、となるまでが、ワンセット。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
スイッチが壊れていると分かればあとは交換するだけですが、
「DBサーバが一台構成の場合は問題なく、複数台構成にすると問題が発生する」
という現象から故障箇所がスイッチであると特定するのには時間がかかりそうです。
実際に今回の場合もDBサーバ、アプリサーバそれぞれに問題が無いことを確認した後にスイッチの不具合を疑っていますから。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
今回であれば
・スイッチの不具合(ハード故障/ソフトウェア不具合)
・サーバのハード故障(NIC/マザーボード/メモリ/HDD)
・サーバのソフトウェア不具合(OS/ミドルウェア/その他のアプリ)
・ケーブル不良
・オペレーションミス
・電源供給不安定
みたいのが想定できます
実際にはもっとあるでしょうし要因が複数組み合わせの可能性もある
ある程度原因を絞るにしても特定作業はそれなりの時間がかかってしまうでしょうね
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
むしろよくあの短期間でスイッチバグだと絞り込めたな、と感心しているけれど。
まず最初にサーバ間のフェイルオーバーの仕組みの(サーバの中の)問題ではないかと、調査に時間をかけてしまうなぁ、自分なら。
よく特定したなぁ
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
Aviation Wireの記事 [aviationwire.jp]の情報を見つつ…
・DBサーバが止まり、複数台動かすと不安定な状態になること
・1台で動かせば正常動作すること
これにより比較的早期に、1台での運用による仮復旧は出来たことでしょう。
ここから障害の切り分けに入ります。
状況的にまず最初にシステムのOSやソフトウェアが疑われたかもしれません。
夜間にパッチなどを当てていないか、変なデータを入れていないか。
故障の情報は入っていないため、スイッチやルータの設定ミス等も疑ったことでしょう。
そこからパケットキャプチャ等で犯人を特定して、シスコが犯人であることをシスコに認識させるために情報を整理して…
ということを考えるとよく1日で交換部材を確保できたなーと感心します。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
> 素人考えだと、スイッチを交換すれば
だれだよ、スイッチを強く叩いたのは!
まあ、スイッチなんて安いもんだろうし、すぐ交換すればいいんじゃね?
# もっと素人はスイッチ=赤黄青のボタンだと思ってる可能性
Re:素人にわかるように、解決の難しさを教えて (スコア:1, 荒らし)
ていうコンピュータージョーク [vector.co.jp]を思い出した。
Re: (スコア:0)
故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変
それでもネットワークを二重化するとか対策はできそうだけど
Re:素人にわかるように、解決の難しさを教えて (スコア:5, すばらしい洞察)
いや、その2重化が仇になっている可能性も。
発表されたページでは細かいことは分からないが、
「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」
「DBサーバ間で整合が合わなくなった」と書かれている。
当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。
で、ここからは私の妄想。
だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。
これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)
ってのかなぁ。
Re:素人にわかるように、解決の難しさを教えて (スコア:2, 参考になる)
pingは確実に通るけどtcp/udpは時々通らないという故障をしたスイッチがあってな。。
それはもうはまりましたよ。
実際に使用するプロトコルで「も」やった方が良いと思うんだ。
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のルーターで似たようなことは経験したことがありますが、何らかのエラーログは吐いていただろうし、
トラフィックのグラフと合わせて追っていけば問題のあるSWを見つけるのはそれほど難しくないような気もします。
あくまで日頃からログの管理をしていればですが。
Re:素人にわかるように、解決の難しさを教えて (スコア:1)
kernelレベルのバグだと、ログを見ても、何も原因が出力されないことが多いかと思います。
既に買収されたB社のL3スイッチでMACテーブルが不定期に破損するというバグにあたったことがありますが、問題が発生してもログには何も出ないし、コマンドからMACを確認しても、確認コマンドをトリガとして問題が解消されるのでコマンド結果からも異常が確認できない。
スイッチのブートコードをデバッグ用のコードに置き換えて、はじめて原因が分かったけど、そこに至るまでに相当時間がかかった。
Re: (スコア:0)
同じく素人ですが、そもそもスイッチが原因だとわかるまでにも時間がかかったんじゃないでしょうか。
実際、故障時に信号を送ってくるはずのスイッチが送ってきてないわけで、一層特定がやっかいだったのかなと。
Re: (スコア:0)
> 素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
> たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
そこで言っている「ハブ」はなにですか?
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
まあ、今売られている奴は、1000円切ってる奴でも、「スイッチングハブ」だからね。
昔のリピータとしてのハブを知っている人はもうほとんどいない。
#段数の制限とか懐かしい。
ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。
スイッチっていうと、インテリジェントな奴のことだとスルーするのが基本。
リピータにも「インテリジェントハブ」ってあったけどね。ま、私もリピータハブを(バカハブって呼んでたけど)
カタログとかでは
インテリジェント…コマンドラインインタフェイスを持つ
Webスイッチ…HTTPのインタフェイス
とかになってて、Webスイッチも十分にインテリジェンスだと思う今日この頃。
Re:素人にわかるように、解決の難しさを教えて (スコア:2)
>ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。
懐かしいですね。
同軸とか10BASE5とか。
Re: (スコア:0)
(L2スイッチング)ハブだと思うけど、そんな細かいとこどーでもいい
Re: (スコア:0)
大雑把に言いますと、人狼ゲームで、予言者(GM)が嘘ついてる状態です。
原因特定には、かなり困難な状況です。
Re: (スコア:0)
スイッチ(偽預言者): このアプリは狼です!今夜吊るしてください!
Re: (スコア:0)
Catalyst 4948Eなので交換は簡単だと思いますが、中途半端に動いていたので予備機に切り替わらず
スイッチが原因と思わなかったようですね。
Re: (スコア:0)
刑事ドラマにおける時間の配分
システム障害における時間の配分
「初めて確認された」不具合 (スコア:0)
なんて、俺もよく出してますよ
Re:「初めて確認された」不具合 (スコア:1)
ですよね。間違っちゃいないけど、なんか変な表現。
Re:「初めて確認された」不具合 (スコア:1)
世界中で広く使われている製品で、「初めて確認された」不具合、という表現がおかしいとは思わないんだけど、どこが変?
俺様が昨晩やっつけ仕事ででっち上げたスクリプトで、「初めて確認された」不具合、だったら変かもね。
Re:「初めて確認された」不具合 (スコア:1)
不具合には既知の不具合か初めて確認された不具合しかないわけで、今回のように大きな障害になるのは既知の不具合ではなさそうだ、と感じていました。
なので、「初めて確認された」とわざわざ括弧書きでタイトルに付いているのを見て、そりゃそうなんじゃないの、そこに特筆すべき点があるの?と感じたわけです。
あるいは単に私が仕事柄なにかの不具合を初めて確認するのに慣れすぎてしまったせいで、不具合報告に「初めて確認された」とつく事に違和感を覚えてしまっただけかも。
Re:「初めて確認された」不具合 (スコア:1)
不具合には既知の不具合か初めて確認された不具合しかないわけで、今回のように大きな障害になるのは既知の不具合ではなさそうだ、と感じていました。
なるほどね。
解らなくはないです。
が、何らかの不具合が発見されて、それが公知になるまで、というのには結構な時間差があることが普通です。
私としては、「初めて確認された」と「既知」の間に、公知ではないが既知、とか、他に報告されていたものと同じものだと確認された類例の少ない、とかがあると認識しています。
なので、「初めて確認された」も特に違和感はないですね。
「Ciscoからリプレイスするべき」的な意見 (スコア:0)
あんまり聞かないような気がするんですけど。それは、他に受け皿が無いからなんですかね?
脆弱性を問題にされ、非難されやすい物と、そうなりにくい物があるような気がします。
Re:「Ciscoからリプレイスするべき」的な意見 (スコア:1)
Cisco以外を入れたら、トラブったときの苦情が増えるもん。今回の件だって、「Ciscoならしょうがない」もしくは「Ciscoでもトラブるんなら仕方ない」のどちらかで納得してる人は結構いるんじゃないかな。
Re:「Ciscoからリプレイスするべき」的な意見 (スコア:1)
イザとなったらこう言ってごまかす (スコア:0)
「ああ、宇宙線のせいですね」
Re:イザとなったらこう言ってごまかす (スコア:1)
「宇宙船が着陸してたんですか!?」
Re: (スコア:0)
「で、掃除のおばちゃんはどこですか?」
Re:ハードの耐用年数はわからない? (スコア:1)
大体、ネットワーク機器の不具合ってのは、ハードウェアよりもソフトウェアが原因のことが多いんじゃないかな。
なので、新しければ不具合を起こしにくい、ってことはなくて、新しいほど(初出荷から時をおかなほど)不具合を起こしやすい、ってこともあるんじゃないかな。
Re:数年前だが (スコア:2, 参考になる)
どういう会話の流れだったかわからんけど、
前工程の仕様書からテスト項目おこしてから設計書を書くという手法はあるんだが……