現場の視点で見る災害対策（2）：DRサイトの実現方式と設計上のポイント：ディザスタリカバリで強い企業を作る（5/5 ページ）

[小川晋平，ITmedia]

エンドユーザー側の切り替え設計

　いざ災害が発生したとして、エンドユーザーがDRサイトのサービスを使えるようになって初めてディザスタリカバリの意味がある。したがって、エンドユーザー側での切り替え設計は非常に重要だ。

　ここでは、クライアントPCのOSはWindows系OSであると想定し、設計のポイントに触れておこう。

　切り替えの際は、エンドユーザー側でできる限り設定変更を行わせない方式をとりたい。それを実現するためには、プライマリサイトの設計／設定の中に、「IPアドレスの直打ち」という項目がないかどうかが1つのポイントになる。

　プライマリサイト側で提供しているサービスがDNS（名前解決）によって提供されている場合は、DNSの設定変更に加え、クライアント側でipconfig/flushdnsを実行すればDRサイト側に切り替えることができる。もちろん、DNSサーバのリソースが許される限りSOAレコードをチューニングすることにより、セカンダリDNSのレコードへの切り替えをより迅速に行えるようになる。

●既存のバックアップジョブとチェックポイントジョブコントロールの連携

　レプリケーションを行う場合には、まず最初に「初期同期」を行い、後は差分を転送するという実装が一般的だ。この初期同期を行う際は、WAN回線やストレージに大きな負荷が掛かる。

　しかしながら、WAN回線やサーバの部分障害などによってプライマリサイト側とDRサイト側でデータの整合性に乱れが生じ、レプリケーションプログラム側でどこまで同期したかが分からなくなるような状況も発生する。こうなるともう一度、初期同期から同期作業をし直すことになってしまうが、こうした状況を回避するため、通常はレプリケーションプログラムがチェックポイント機能を有している。

　プライマリサイト側では通常、何らかの形でバックアップを行っている。集中バックアップシステムによってバックアップジョブコントロールを行っている場合、例えば1日1回バックアップジョブの中にチェックポイントコマンドを一緒に埋め込んでしまうという手がある。こうした工夫により、無駄な負荷がシステム全体に掛からないようにできる。