ANAシステム障害について (Catalyst 4948E)
記事には詳しく書かれておりませんが、サーバーが原因ではなく、Cisco Systems社のCatalyst 4948Eというネットワーク機器(スイッチ)のバグが原因と発表されております。
(写真)Cisco Systems社製 Catalyst 4948E
このバグの内容は、故障しても故障パケットを飛ばさないというバグで、サーバー間通信がうまくいかないことによって、サーバーが誤動作を起こしシステムがダウンしました。
ANAが公表している「国内旅客システム」の概要図
具体的には、4台のDBサーバつなげているスイッチがパケットを流さなくなった。つまり、スイッチとしての機能を果たさなくなった。スイッチもモノであるのでいつかは壊れる。そのときは図にもあるように予備機があり、メインで使っていたスイッチが故障した場合はこの予備機が使われる。
しかし今回は、この予備機が使われることはなかった。
予備機が使われるきっかけ（トリガー）になるのは、SNMP Trapだったらしい。このTrapがスイッチから上がらなかった。だから予備機に切り替わることなくサーバの同期がされなった。
さらに悪いことに、サーバは相互にデータを同期しているが、同期が取れなくなると各サーバのデータ内容に食い違いが発生してしまうため、各サーバと同期が取れないサーバはシャットダウンする仕様になっていた。
これらを踏まえ、4台のDBサーバが順次シャットダウンし、システムが止まってしまった。
ここからは私の意見だが、スイッチの切り替えトリガーがTrapというのがお粗末である。
通常は疎通が取れない時点で自動で切り替える設定にする。なぜなら、そもそもスイッチがTrapを出すのは、スイッチが稼働しているからできることであって、故障しているのであればTrapを出すことができない。
スイッチの不具合を検知するのであれば、別のNWで死活監視やポーリングする他ないのではないか。
それと、DBサーバの同期が取れないとシャットダウンする仕様は理解できるが、最後の1台は残しておく仕様でもよかったのでは？と思う。
それにサーバにもbackupポート機能があるはずだから、定期的に同期先のサーバとの疎通確認を行い、NGだったらbackupポートを使うという設計にもできたはずだ。(まぁ、同期といってもUDPパケットしか投げてないのかもしれないから、ベット疎通確認用のicmpパケット投げるので、負荷は高くなると思うが。)
それにしても、この運用さんの対応力には感服する。30分足らずで一部サービスを再開、150分後には搭乗手続きサービスを復旧と原因が判明してない中で、ここまで対応が取れるのはすごい。障害に対する対策がとられていたからこそできた所業だと思う。この点は称賛に値するとおもう。
この障害でネットワークエンジニアさんたちは、お客様から聞かれると思いますが、この記事でお役に立てればと思います。
※Cisco Bug Searchを調べましたが・・・。
以上、chocoでした。
