こういう場合には、テープにバックアップを行い、物理的に搬送して同期を行う方法が妥当だ。
10TBのファイルサーバであれば、通常、数百GB程度のボリュームを複数持つ設計がなされているだろう。ボリュームごとにチェックポイントを発行し、プライマリサイトのテープバックアップをブロック単位で行う。そして、そのテープを順次、安全な手段でDRサイトに配送する。DRサイトではテープからプライマリサイトと同じブロック列をリストアし、チェックポイント移行の差分をネットワーク経由で転送する。
仮に、バックアップとテープの配送、リストアといった作業に3日かかったとしても、3日分の差分データのみをネットワーク経由で同期すればよい。このため、すべてのデータをネットワーク経由で同期する場合に比べ、負荷が圧倒的に下がる。
以上のように、WANの帯域にはコスト面での制約があるため、初期同期には思わぬ苦しみが発生する。レプリケーション対象となるデータが大容量の場合には要注意だ。
なお、ストレージを新規に導入する場合には、まずプライマリサイトにDRサイト用のストレージも仮に設置し、ローカルのSAN内でコピーを完結した後、DRサイト用ストレージをDRサイトに移設するという手もある。
●帯域制御と圧縮
レプリケーションを行うプログラムの中には、それ自体に帯域制御機能が付いているものがある。
シマンテックの「VERITAS Storage Foundation Volume Replicator(VVR)Option」を例にとってみよう。VVRではサーバ単位でレプリケーションを行う。例えばレプリケーション対象サーバが10台あり、WAN回線が100Mbpsという構成を考えてみよう。もし、すべてのサーバで同時にレプリケーションのピークがくる場合には、それぞれ最大10Mbps程度の帯域しか確保できないことになる。
こうした状況で帯域制御が行われないと、時に輻輳が発生し、データの再送が繰り返されることになる。最悪の場合は、レプリケーションが完了しないこともあり得る。そのため、運用を行いながら状況を監視し、それに基づいて適切な帯域制御設定を行っていく必要がある。
同様に、レプリケーションを行う際に同時に圧縮を行う機器(ハードウェア)もある。こうしたツールは積極的に利用したい。
●被災センターを確実に「ダウン」させる設計
マイクロソフトのActive Directoryを使っている場合に注意が必要なことがある。DRサイト側でプライマリサイトと同じ名前でサービスを提供すると、名前の競合が起き、エラーが生じるという問題だ(後述)。
災害発生時にプライマリサイトとDRサイトの通信が断続的に停止するような場合は、こうした事態が生じる恐れがある。それを防ぐため、フェイルオーバーを行う決断を下したならば、被災したプライマリサイト側は思い切ってネットワーク的に孤立させてしまうほうがよい。
では、被災したプライマリサイトを確実にダウンさせるにはどうするか。
現地に人が入れる状況であれば、直接、ネットワーク機器を停止すればよい。しかし、現地に入れない場合はルーティング設定を変更することで、プライマリサイトをネットワーク的に孤立させることが可能である。したがって、あらかじめ自社の各拠点のルーティング設定を簡単に入れ替えられるよう設計しておくことをお勧めする。
Copyright © ITmedia, Inc. All Rights Reserved.