メールを読もうとしたところ「POPサーバが応答しない」という意味のエラーが表示されてしまいました。それも1部署の1クライアントだけでなく、かなりの数のクライアントにトラブルが発生しているようです。どうすればいいでしょうか?
昨日まで何の問題もなく使えていたメールソフトが、朝からエラーを表示するだけで使えない(画面1)。
 |
|---|
| 画面1 POPサーバ無応答のエラー(Outlook Expressの場合) |
しかも、障害は1台のクライアントだけでなく、ほかのユーザーも同様のトラブルが起きているらしい。メールが昨今のビジネスで必要不可欠なインフラとなっている以上、この手のトラブルは実際の業務にも多大な影響を与える。よって、ともかく一刻も早く解決しなければならない緊急事態だ。 このような1台のクライアントや1部署だけにとどまらないケースで1番最初に疑うべきは、すべての大元となるサービスを提供しているマシンである。この場合は、メールサーバ自体に異常が発生しているかもしれないという考え方になる。なぜなら、1台のクライアントや1台のハブに繋がっているグループだけの異常であれば、原因はその中だけに特化したサービスやネットワーク機器にあると考えられるからだ。このように、トラブルが発生した際は、まず「どこでトラブルが発生しているか」を見極めることが重要になる。すべてのトラブルシューティングは、ここから始まる。
ここでトラブル発生の範囲が特定できたら、次にそこから導き出される原因を探るためにトラブルの症状を確認する。今回の場合、画面1のような「POP(メール)サーバが応答しない」といった意味のエラーが出ている。これは、メールサーバとクライアントの間で通信ができなかったということを意味するので、クライアントがメールサーバにアクセスして自分のメールを取り出すときに利用するメールサーバに何らかの原因がある可能性が高まる(図1)。
 |
|---|
| 図1 メールサーバの役割 |
もちろん、メールサーバにはまったく異常がないのに、途中のネットワークに何らかのトラブルが発生していることにより通信ができなくなっているという可能性も充分に考えられる。さらに最悪のケースとして、メールサーバにも異常が発生し、なおかつネットワークにも別のトラブルが起きているといった二重障害とでもいうようなことも実際に見られるケースである。ただしネットワークのトラブルについては、次の項目で説明するので、ここではメールサーバなどといった、特定のハードウェア(サービス)にトラブルが発生した際の解決手順を見ていこう。
メールサーバをチェックしてみる
まずは、メールサーバが正常に稼動しているかを確認しておこう。まずは50ページでも解説したpingコマンドでサーバがダウンしていないかを確認する。また、稼働していたとしても大量の負荷がかかっている場合もあるので、telnetなどでログインしてuptimeコマンド(UNIX系OSのみ)でサーバの負荷を確認するのもよいだろう。サービスを動かしているサーバがダウンしているかどうかを確認するには、まずこの2つのコマンドを利用するとよい。これらのコマンドでメールサーバに何らかの異常が確認できたら、ともかく再稼動させるための処置を緊急にとらなければならない。ただし一口にメールサーバの復旧といっても、ネットワークの規模や組織の事情により、ハードウェアも異なれば、OSや使用しているメールサーバのソフトウェアも違っているはずだ。ここではまず、汎用的なトラブルの4大パターンを修復が困難な順に示しておく。
(1)ハードウェア障害
メールサーバのハードウェアがまったく動かないという最悪の状態だ。最近ではこのケースはほとんどまれであろう。しかし100％起きないという保証はないので、保守契約や代替品のストックなどの管理はしておかなければならない。また最近の大規模なネットワーク環境では、ハードウェアを冗長構成にするなどの工夫もとられているはずだ。
(2)トラフィックの急増による異常
ユーザーのアクセスが集中した、あるいはメールの処理がサーバ設置時に想定していたものよりはるかに多くなり、結果的にサーバが異常を起こしているように見えるケース。実際にはハードウェアやソフトウェアの異常がないだけに、対処が難しいケースがこれだ。この場合は抜本的な対策が必要となる。たとえばメールサーバを複数に分ける、ハードウェアの増強をはかる、といった処置を行なう。
ただし最近では、メールを利用してばらまかれるウイルスの影響により異常なトラフィックが発生する場合(コラム参照)や、外部からのアタックが原因の異常も考えられるので、メールサーバのログを解析することも必要になっている。
(3)OSやアプリケーションのバグ
バグやシステムエラーによってメールサーバが一時的にダウンするケース。単なるシステムエラーの場合は、一般的には再起動することで比較的短時間で復旧できる。しかしエラーの内容によってはすぐに同じ現象で落ちてしまうことも考えられるので、しばらくはメールサーバの監視が必要になる。いずれにしろ、OSやアプリケーションのパッチ情報などをこまめに取り寄せて情報を集めておくことが大切だ。そしてユーザーの利用が少ない時間帯や休日などを利用してメールサーバを停止し、これらのパッチをあてる作業も必要だろう。
また、特にアプリケーションがダウンしているだけの場合、pingによる返答は返ってくることになる。もしtelnetサービスなどのリモートログイン環境が稼働している場合は、サーバルームなどでハードウェアを一見しただけでは分かりにくい、OSがダウンしているのか?アプリケーションがダウンしているのかということを確認することもできる。telnetでログインできれば、OSは動作しているが、アプリケーションがダウンしていることがpsコマンドなどで確認できるはずだ。
(4)その他の一時的なトラブル
そのほかによくあるのが、ディスクの空き容量不足から作業領域が確保できずに、メールサーバのソフトウェアが動かなくなるケースだ。不要なファイルを削除して仮復旧し、後日HDDの増設を行なうことになる。とはいえ、ユーザーがメールサーバ上にメールを残すようにしているといずれはパンクしてしまうので、ユーザーに定期的な削除を促すなど、運用面でカバーする必要がある。
こういったパターンをある程度頭に入れて、ともかく仮にでも復旧させるための最短の手段を講じるのが管理者の役目だ。トラブルの原因によっては、サーバを止めて入念に調べたい場合もあるかもしれない。しかし、メールサーバの停止は先に触れたようにユーザーへの影響が非常に大きいので、善後策は後で考えることにして「ともかく稼動させつづける」ことを最優先にしなければならないトラブルである。
