●DRサイトへのリモートアクセス設計
ひとたび災害が起これば、自身および家族の安全を第一に考え、被災地域から一時的に避難する社員もいるだろう。一通り安全を確保した後、事業所に行けない場合の会社との連絡手段として、無線ネットワークを使ったリモートアクセスを通じて、DRサイト側のサービスを利用することは十分に考えられる。こうしたケースでは、海外出張中の社員もリモートアクセスを利用する可能性が高い。
そのため、DRサイト側についても、プライマリサイトと同じようにリモートアクセスが可能な設計を施しておく。
ただし、リモートアクセスのゲートウェイそのものをActive-Standby構成にする意味は、セキュリティログの一元化以外にはあまりない。そこで、通常時からプライマリサイト側、DRサイト側ともに社内接続のゲートウェイとして開けておき、クライアントPC側でも双方にアクセスできる設定をしておくと、有事の際の手間が省けて有用である。
ただしこうした設計は、社内へアクセスできる経路が増えることも意味する。それだけセキュリティ面でケアすべき個所が増えてしまうため、セキュリティポリシーと合わせてよく検討のうえ設計したい。
●有事に備えたPC/セキュリティトークン配布
有事のときほど、ノートPCやその利用のためのセキュリティトークンが必要になる。
被災のために手元のノートPCがなくなり、事業継続上重要な業務が停止してしまう可能性は高い。そこで、あらかじめ、有事の際に事業継続上重要な業務を行う役員や社員にPCやセキュリティトークンを配布できるように設計しておくべきだ。さらに、実際に配布できる予備のPCやセキュリティトークンをDRサイトもしくは複数の拠点に配備し、提供に関するルールを整えておくことも有効である。
●リハーサルの重要性
ここまで紹介したポイントを考慮しながら、DRサイトにプライマリサイトの縮退系のシステムを構築したら、それで災害対策はおしまいということにはならない。
重要なのはリハーサルだ。リハーサルを実施し、フェイルオーバーの意思決定プロセスや手順の確認、フェイルバックの手順の確認、実際に掛かる時間の測定、各種改善点の洗い出しを行う。それが、有効性の高いディザスタリカバリにつながる。
●確認できることとできないことを明確に
リハーサルといっても、実際に災害が発生したときとまるきり同じシチュエーションを再現できるわけではない。しかし平常時には、実際にシステムを停止できる時間が短い。そこで、いくつかの制約を加えた上でリハーサルを行うのが一般的である。
例えば、プライマリサイトからDRサイトへの同期に関するリハーサルは行うが、時間的制約から、DRサイト側でサービスを稼働させてデータを書き込んだ後、DRサイト側からプライマリサイト側へ逆同期をするというプロセスを飛ばすことはよくある。この場合、逆同期にかかわる手順はリハーサル内では確認できない。別途ステージング環境などを利用し、手順を確立する必要がある。
つまり、被災時に実際に運用を行う人たちが、「リハーサルで何が確認できて、何が確認できていないのか」を理解すること、そして確認できていない事柄についても何らかの手段で疑似体験できるようにすることが重要である。
●リハーサルを行ってはじめて完成するシステム?
例えばメールサーバとしてMicrosoft Exchangeを使っている環境を考えよう。ディザスタリカバリのためには、DRサイト側でも同じ名前でサービスを立ち上げる必要がある。
しかし、プライマリサイトでサービスを提供している状態でDRサイト側でも同じ名前を持つと、Active Directoryの競合が発生し、サービスを停止してしまう。このため、リハーサル時(あるいは、メンテナンス時など別の機会でもよいが)にプライマリサイトを停止させてからはじめて、DRサイト側のExchangeをインストールできる状態となる。
このようにMicrosoft製品には、Active Directoryと深く連携しているがゆえに、プライマリサイト側のサービスを停止しないとDRサイト側のインストールができないという問題が発生するものがあるため、要注意である。
●事前アナウンスの重要性
リハーサルを実施する際には、少なくとも1カ月以上前にエンドユーザーおよびDR対象外システム管轄部門へのアナウンスが必要だ。「システムが突然落ちた」という苦情はもちろん、営業締め日などと重なってしまうと大変である。
この時、海外拠点にも忘れずにアナウンスを行う。また、DR対象外システムを漏れなく洗い出し、特に、社外と連携するようなシステムが含まれている場合は、社内外への連絡を忘れないようにしたい。
●結果を踏まえて手順を磨く
いくら災害に備えた手順が整えられていたとしても、何の準備もなしに、いざというときその通りに行動できる人は少ない。リハーサルがなければ、実際に災害が発生しない限り、DRサイト側の運用者が手順書を実行することはない。たまに手順の確認をしておかないと腕がなまることになる。
また、リハーサルを行うことで、手順書の中のうまくいかない部分を洗い出し、現行のものよりさらに効率的な手順を見つけることもできる。リハーサルの機会を利用して手順を磨くことは非常に有用だ。
Copyright © ITmedia, Inc. All Rights Reserved.