本記事は、原著者の許可を得て以下のリンクを翻訳したものです。翻訳内容に誤りがある場合、その責任は翻訳者にあります。また記事によっては、訳語を適宜Qiitaで読みやすいように段落分け、カテゴライズ分けをして記述しているものもありますのでご了承ください。
https://fullvalence.com/2025/12/03/from-vmware-to-ibm-cloud-vpc-vsi-part-6-disaster-recovery/
このシリーズの全てのブログ記事はこちらです：
- VMwareからIBM Cloud VPC VSIへ（パート1）：導入
- VMwareからIBM Cloud VPC VSIへ（パート2）：VPCネットワーク設計
- VMwareからIBM Cloud VPC VSIへ（パート3）：仮想マシンの移行
- VMwareからIBM Cloud VPC VSIへ（パート4）：バックアップとリストア
- VMwareからIBM Cloud VPC VSIへ（パート5）：VPCオブジェクトモデル
- VMwareからIBM Cloud VPC VSIへ（パート6）：ディザスターリカバリー
- VMwareからIBM Cloud VPC VSIへ（パート7）：自動化
- VMwareからIBM Cloud VPC VSIへ（パート8）：Veeam Backup and Replication
この記事では、IBM Cloud VPC VSI が持つネイティブ機能のうち、ディザスタリカバリーに利用できるものを簡単に取り上げ、それを代替アプローチと比較します。
Copied Snapshot(コピーされたスナップショット)
以前取り上げたように、IBM Cloud Backup for VPC のバックアップポリシーでは、VSI ボリュームのスナップショットをスケジュールするだけでなく、そのスナップショットを別の IBM Cloud リージョンへコピーするスケジュールも設定できます。この仕組みを使うことで、ディザスタリカバリーの目的で VSI データを別リージョンへ定期的にレプリケートできます。ただし、この方法には多くの制限があるため注意が必要です：
-
同一リージョン内のスナップショットでは、個々の VSI の全ボリュームを整合性のある形で取得できますが、複数の VSI をまとめて整合性を保証することはできません。一方、タグベースでのクロスリージョン・スナップショットコピーは VSI に紐づく関係を無視してボリューム単位でしか実行できません。このため、単一の VSI 内であっても書き込み順序の整合性（write-order consistency）は保証されません。
この制限を回避したい場合は、API や CLI を使い、まず VSI 整合性のあるスナップショットを作成し、次に各ボリュームのコピーを別リージョンへ個別に実行する必要があります。 -
この自動化に、VSI 内のアプリケーションのquiesce（静止）処理を加えることで、安定したレプリカを確保したり、複数 VSI にわたる書き込み順序の整合性を確保したりできる可能性があります。
-
Backup for VPC では、crontab 形式の表記でスナップショットとコピーのスケジュールを設定できます。ただし、原則としてスナップショットやコピーは同一リージョン内でスペース効率のよいチェーン構造として保持されるものの、ボリュームサイズに応じて初回のフルコピーには時間がかかります。さらに、クロスリージョンコピーを増分コピーにしたい場合、ボリュームサイズに応じてスナップショット作成およびコピー頻度を下げる必要があります（このテーブルを参照のこと）。例えば筆者のテストでは、250GB のブートボリュームで、スナップショットとコピー間隔を2時間に設定する必要がありました。
訳者注: IBM Cloud docsには以下の記述が記載されています。
https://cloud.ibm.com/docs/vpc?topic=vpc-backup-service-about&interface=ui&locale=en#backup-service-crc
- クロスリージョンコピーを含むバックアップジョブでは、まず元リージョンでスナップショットが作成され、安定状態（stable）になるまでデータ転送が続きます。その後コピー先リージョンでコピーが作成されデータ転送が開始されます。
- ボリューム容量が大きいほどコピー時間が長くなります。（例：3TB ボリュームのコピーには 12.5時間以上かかるとdocsには記述されています）。
- 初回のリモートコピーはフルコピー。2回目以降は、直前のスナップショットがコピー先に存在し安定している場合のみ増分コピーが可能です。
- 直前のスナップショットがまだ安定していない状態で新しいコピーを実行すると、増分ではなくフルコピーが実行されます。そのため、例えば3TB ボリュームで12時間間隔を設定しても、前回コピーがまだ安定していないため毎回フルコピーになってしまう可能性があります。
-
そのテーブルは最低限の目安を示しているように見えます。実際には2時間間隔であっても、コピーされたスナップショットが増分ではなくフルコピーになっている場合がありました。
-
いずれにしても、増分コピーかフルコピーかに関わらず、コピーにかかる時間のため、実効 RPO は2時間間隔よりやや長くなります。また、これらのコピーはスペース効率こそ良いものの、一般的に RPO が非常に低い「真のレプリカ」とは言えません。
-
ポリシーでは、ソースリージョンで最低3つ、コピー先リージョンでも最低3つのスナップショットを保持する設定を推奨します。これは、常に有効なコピーを確保するため（最低2つ必要）だけでなく、ストレージシステムが最新スナップショットを基準に増分を計算している最中に、古いスナップショットの削除や統合が同時に行われる事態を避けるためです。
-
バックアップや VPC オブジェクトモデルの説明と同様、ストレージボリュームだけでなく環境全体を復元する計画が必要です。例えば、パブリックIPアドレスは新しいリージョンでは変更されるため、ネットワークの再構成が必要です。また、プライベートネットワーク接続も新リージョンへ向けてルーティング変更が求められます。
-
新リージョンで VM を再作成すると、新しい UUID が割り当てられ、cloud-init が再実行されます。その結果、root パスワードや SSH authorized_keys のリセットなどの副作用が発生するため、事前に準備が必要です。
これらの制限があっても対応可能なケースもありますが、そうでない場合は別のアプローチを検討する必要があります。
スタックの上位層へ目を向ける
一般に、より厳しい BCDR（Business Continuity and Disaster Recovery）要件を満たすには、スタックの上位層に移行する、またはスタックを跨ぐソリューションに投資する必要があります。例えば、ストレージアレイのレプリケーションを活用すれば、効率的かつ低い RPO でのレプリケーションが可能です。しかし、トランザクション整合性を確保するには、ファイルシステムやデータベースのQueice（静止）処理と組み合わせる必要があります。単なるクラッシュ整合性では不十分な場合が多いためです。
そのため、エンタープライズアーキテクチャでは、エージェントベースのツールやアプリケーション／データベース固有の手法を使ってレプリケーションを行う、あるいはオーケストレーションする方法が一般的です。これらの方法は、OS、アプリケーション、メッセージング、データベースなど、あなたのソリューションアーキテクチャに大きく依存します。
したがって、使用している技術スタックと DR の要件に基づき、どのツール・手法が適しているかを調査・評価する必要があります。たとえば、DB2 を使用しているなら、IBM Cloud の異なるリージョン間でデータベースをレプリケートするために Q Replication や SQL Replication を検討できます。OS エージェントの利用はバックアップでは一般的ですが、DR（ディザスタリカバリー）ではあまり一般的ではありません。しかし、求める RPO によっては有効な選択肢になり得ます。ただし、エージェントベースのバックアップでは、現時点で VSI の ISO ブートがサポートされていないため、復旧方法に制限があるかどうかの確認が必要です。
このようなアプローチは、一般的に本番と DR の両方の場所にアクティブなインフラを保持することが前提となります。これにより、いくつかの計画や実行の側面が複雑になります。たとえば、レプリケートされた環境は元の環境と同じ IP アドレスを持たないため、アプリケーションユーザー側には DNS 切り替えで隠蔽する必要があります。一方で、フェイルオーバー時に新規リソースを作成する必要がない（事前に作成済みである）ため、計画や実行の他の側面はむしろ簡素化されます。