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回の編集で完了する。
- 構成がシンプルになる
STPとか考えなくて済みます。
VSS（Virtual Switching System）について
VSSはスタックのように専用ケーブルではなく光ケーブルを使い、お互いの機器を接続して論理的に1台の機器として管理出来るようになります。
利点として物理的な距離の制限が緩和されます。
（スタックケーブルは数m、VSSで利用する光ケーブルなら規格によっては40Km！）
その他はスタックとだいたい同じ。
(スポンサーリンク)
復旧に時間が掛かる原因
- 監視システムで機器障害の検知できない
- 傍から見ると正常動作しており、調査対象から外れる
今回はDBサーバー・アプリケーションサーバーと異常がないか障害部位の切り分けを行い、ようやくCatalyst4948Eの障害を疑っています。
このように明確な障害部位特定ができないと障害発生箇所から調査していくため、原因特定と復旧に時間がかかってしまいます。
またネットワークとサーバー（インフラ）を構築運用しているのが別々の部署の場合、お互い構成を熟知してないため、解決により長くなる傾向があります。
部署どころか、会社すら違う場合もふつうに有りますからね。
障害回避するための構成
ネットワーク機器側 VSSまたはスタックを組み、仮想的に1台のネットワーク機器として構築
サーバー側 イーサチャネルでネットワーク機器に接続。
簡単なネットワーク図にするとこんな感じ。
スタックかVSSなら片系が中途半端に生きていても・・・通信が継続できるのではないでしょうか。
多分。
損害賠償の訴訟
ANAのシステムを構築しているベンダーは日本ユニシスのようです
http://itpro.nikkeibp.co.jp/atcl/news/16/033100944/?r_erm
全日本空輸（ANA）は2016年3月31日、本誌の取材に対して3月22日に発生した国内旅客システムのシステム障害の件で、システムを納入した日本ユニシスへの損害賠償を検討していると明かした
訴訟をおこなさないとANAが逆に株主から訴えられる可能性もあるため、訴訟までいくのかな？
裁判になった場合、発生事例がないスイッチのバグで果たして障害を予測できるか？ベンダーの責任が問えるか？といろいろと気になる裁判になりそうです。
傍から見ると現場の機器構成だと回避不能な障害では、と考えてしまいます。
拝見させて頂きました。スタックも組めないんですね。しかしHSRPのバグだとしたら、今更過ぎて泣けますね。
返信削除枯れているはずの機器でも油断できない事例ですよね
返信削除今更ながら・・・
返信削除中途半端な死に方というのはどのような機械でも発生しうる。ネットワーク機器以外でも当然。
なぜそのことを色んなメディアが指摘しないのか、、、あまりにもレベルが低い。
ちなみにシスコはこれを自身の機械のバグとは認めていない。たまたまこの１台でハードウエア的な障害があった可能性はあるが、バグとは認めない。当然だろう。
（認めてるというのであれば、Ciscoの誰がいつ、どういうコメントを出したのか見てみたい。。）
レイヤ２・３の世界の故障をもっと高レイヤで救えなかったというのだから、明らかにシステムそのもののつくりが悪いのだろう。SNMP Trapが飛ばなかったら救いようがないというのは、あまりにも初歩の初歩をわかっていないということ。ウォッチドッグタイマーすらも実装してなかったのか。
ユニシスやANAのシステム担当者が責められるのが当然。ANAの担当者を褒めたてるコメントもよく見受けられるが、気色悪い。本人たちもわかっているだろう。
技術者が頑張ったのは認めるが、そもそもシステムのつくりを見直した方が良い。
メーカーのせいにして安心してると、今後も同じ不具合を起こすことは目に見えている。
5月4日書き込みの匿名さんに同感。サーバ／ネットワークエンジニアが当然考慮すべき設計ポイント。
返信削除