パスワードを忘れた? アカウント作成
12738590 story
ネットワーク

全日空のシステム障害、シスコ製スイッチの「初めて確認された」不具合が原因 128

ストーリー by hylom
どうしてこうなった 部門より
あるAnonymous Coward 曰く、

3月22日に全日空のシステムで障害が発生し、搭乗手続きなどが行えなくなるという問題が起きた。この原因が、Cisco Systemsのイーサネットスイッチの故障だったことが公表されている(日経ITpro)。

このシステムではスイッチの故障時にその旨を伝える信号が発信されるはずだったが、それが正しく機能しなかったために故障を検知できず、予備機への切り替えが行えなかったという。また、スイッチは完全に故障したわけではなく、不安定な状態で動作していたようだ。

問題が発生したスイッチは「Catalyst 4948E」で、今回のような不具合は初めて確認されたとのこと。代替機に交換したことでシステムを復旧できたという。なお、全日空では2013年2月にシステムの刷新を行っているが、それ以前の2007年にもCiscoのスイッチが原因による大規模なシステム障害が発生していた。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by ymasa (31598) on 2016年04月01日 16時20分 (#2990172) 日記

    http://www.aviationwire.jp/archives/85999 [aviationwire.jp]

    障害発生を受け、スイッチがシグナルを出さない状況でも、DBサーバーからスイッチの故障を検知できるよう、24日にシステムを改修。不具合が発生したスイッチは、製造したシスコが解析して故障箇所が判明したため、シスコが改善策を検討しているという。

  • by qpwoeiru (47171) on 2016年04月01日 19時06分 (#2990291) 日記

    シスコのせいなのに、CIOと取締役執行役員が減給になるんだ。

  • by the.ACount (31144) on 2016年04月02日 13時00分 (#2990650)

    ホントのニュ−スみたいだ!

    --
    the.ACount
  • by Anonymous Coward on 2016年04月01日 16時27分 (#2990177)

    素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。

    たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが
    こういった充分な資金力のある、大規模で信頼性が求められるシステムで

    長時間、停止してしまうことを防ぐことは
    それほど難しいことなのでしょうか?

    • 普通の障害解析って、ソフトウエアが複雑な所から疑っていくことが少なくない。そうなると、ネットワーク機器はかなり後になる。

      私もスイッチが原因でのトラブルはあったけど、スイッチかぁ?ってなるまで結構時間がかかった経験がある。

      親コメント
      • 確かにネットワーク周りって後回しになりがちですねぇ。

        なんなんでしょうね、やっぱり物理的なシステムだと思ってしまうので、
        堅牢性への妙な期待感があるんでしょうか。

        電気が点かなくなったら、普通は、電球か蛍光灯かLEDの寿命が来たと思うわけで、
        停電とか、配電盤とかに思いが至るのは、その次になるかと。大元のインフラは、なんか
        大丈夫と思っちゃうんでしょうね。

        なお、真っ先に電気代の滞納とか、自分たち以外人類滅亡とかが頭をよぎるのは、
        かなりの上級者ですので、ご注意ください。

        親コメント
    • by Anonymous Coward on 2016年04月01日 16時48分 (#2990194)

      スイッチが壊れていると分かればあとは交換するだけですが、
      「DBサーバが一台構成の場合は問題なく、複数台構成にすると問題が発生する」
      という現象から故障箇所がスイッチであると特定するのには時間がかかりそうです。
      実際に今回の場合もDBサーバ、アプリサーバそれぞれに問題が無いことを確認した後にスイッチの不具合を疑っていますから。

      親コメント
    • 障害の特定はあらゆる可能性を検討して潰していく必要があります
      今回であれば

      ・スイッチの不具合(ハード故障/ソフトウェア不具合)
      ・サーバのハード故障(NIC/マザーボード/メモリ/HDD)
      ・サーバのソフトウェア不具合(OS/ミドルウェア/その他のアプリ)
      ・ケーブル不良
      ・オペレーションミス
      ・電源供給不安定

      みたいのが想定できます
      実際にはもっとあるでしょうし要因が複数組み合わせの可能性もある

      ある程度原因を絞るにしても特定作業はそれなりの時間がかかってしまうでしょうね
      親コメント
    • by Anonymous Coward on 2016年04月01日 17時11分 (#2990222)

      Aviation Wireの記事 [aviationwire.jp]の情報を見つつ…
      ・DBサーバが止まり、複数台動かすと不安定な状態になること
      ・1台で動かせば正常動作すること
      これにより比較的早期に、1台での運用による仮復旧は出来たことでしょう。
      ここから障害の切り分けに入ります。
      状況的にまず最初にシステムのOSやソフトウェアが疑われたかもしれません。
      夜間にパッチなどを当てていないか、変なデータを入れていないか。
      故障の情報は入っていないため、スイッチやルータの設定ミス等も疑ったことでしょう。
      そこからパケットキャプチャ等で犯人を特定して、シスコが犯人であることをシスコに認識させるために情報を整理して…
      ということを考えるとよく1日で交換部材を確保できたなーと感心します。

      親コメント
    • > 素人考えだと、スイッチを交換すれば

      だれだよ、スイッチを強く叩いたのは!
      まあ、スイッチなんて安いもんだろうし、すぐ交換すればいいんじゃね?

      # もっと素人はスイッチ=赤黄青のボタンだと思ってる可能性

      親コメント
    • どんな機械でも直せる、優れたエンジニアがいた。30年間忠実に会社に勤めた後、彼は無事引退した。数年後、数億円の機械がどうしても直せないと、会社から知らせを受けた。いろいろ試したが、彼らにはどうにも直せな いのであった。彼らは自暴自棄になって、過去に多くの問題を解決した、引退したエンジニアに連絡を取った。エンジニアは、しぶしぶ腰を上げたのであった。

      彼は、巨大な機械を一日かけて調べた。その日も終わろうかという頃、彼はある部品の上に小さな"x"マークをチョークで書いて、誇らしげに言った。

      「これが問題の個所だ」

      その部品は交換されて、また機械は完全に動くようになった。会社は、仕事代として5万ドルを彼から請求された。会社は、料金の明細を要求した。そのエンジニアは、ごく短い返答をよこした。

      チョークのマークひとつ $1
      それをどこに書くか知っていること $49,999

      料金は全額支払われ、エンジニアは再び幸せな引退生活に戻った。

      ていうコンピュータージョーク [vector.co.jp]を思い出した。

      親コメント
    • by Anonymous Coward

      故障診断機能の不具合だから、スイッチの故障だとの判断に至るまでが大変
      それでもネットワークを二重化するとか対策はできそうだけど

      • by manmos (29892) on 2016年04月01日 17時03分 (#2990212) 日記

        いや、その2重化が仇になっている可能性も。
        発表されたページでは細かいことは分からないが、
        「スイッチが障害を起こしたが、その障害を起こしたという信号が出なかった」
        「DBサーバ間で整合が合わなくなった」と書かれている。

        当然DBサーバはリンクアグリゲーションで接続されているであろう事は容易に推測できる。(帯域も必要だし、fail safeも確保できる。)あと、DBサーバ同士の接続は、他のパケットが流れない専用のリンク。

        で、ここからは私の妄想。

        だた、スイッチが障害を起こしたが、リンクアグリゲーションの一部だけの障害で、その検知が出来なかったら、サーバは全部の接続にパケットを流そうとするが、当然ストリームの整合性はまったくなくなるわけで、リプリケーションのエラーが続発する。

        これを解消するとなると、 DB同士pingを流しあってある閾値を越えてロスると傷害と判断する。(レプリケーションの監視の多くは、pingが通りさえすればOKってのもあったりする。)

        ってのかなぁ。

        親コメント
        • by Anonymous Coward on 2016年04月01日 17時52分 (#2990246)

          pingは確実に通るけどtcp/udpは時々通らないという故障をしたスイッチがあってな。。
          それはもうはまりましたよ。
          実際に使用するプロトコルで「も」やった方が良いと思うんだ。

          親コメント
        • 以前MC/ServiceGuard(HP9000サーバーのクラスタソフトウェア)の勉強をした時、システム構成例でハートビートLANは10Base2で構成されていた。
          当時は「今時10Base2かよ」と思ったけど、HUBの故障を考えなくていいので、間違ってなかったのかもしれない。
          親コメント
        • どういう壊れかたしたのかもう少し知りたいですよね。

          LAG組んでたらLACPで凡その障害は検知できますし
          auto negoにしておけばL1障害も結構検出可能。
          BFD入れておけばIPレベルの死活もばっちり。

          ほんとにちゃんと設計されてたんだろうかと気になります。
          DB同期ラインし適当でいいやってただデフォルト設定で突っ込んでたりして・・・。

          親コメント
          • by Anonymous Coward on 2016年04月03日 10時49分 (#2991111)

            >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でも張るか(笑)

              親コメント
    • by Anonymous Coward

      switchに問題があることがわかれば、あとは簡単。
      代替機に交換って、きっと問題のあったswitchを落とすだけじゃないかな。
      ふつうだったら自動的にfail overすべきところを、
      「不安定な状態で動作していた」ためにそれができなかったように見える。

      switchでもrouterでもSANでもそういうによくやられてる。

      • 不安定なだけってのはパケットなりに現れない現象なんでしょうかね。
        親コメント
      • by Anonymous Coward

        Ciscoのルーターで似たようなことは経験したことがありますが、何らかのエラーログは吐いていただろうし、
        トラフィックのグラフと合わせて追っていけば問題のあるSWを見つけるのはそれほど難しくないような気もします。
        あくまで日頃からログの管理をしていればですが。

        • by Anonymous Coward on 2016年04月01日 18時07分 (#2990257)

          kernelレベルのバグだと、ログを見ても、何も原因が出力されないことが多いかと思います。
          既に買収されたB社のL3スイッチでMACテーブルが不定期に破損するというバグにあたったことがありますが、問題が発生してもログには何も出ないし、コマンドからMACを確認しても、確認コマンドをトリガとして問題が解消されるのでコマンド結果からも異常が確認できない。

          スイッチのブートコードをデバッグ用のコードに置き換えて、はじめて原因が分かったけど、そこに至るまでに相当時間がかかった。

          親コメント
    • by Anonymous Coward

      同じく素人ですが、そもそもスイッチが原因だとわかるまでにも時間がかかったんじゃないでしょうか。
      実際、故障時に信号を送ってくるはずのスイッチが送ってきてないわけで、一層特定がやっかいだったのかなと。

    • by Anonymous Coward

      > 素人考えだと、スイッチを交換すればすぐ回復できそうなように思えます。
      > たぶん、ハブほど簡単に交換できるものじゃないのだろうとは思いますが

      そこで言っている「ハブ」はなにですか?

      • まあ、今売られている奴は、1000円切ってる奴でも、「スイッチングハブ」だからね。
        昔のリピータとしてのハブを知っている人はもうほとんどいない。

        #段数の制限とか懐かしい。

        ま、「イエローケーブルにバンパイヤ立ててた」って、単語レベルで意味不明ですね。

        スイッチっていうと、インテリジェントな奴のことだとスルーするのが基本。

        リピータにも「インテリジェントハブ」ってあったけどね。ま、私もリピータハブを(バカハブって呼んでたけど)

        カタログとかでは
        インテリジェント…コマンドラインインタフェイスを持つ
        Webスイッチ…HTTPのインタフェイス
        とかになってて、Webスイッチも十分にインテリジェンスだと思う今日この頃。

        親コメント
      • by Anonymous Coward

        (L2スイッチング)ハブだと思うけど、そんな細かいとこどーでもいい

    • by Anonymous Coward

      大雑把に言いますと、人狼ゲームで、予言者(GM)が嘘ついてる状態です。
      原因特定には、かなり困難な状況です。

      • by Anonymous Coward

        スイッチ(偽預言者): このアプリは狼です!今夜吊るしてください!

    • by Anonymous Coward

      Catalyst 4948Eなので交換は簡単だと思いますが、中途半端に動いていたので予備機に切り替わらず
      スイッチが原因と思わなかったようですね。

    • by Anonymous Coward

      刑事ドラマにおける時間の配分

      [事件発生][          証拠の収集と犯人の特定          ][犯人逮捕]

      システム障害における時間の配分

      [障害発生][          情報の収集と原因の特定          ][障害修正]

  • by Anonymous Coward on 2016年04月01日 16時52分 (#2990196)

    なんて、俺もよく出してますよ

    • ですよね。間違っちゃいないけど、なんか変な表現。

      親コメント
      • 世界中で広く使われている製品で、「初めて確認された」不具合、という表現がおかしいとは思わないんだけど、どこが変?

        俺様が昨晩やっつけ仕事ででっち上げたスクリプトで、「初めて確認された」不具合、だったら変かもね。

        親コメント
        • 不具合には既知の不具合か初めて確認された不具合しかないわけで、今回のように大きな障害になるのは既知の不具合ではなさそうだ、と感じていました。
          なので、「初めて確認された」とわざわざ括弧書きでタイトルに付いているのを見て、そりゃそうなんじゃないの、そこに特筆すべき点があるの?と感じたわけです。
          あるいは単に私が仕事柄なにかの不具合を初めて確認するのに慣れすぎてしまったせいで、不具合報告に「初めて確認された」とつく事に違和感を覚えてしまっただけかも。

          親コメント
          • 不具合には既知の不具合か初めて確認された不具合しかないわけで、今回のように大きな障害になるのは既知の不具合ではなさそうだ、と感じていました。

            なるほどね。
            解らなくはないです。

            が、何らかの不具合が発見されて、それが公知になるまで、というのには結構な時間差があることが普通です。
            私としては、「初めて確認された」と「既知」の間に、公知ではないが既知、とか、他に報告されていたものと同じものだと確認された類例の少ない、とかがあると認識しています。
            なので、「初めて確認された」も特に違和感はないですね。

            親コメント
  • by Anonymous Coward on 2016年04月01日 16時52分 (#2990199)

    あんまり聞かないような気がするんですけど。それは、他に受け皿が無いからなんですかね?

    脆弱性を問題にされ、非難されやすい物と、そうなりにくい物があるような気がします。

  • by Anonymous Coward on 2016年04月01日 17時03分 (#2990211)

    「ああ、宇宙線のせいですね」

typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...