PR

山田 英史氏 ディアイティ 技術部長
森 勝氏 サイバーソリューション ソリューション推進室

障害を早期に発見するには,ネットワーク機器を平常時から監視しておくことが欠かせない。早く検知できるだけでなく,時々しか発生せず再現が難しい障害の原因追及も可能になる。ただし,pingによる接続性確認だけでは不十分。応答時間などの監視と組み合わせる必要がある。

 ネットワークの障害には,時々しか発生せず,対策を打つ前に自然に回復してしまうものがある。障害を再現できないため,パケット・アナライザによる原因調査は不可能。このようなケースに威力を発揮するのが,pingSNMPを使ったネットワーク機器の常時監視である。

 最も簡易なのはpingで接続性を確認する方法だが,これだけでは不十分。応答時間やSNMPを使ったトラフィックの状態監視などと組み合わせなければ,障害の原因を突き止められないことが多い。

pingだけでは原因分からず
ルーターの応答監視で解決

図1 部品メーカーのA社は当初pingで監視したが障害を検知できなかった
本社のエンドユーザーが神戸工場の生産管理サーバーにアクセスする際に,サーバーからの返答が全くない現象が時々発生していた。再度発生した時に即座に対応するため,サーバーに対して定期的にpingを送って監視することにした。しかし,pingの反応は正常であるにもかかわらず,再びサーバーからの返答が全くない現象が発生,ユーザーからクレームが入った。
常時監視の手法として最も基本的なのが,pingを使った接続性の確認。pingの返答がなくなると障害として検知する。しかし,サーバーなどのレスポンスが極端に悪化する障害は,接続性の確認だけでは検知できない。複数の機器に対する応答時間の監視が不可欠だ。

 大阪に本社を持つ部品メーカーのA社は半年前,生産管理サーバーを本社から神戸工場に移設した。本社のエンドユーザーは,エコノミー専用線を介して,工場の生産管理サーバーにアクセスするという運用方法である。

 運用を開始して3カ月,本社のユーザーから生産管理サーバーにアクセスできないと電話が入った。サーバーの稼働状態を調べたが,異常なかった。

 ただ,生産管理サーバーの通信ログには,TCPのコネクションが切断された形跡が残っていた。生産管理のアプリケーションは,いったんコネクションが切れると,アプリケーションを再起動してネットワークに再接続しない限り止まったまま。この段階では再起動でその場をしのいだ。

ping応答は正常なのに通信不能に

 A社は,同じ障害の再発に備え,生産管理サーバーに対してpingを送り続けることにした。サーバーへの接続性を常時監視し,障害時にユーザーからクレームが入る前に,システム部で再起動処理しようと考えたのである。

 具体的には,pingを10分ごとに4回送出し,返答がない場合,再度2分後に4回送出。それでも返答がない場合に,エラーとして管理者にメールを通知するという仕組みを作った(図1[拡大表示])。こうしたpingによる常時監視状態を始めて1週間後,再びエンドユーザーから同じクレームが来た。

 しかし,警告メールは届いていない。サーバーは,pingには正常に応答していたからだった。サーバーのログを調べると,今回もTCPのコネクションが切れていた。原因不明のままだったが,とりあえずすぐにアプリケーションを再起動した。