PR

 前回の内容は,タイムリミットを回避することができたものの障害対応は手詰まり状態であり,翌朝までのメール・サーバー復旧を確実にするためには,バックアップ・データのリストアしか方法がないと判断するまでであった。今回は,バックアップ・データのリストアを実行し安堵したのもつかの間,新たな問題が発覚するまでを紹介する。

 「過去に受信したメールをすべて復元することはできませんが,最も可能性が高い方法だと思います」

 私たちは,運用担当チームの責任者に再度状況を報告し,バックアップ・データのリストアが最も復旧の可能性が高い方法であると提案した。

 「ハードディスクなどの障害LEDが点灯していないため,ハードウエア障害の可能性は低いと思います。ならば,壊れたデータベース・ファイルをバックアップ・データからリストアすれば,メール・サーバーは復旧するはずです。ただしこの方法には一つ問題があります。メール・サーバーが復旧したとしても,最後にバックアップを行なった時点以降に受信したメールは復元できません」

 検討した結果,私たちはバックアップ・データのリストアを実施することにした。今回障害の発生したメール・サーバーの目的は,システムの監視とバッチ処理実行結果の確認であるため,既に確認済みである過去のメールの復元は優先度を下げても問題無いと判断したのだ。

 障害対応の目的は,システムが提供するサービスを復旧させ,正常な状態に戻すことにある。従って,機器の障害が長期的なサービスの障害に直結することの無いよう,システムを構成する各機器はすべて多重化し,迅速なサービスの復旧を図れる構成にしておく必要がある。しかし,今回障害の発生したメール・サーバーは多重化されていなかった。そのため,このような対処が必要となったのだ。

 機器の多重化には一般的に,ホットスタンバイの構成を取る冗長化の手法と,コールドスタンバイの構成を取る手法とがある。コールドスタンバイであればメール・サーバーの場合,予備機を用意しておくことになるだろうが,ホットスタンバイの構成をとるメール・サーバーの冗長化には,メール配送経路の冗長化(図3)とメールボックスもしくはメール・データベースの冗長化(図4)という2つのパターンに分けられる。

図3●メール配送経路冗長化の例
図3●メール配送経路冗長化の例
図4●メール・データベース冗長化の例
図4●メール・データベース冗長化の例

 前者は,DNSサーバー上にMXレコードを2つ記述する方式である。このパターンの場合,メールの配送経路が2重化されるため外部(メール送信元)から見たメール・サーバーの可用性は向上する。だが,今回のようにメールボックス自体に障害が発生した場合は,メールのスプールおよびクライアントからメールボックスへのアクセスが出来なくなってしまうため,冗長化の効果は薄い。

 後者のメールボックスもしくはメール・データベースの冗長化は,今回のような障害に対して非常に効果が高い。とは言え,メールボックスを配置するストレージの冗長化やデータの同期を取る仕組みにかかる費用が高額であるため,今回障害の発生したメール・サーバーの用途を考えると,費用対効果の面で導入が難しかったのである。