ANAのシステム障害について簡単に解説。4948Eが原因|雑録的ノートネットワークエンジニアのPONです。必要にかられて調査した内容のまとめや、ネットワークの技術的な話題、趣味の話など発信してきますメニューを開くホームHomeCISCOCISCOANAのシステム障害について簡単に解説。4948Eが原因2016/03/22に発生したANAの国内線システム障害について、原因が判明しました。http://itpro.nikkeibp.co.jp/atcl/news/16/033000936/?fbr同期処理が失敗した原因は、4台をつなぐスイッチの不具合。具体的には、スイッチが故障状態であるにもかからず、故障を知らせる「故障シグナル」を発信しなかった。「ネットワークの機能は使えないけど生死監視には応答し、故障と判断されない状態」は、一番厄介な障害の状態です。冗長化の仕組みを持たせても、このパターンの障害では「正系がダウンしたと検知され、副系に切り替わる」という動作が働かないため、まったく役に立たないですからね。ネットーワーク機器の冗長化の仕組み今回故障したCatalyst4948E(L3SW)は、複数台の機器を1台に仮想化するVSSはおろかスタックも組めない古い機器なのかな?そのため冗長化の設定として、VRRP(またはHSRP)を組んでいたと思われます。VRRP(HSRPもほぼ同等)VRRP/HSRPは同一LAN上の複数台のネットワーク機器を仮想的に1台に見せるプロトコルで、仮想のIPアドレスを設定し(MACアドレスは自動で設定される)、マスター機がダウンするとスタンバイ機が仮想のIPアドレスを自動で引き継ぎます。ダウン検知のため、VRRPを設定した機器同士がお互いパケットを常に送受信しています。サーバーのデフォルトゲートウェイの向き先を仮想IPアドレスとすることで、マスター機が障害でダウンした時もサーバーは設定を変えることなく通信を継続することができます。今回のANAのシステム障害では、Catalyst4948Eのマスター機が中途半端に生きていたので、スタンバイ機への切り替わりが発生せず、通信障害が起きたと推測します。スタックについて専用ケーブルでCatalyst同士を接続することで、スタック接続した機器を論理的に1台の機器として管理することができます。VRRPと異なり、運用管理が楽になる利点があります。コンフィグを編集する場合、スタック接続している機器なら1回の編集で完了する。VRRPで冗長化している場合は、それぞれの機器でコンフィグの編集が必要となる。構成がシンプルになるネットワーク構成は極力シンプルなのが望ましいのは言うまでもありません!STPとか考えなくて済みます。System)についてVSSはスタックのように専用ケーブルではなく光ケーブルを使い、お互いの機器を接続して論理的に1台の機器として管理出来るようになります。利点として物理的な距離の制限が緩和されます。(スタックケーブルは数m、VSSで利用する光ケーブルなら規格によっては40Km!)その他はスタックとだいたい同じ。監視システムで機器障害の検知できない傍から見ると正常動作しており、調査対象から外れる今回はDBサーバー・アプリケーションサーバーと異常がないか障害部位の切り分けを行い、ようやくCatalyst4948Eの障害を疑っています。このように明確な障害部位特定ができないと障害発生箇所から調査していくため、原因特定と復旧に時間がかかってしまいます。ネットワークとサーバー(インフラ)を構築運用しているのが別々の部署の場合、お互い構成を熟知してないため、解決により長くなる傾向があります。部署どころか、会社すら違う場合もふつうに有りますからね。イーサチャネルでネットワーク機器に接続。簡単なネットワーク図にするとこんな感じ。訴訟ANAのシステムを構築しているベンダーは日本ユニシスのようですhttp://itpro.nikkeibp.co.jp/atcl/news/16/033100944/?r_erm全日本空輸(ANA)は2016年3月31日、本誌の取材に対して3月22日に発生した国内旅客システムのシステム障害の件で、システムを納入した日本ユニシスへの損害賠償を検討していると明かした訴訟をおこなさないとANAが逆に株主から訴えられる可能性もあるため、訴訟までいくのかな?裁判になった場合、発生事例がないスイッチのバグで果たして障害を予測できるか?ベンダーの責任が問えるか?といろいろと気になる裁判になりそうです。傍から見ると現場の機器構成だと回避不能な障害では、と考えてしまいます。0:10拝見させて頂きました。スタックも組めないんですね。中途半端な死に方というのはどのような機械でも発生しうる。ネットワーク機器以外でも当然。そのことを色んなメディアが指摘しないのか、、、あまりにもレベルが低い。ちなみにシスコはこれを自身の機械のバグとは認めていない。この1台でハードウエア的な障害があった可能性はあるが、バグとは認めない。(認めてるというのであれば、Ciscoの誰がいつ、どういうコメントを出したのか見てみたい。)レイヤ2・3の世界の故障をもっと高レイヤで救えなかったというのだから、明らかにシステムそのもののつくりが悪いのだろう。Trapが飛ばなかったら救いようがないというのは、あまりにも初歩の初歩をわかっていないということ。ウォッチドッグタイマーすらも実装してなかったのか。ユニシスやANAのシステム担当者が責められるのが当然。ANAの担当者を褒めたてるコメントもよく見受けられるが、気色悪い。本人たちもわかっているだろう。技術者が頑張ったのは認めるが、そもそもシステムのつくりを見直した方が良い。12:305月4日書き込みの匿名さんに同感。「このアプリがシャットダウンを妨げています」。「ブート詳細オプション、最大メモリ」変更によるトラブル。書いてる人HN:PONまったりと生きているネットワークエンジニアです。