大地震が発生！ その時、管理者（あなた）は……？：良い管理者 悪い管理者 普通の管理者（4/6 ページ）

[木村尚義，ITmedia]

災害時の対処をマニュアル化し日ごろの訓練を怠らぬ

　〔良いシステム管理者・神田正男〕はとっさに机の下に隠れ、揺れが収まるのを待った。マシンケージやロッカーは固定されており、什器の上に荷物を置かないことが運用マニュアルで徹底されているため、落下物で怪我をすることはなかった。

　しかし、真っ暗で何も見えない。神田はマシンルームの机の下に常備されているヘルメットをかぶり、ヘルメットと同様に常備されている自家発電機能のある白色発光ダイオードの懐中電灯を頼りに、サーバの状態を見に行った。出火はないようだが、念のためマシンルームに常設されている消火器を準備した。

　停電してから10分以上経過しているので、シャットダウンプロセスが始まっていた。シャットダウンプロセスは、シャットダウンスクリプトにより、分散処理されている大阪支店のサーバをメインに切り替えるプロセスが動く。シャットダウンスクリプトが成功すると、神田正男をはじめとする数人の管理者の携帯電話にメールが届くはずである。

　ところが、サーバのシャットダウンは正常に終了したが、メールは届かなかった。シャットダウンスクリプト自体は成功しているから、サーバからはメールを投げているはずだ。しかし、経路のどこかで震災の影響が出ているらしい。つまり、大阪支店のサーバは自動的にメインになっていないのだ。

　後日分かったことだが、建物の電源や集線装置がある地下室で浸水があり、外部との通信が一切遮断されてしまったようだった。

　そんなことを考えているとき、不意にメール着信音が鳴った。大阪支店の管理者から神田に安否確認のメールが届いたのだ。震災は昼のニュースで知ったらしい。携帯電話の音声による通話は不通だったが、携帯メールは多少の遅延があるものの、正常に届くようだ。神田は音声の通話をあきらめ、携帯メールを使って大阪支店の管理者に無事を知らせるとともに、大阪支店のサーバを手動でメインサーバにするように依頼した。

　マシンルームのIP電話は停電時に使えないだろうということも想定していたので、あらかじめ携帯メールの連絡網を作っていたのだ。

各地にファイルを分散させリアルタイムに複製

　神田は今回の震災の2カ月前、災害対策マニュアルVer1.0を完成させていた。マニュアルは、阪神淡路大震災や、新潟中越地震の教訓を元に策定したものだ。神田ら管理者が行った調査は以下のようなものである。

障害の内容	調査内容
数分間の停電	無停電電源装置で対処。無停電電源装置は使用年数により徐々に劣化するので、定期的に容量を確認
数時間にわたる停電	建物との契約で燃料を使った非常用電源が使える。しかし、夏場は空調のパワー不足が判明。冬の訓練では気が付かなかったが夏季には熱の対策が必要
24時間をこえる停電	対処不能
ISPは無事	ISPは無事であっても、ホスティングされているサービスのメンテナンスのためにリモート接続する必要あり
ISPそのものがダウン	コンピュータルームで対策できるのは社内の配線まで

A社の災害対策調査

A社のネットワーク構成

　対策マニュアルで考慮したのは、被災の度合いにより各地のコンピュータシステムのみをバックアップしても意味がないことだった。そして、神田らが出した結論は、各地にサーバを分散させることであった。

フォルトトレランスDFSの仕組み

　つまり、東京本社と各拠点でメールシステムとファイルシステムを持ち、定期的に複製処理を行う。それも、なるべく自動化するようにした。分散ファイルシステム(DFS：Distributed File System)により、重要データは札幌、東京、大阪、福岡に自動的に複製されている。メールは、安否確認のためにも最優先で立ち上げることにして東京および大阪で複製することにした。IDとパスワードが格納されているディレクトリサービスも東京と大阪で自動複製を行っている。当然、すべてのデータをすべての拠点に複製すれば確実である。しかし、すべてのデータに冗長性を持たせるとメンテナンスのためにTCOは確実に増加してしまう。

　そこで、東京と大阪が同時に壊滅的被害を受けることはほぼないだろうという見解で対策することにした。東京にあるサーバがダウンしたときは、大阪、札幌、福岡の3拠点で協力して、まかなおうというものである。