いまどきのサーババックアップ戦略入門（4）

遠隔バックアップと復旧の現実解

株式会社シマンテック
後藤 博之
2007/12/13

---

　レプリケーションのアーキテクチャ

　ここからは遠隔拠点でのバックアップ手法について説明する。レプリケーション技術のアーキテクチャは、大きく分けて2つある。

　1つ目は「同期モード」によるリモートサイトのディスク装置（ボリューム）へのデータ更新である。同期モードは、ローカルサイト上で稼働しているアプリケーションによる書き込み処理が完了する前に、リモートサイトのデータを即時に反映するアーキテクチャである。同期モードの動作イメージとして、DOSコマンドプロンプトからコマンドを実行し、プロンプトが戻ってきたときには、リモートサイトのデータが反映されていることを保証している状態に近いと表現すれば分かりやすいと思う。

　もう1つは「非同期モード」によるリモートサイトへのデータ更新である。非同期モードは、ローカルサイト上で稼働しているアプリケーションによる書き込み処理が完了し、ある一定期間が経過した後、リモートサイトのデータを反映するアーキテクチャである。非同期モードの動作イメージは、DOSコマンドプロンプトからコマンドを実行し、プロンプトが戻ってきた後、リモートサイトのデータが反映することを保証するのに似た状態である。

　「同期モード」と「非同期モード」を選択する際の違いとして、以下の表に示したような項目がある。システムにおいて重要視するポイントに応じて、いずれかを選択する必要がある。

	同期モード	非同期モード
リモートサイト上のデータを最新の状態に保つ	◎ リモートサイトは常に最新。	△ 常に最新とは限らない。リモートに反映されていないデータがローカルサイトに存在する可能性がある。
データ遅延の管理	◎ 少量の書き込みに適している。また、リモートサイトが常に最新のため、遅延保護の必要はない。	△ リモートサイトでデータ遅延が発生する可能性あり。ローカルサイトで災害が発生した際、トランザクションが失われてよいかどうか、またどの程度まで許容できるか考慮する必要あり。
ネットワーク特性	△ 帯域幅が広く、遅延が小さい状況に最も適している。 サイト間通信帯域は、常にアプリケーションの書き込み速度と同等か、それを上回る必要がある	◎ サイト間の通信帯域幅の変動によるアプリケーションのパフォーマンス影響を最小限に抑える。
アプリケーションの応答	△ リモートサイトへのデータ反映が完了しない場合、アプリケーションのパフォーマンスに影響あり	◎ アプリケーションパフォーマンスへの影響を最小限に抑える。

表1　同期モードと非同期モードの選択を左右する要素

　また、ディスク装置またはボリューム管理ソフトウェアで提供しているレプリケーション機能を使ったデータ更新のアーキテクチャの多くは、更新された情報をブロック単位でリモートサイトにデータ転送する方式を採用している。ブロック単位のメリットは、ファイル単位と違い、「変更差分のデータ（ブロック）のみを転送できる点」と「ネットワーク負荷を少なくできる点」にある。ファイル単位の場合、オフィス・アプリケーション系の既存ファイルを変更し保存した場合、そのファイル全体をリモートサイトに送信するが、ブロック単位であれば、ディスク装置（ボリューム）から見て変更されたブロックのみをリモートサイトに送信する。リモートサイトに転送するデータ量が比較的少ないことにより、ネットワーク負荷が少なくなるといえる。

レプリケーションにおけるデータ保護上の課題

　これまで、レプリケーションによる遠隔拠点へのデータ転送について説明してきた。以下ではレプリケーションに対応した環境において、データ保護の課題となる内容について触れていく。

　レプリケーションの特徴として、「リアルタイム性」や「同期／非同期モードによるリモートサイトのデータ更新」を説明したが、仮にローカルサイト上のアプリケーションに障害が発生し、データが不整合になった場合はどうだろうか？この場合に想定される動作として、不整合な状態もレプリケーションしてしまうのは注意すべきポイントだ。ディスク装置ベースやボリューム管理ソフトウェアによるブロック単位のリモートサイトへのデータ更新では、そのほかの要因であるアプリケーションおよびデータベースのデータ不整合や、ネットワーク回線障害によるリモートサイトへのデータ転送不可の障害について考慮する必要がある。

　このような障害に対しては、第3回でも触れたようにスナップショットを使い、レプリケーション中における静止ポイント（ある一定時点のデータ）を取得する方法がある。スナップショットを取るサイトについては、ローカルサイトのみもしくはリモートサイトのみ、もしくは両方で取得する構成を組むことも可能だ。スナップショットをいずれかのサイトで取得することにより、万が一レプリケーション中にデータ不整合が発生したとしても、スナップショット領域からのデータリストアが可能である。またスナップショットではなくバックアップを取得する選択をすることもできる。　

図3　ローカル、リモート両拠点でスナップショットを取ることも考えられる

　広域災害などへの対応を目的とした遠隔拠点への復旧について触れてきたが、対象となるシステムのサービスレベルに応じて、RPO／RTOやデータ保存世代などを検討する必要がある。またサービスレベルも重要ではあるが、遠隔拠点への復旧を検討する段階において、ビジネス継続計画によるプランニングが一番重要な点だといえる。システム稼働率（アベイラビリティ）を向上させることもぜひ検討していただきたい。

今後の連載

　今回は、遠隔バックアップ手法の詳細について紹介した。連載の最後となる次回は応用編として、アプリケーションや特定システムに依存する話題、システムバックアップについての話題に触れていく予定である。

3/3

Index
遠隔バックアップと復旧の現実解
	Page1 イメージを遠隔拠点にデータ転送
	Page2 レプリケーションで遠隔拠点にデータ転送
	Page3 レプリケーションのアーキテクチャ レプリケーションにおけるデータ保護上の課題 今後の連載

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）