Google Cloud 上での SAP NetWeaver 向け障害復旧のプランニングガイド

Google Cloud を使用して、Google Cloud、オンプレミス、または別のクラウドプロバイダで実行されている SAP システムの障害復旧ソリューションをホストできます。

障害復旧の定義

障害復旧（DR）と高可用性（HA）はビジネス継続性というコンセプトを実現するための重要な要素です。このガイドでは、障害復旧について説明します。

DR ソリューションは、自然災害や人為的な災害、またはインフラストラクチャの障害で大規模な停止が発生した後に、アプリケーションの処理を復元するように設計されています。こうした停止が発生すると、メインのアプリケーションシステムだけでなく、小規模なシステムやローカルのインフラストラクチャの障害から保護するスタンバイシステムも停止します。

DR ソリューションには、高可用性ソリューションと異なり、次のような特性があります。

通常、DR ソリューションのリカバリシステムはホットスタンバイシステムではありません。
障害復旧手順では通常、データ、システム、インフラストラクチャのバックアップまたはレプリケーションからアプリケーションの処理を復旧または復元するために、手動操作が必要になります。
ソリューションには、プライマリシステムと地理的に離れた場所にあるリカバリサイトが含まれます。
通常、障害復旧ソリューションの目標復旧時間（RTO）は、日単位ではなく時間単位で測定されます。

次のアーキテクチャの SAP システムには、HA ソリューションと DR ソリューションの両方が含まれています。障害発生後にシステムが復元される DR サイトは、右側のリージョン 2 にあります。プライマリシステムは左側のリージョン 1 にあり、2 つのゾーンにまたがるフェイルオーバークラスタで高可用性を実現しています。両方のリージョンにまたがる点線が DR ソリューションのバックアップ機能を表しています。また、このシステムではマルチリージョンの Cloud Storage バケットを使用しています（図の一番下に表示されています）。

この例にはデータベースも含まれています。アプリケーションの復旧にはデータの復旧も関係していますが、ここでは、データベースシステムの DR 手順について触れません。データベースのドキュメントまたは該当する SAP ノートをご覧ください。このガイドでは、SAP NetWeaver システム（SAP ASCS / ERS）とアプリケーションサーバー（SAP AAS）を中心に説明します。

DB を使用した HA および DR システムの概要: 左側の 2 つのゾーンに HA システムがあり、右側の別のリージョンに DR サイトがあります。

Google Cloud での高可用性 SAP システムの実装については、Google Cloud 上での SAP NetWeaver 向け高可用性のプランニングガイドをご覧ください。

Google Cloud での SAP HANA の高可用性と障害復旧については、SAP HANA 高可用性プランニングガイドと SAP HANA 障害復旧プランニングガイドをご覧ください。

Google Cloud での DR の一般的な情報については、障害復旧計画ガイドをご覧ください。

Google Cloud で実行されていない SAP システムの DR 設計アプローチ

メインの SAP システムが Google Cloud 上で実行されていない場合は、DR ソリューションにリフト＆シフト方式を使用できます。この場合、DR システムのアーキテクチャとソフトウェアは、プライマリシステムと同じものになります。また、クラウドネイティブ方式を使用することもできます。この場合、DR ソリューションの設計の一環として、Google Cloud または Google Cloud パートナーのプロダクトやサービスでサポートされているクラウド向けに復旧されたシステムを最適化します。

リフト＆シフト方式を使用する場合は、プライマリシステムのアーキテクチャが Google Cloud で完全にサポートされていることを確認する必要があります。いずれの方式でも、使用するすべてのソフトウェアが Google Cloud で使用できるように適切にライセンスが付与されている必要があります。

ライセンスの詳細については、Google Cloud Platform の利用規約をご覧ください。

Google Cloud 上での SAP NetWeaver 用の DR ソリューションの設計要素

Google Cloud 上での SAP NetWeaver 用の DR ソリューションの設計要素には、次のものがあります。

DR サイトのロケーション
ネットワーキング
セキュリティ
仮想マシン（VM）の考慮事項
バックアップオプション
ストレージ

復旧目標とコスト目標を満たすため、これらの設計要素を実装する際にはさまざまな選択肢を検討します。

DR サイトのロケーション

DR サイトの Google Cloud リージョンを選択する際は、次の点を考慮する必要があります。

プライマリサイトで障害の影響が生じる可能性がある領域
SAP NetWeaver システムのユーザーが存在する場所
SAP システムが使用する Google Cloud のリソースと機能を、選択したリージョンとゾーンで使用できるかどうか

プライマリサイトから十分に離れた場所にある DR サイトの Google Cloud リージョンを選択し、プライマリサイトで発生する可能性のある障害によって DR サイトが影響を受けないようにします。通常、100 マイル以上の距離で十分と見なされますが、規制や組織のガイドラインによっては最短距離が異なる場合があります。

プライマリ SAP システムが Google Cloud で実行されている場合は、プライマリシステムが実行されているリージョン以外の、ユーザーに近い Google Cloud リージョンに DR サイトを配置します。同一の障害によって 2 つの Google Cloud リージョンが影響を受けないように、各 Google Cloud リージョンは十分に離れた場所に配置されています。

プライマリ SAP システムが Google Cloud の外部で実行されている場合は、プライマリサイトで発生する可能性のある障害によって影響を受ける可能性のあるゾーン以外の、できるだけユーザーに近いリージョンに DR サイトを配置します。

DR リージョン内では、SAP システムやデータベースシステムが必要とする VM インスタンスタイプと他のインフラストラクチャをサポートするゾーンに DR システムを配置します。

DR サイトのリージョンを選択した後、イベント発生前に DR システムに十分なリソースが提供されているように、リージョンのリソース割り当ての変更が必要になることがあります。

すべての Google Cloud リージョンの場所については、リージョンとゾーンをご覧ください。

各リージョンで利用可能な機能については、利用可能なリージョンとゾーンをご覧ください。

グローバル、リージョン、ゾーンの Google Cloud リソースについて詳しくは、グローバルリソース、リージョンリソース、ゾーンリソースをご覧ください。

ネットワーキング

Google Cloud では、Virtual Private Cloud（VPC）によって世界中に広がるネットワーク機能が提供されます。

DR サイト用の VPC ネットワークがまだ存在しない場合は、作成する必要があります。また、DR サイトのサブネットワークと IP 範囲を作成する必要があります。

プライマリシステムが Google Cloud 上にある場合、プライマリサイトと DR サイトの両方が同じ VPC ネットワーク内にあると、ネットワークの構成が容易になります。必要であれば、プライマリサイトと DR サイトを別々の VPC ネットワークまたはプロジェクトに配置することもできます。

DR ソリューションを設計する際に、次の通信パスを検討する必要があります。

Google Cloud のプライマリサイトと復旧サイト間の接続
SAP システムを構成するアプリケーション、データベース、サーバー間の内部通信
ユーザーと SAP システム間の接続

Google Cloud の外部にあるサイトからの接続用に、Google Cloud はさまざまなネットワーキングプロダクトを提供し、これらの接続ポイントをサポートしています。

プライマリサイトと DR サイトの接続

バックアップを保存し、2 つのシステム間のレプリケーションパスを提供するには、プライマリサイトと DR サイトの接続が必要です。この接続により、障害発生時や障害復旧手順のテストでリカバリリソースをすぐに利用できるようになります。

プライマリシステムが Google Cloud で実行されている場合、DR サイトでのバックアップの作成はほぼ自動的に行われます。Compute Engine スナップショットは、マルチリージョンとして指定できます。他のバックアップは、DR サイトですぐに使用できるように、プライマリシステムからマルチリージョンの Cloud Storage バケットに直接保存できます。

プライマリシステムが Google Cloud で実行されていない場合は、Cloud Interconnect または Cloud VPN を使用して、プライマリサイトを Google Cloud の DR サイトに接続できます。

高可用性の Cloud Interconnect トポロジは、少し変更するだけで DR シナリオに利用できます。詳細については、Dedicated Interconnect で 99.99% の可用性を実現するをご覧ください。

DR シナリオに応用できる高可用性のマルチリージョン VPN ゲートウェイトポロジについては、Cloud VPN トポロジをご覧ください。

プラットフォーム外のサイトから Google Cloud への接続を設定する際の重要な考慮事項は帯域幅です。接続によって、Google Cloud への定期的なデータ転送とバックアップが適切にサポートされる必要があります。

プラットフォーム外のサイトから Google Cloud に接続する方法について詳しくは、ハイブリッド接続プロダクトをご覧ください。

SAP アプリケーション、データベース、サーバー間の接続

プライマリシステムが Google Cloud 上で実行されている場合、DR サイトで SAP アプリケーション、データベース、サーバー間の接続を維持することは、プライマリサイトでホスト名、サブネット、ファイアウォールなどをモデル化するという比較的簡単な作業で行えます。

プライマリシステムが Google Cloud で実行されていない場合は、プライマリサイトのネットワークアーキテクチャを Google Cloud の DR サイトに変換する作業が、設計フェーズでさらに必要になる可能性があります。

復旧したシステムでビジネスに重要な処理を行う前に、DR 手順をテストして、接続に関する問題を特定し、解決しておく必要があります。

ユーザーと DR サイトの接続

SAP システムが DR サイトに復元されたら、復旧されたシステムにユーザーからのトラフィックを再ルーティングする必要があります。通常は、DNS エントリ内のネットワークエイリアスを新しい IP アドレスに更新します。

ネットワークアーキテクチャが VPC ルートを使用している場合、復旧中にルートを更新する必要があります。

Google Cloud では、Cloud DNS を使用することも、別の DNS ソリューションを使用することもできます。

リージョンネットワークリソース

プライマリシステムが Google Cloud で実行されており、Cloud NAT やリージョン Cloud Load Balancing などのリージョンネットワークリソースを使用している場合、各リージョンにリソースのインスタンスが必要です。

詳細については、以下をご覧ください。

ネットワークアクセス制御

プライマリサイトで開いているポートと同じポートが DR サイトで開いていることを確認します。

VPC ネットワークでファイアウォールルールを定義して、VM との間のトラフィックを制御できます。

Windows Server で Active Directory サービスを使用している場合は、このサービスを復旧前に設定し、プライマリサイトの Active Directory インスタンスと同期する必要があります。

セキュリティ

DR サイトのプライマリサイトと同じセキュリティ制御と権限を実装する必要があります。復旧した環境も同じコンプライアンス規制の対象になります。

プライマリサイトにアクセスするユーザーまたは役割には DR サイトへのアクセス権も必要です。

Google Cloud での DR ソリューションのセキュリティの設計に関する一般的な情報については、セキュリティ管理とコンプライアンス管理の実装をご覧ください。

VM に関する考慮事項

Cloud Deployment Manager、インスタンステンプレート、カスタムイメージなど、Google Cloud 、プロダクト、機能によって提供される Terraform 構成を使用すると、Compute Engine 仮想マシン（VM）インスタンスのデプロイを高速化し、DR サイトでの構成エラーを回避できます。

仮想マシンの構成とデプロイ

Google Cloud には、SAP システムを事前定義して DR サイトにデプロイできる、Google Cloud 上の SAP 用の Terraform 構成ファイルと Deployment Manager テンプレートが用意されています。Terraform または Deployment Manager のファイルを使用すると、デプロイを迅速に行い、構成エラーが減らすことができます。また、SAP のサポート要件を満たす SAP システムを構築できます。

Compute Engine インスタンステンプレートでも VM を事前に構成できます。インスタンステンプレートを使用すると、デプロイを迅速に行い、復旧中の VM の手動構成を減らすことができます。ただし、DR サイトの再構成が必要になるため、次のセクションで説明するように、復旧用のブートディスクから VM を回復するほうが簡単な場合があります。

インスタンステンプレートの詳細については、インスタンステンプレートをご覧ください。

Terraform などのデプロイオーケストレーションツールを使用して、Google Cloud 上でのインフラストラクチャのデプロイを管理することもできます。

RTO によっては、Compute Engine インスタンスを事前にデプロイできますが、VM のデプロイに数分程度で完了するので、復旧時にデプロイすることも可能です。

VM を事前にデプロイする場合は、費用を抑えるために VM を停止するか、復旧で必要になるまで他の重要でない作業に使用できます。

また、復旧サイトでより少ない VM に分散システムを統合することで、費用を最小限に抑えることもできます。たとえば、プライマリサイトのアプリケーションサーバーが、DR サイトのプライマリサイトの専用ホストにある場合、アプリケーションサーバーを SAP Central Services と同じホストに配置できます。ただし、各サイトで異なる構成を使用するため、管理作業は煩雑になりますが、この点を犠牲にしても、コストの削減が必要な場合もあります。

回復用のブートディスク

プライマリシステムでホストのブートディスクからカスタムイメージを作成し、このイメージから DR サイトの復旧用インスタンスを作成します。

システムが Google Cloud で実行されている場合、プライマリシステム用の Compute Engine 永続ブートディスクを作成して変更した場合は、カスタムイメージを作成します。変更されていない Google Cloud の公開イメージを使用している場合は、復旧サイトでも Google Cloud の公開イメージを使用できます。詳細については、カスタムイメージの作成、削除、非推奨をご覧ください。

システムが Google Cloud で実行されていない場合は、オンプレミス環境から Google Cloud にブートディスクイメージをインポートするか、ローカルワークステーションまたは別の Cloud Platform で実行されている VM から仮想ディスクをインポートできます。

バックアップオプション

Google Cloud には、DR ソリューションを設計する際に選択できるさまざまなバックアップオプションが用意されています。

Compute Engine カスタムイメージ
Compute Engine 永続ディスクスナップショット
レプリケーション

Compute Engine カスタムイメージ

復旧で使用するプライマリシステムのブートディスクをバックアップするには、Compute Engine のカスタムイメージとして Google Cloud に保存します。詳細については、回復用のブートディスクをご覧ください。

Compute Engine 永続ディスクスナップショット

Compute Engine 永続ディスク上にある SAP またはその他のファイルシステムをバックアップするには、永続ディスクスナップショットを使用します。

スナップショットのスケジュールを定義し、スナップショットを定期的に自動で取得することもできます。詳細については、永続ディスクのスナップショットスケジュールの作成をご覧ください。

スナップショットは、ブロックレベルの整合性のみを提供します。ファイルレベルの整合性を維持するには、これらのスナップショット中にターゲットファイルシステムで書き込みアクティビティを一時停止するメカニズムを実装する必要があります。

レプリケーション

共有ストレージソリューションと目標復旧時点に応じて、ファイルシステムを複製できます。レプリケーションは、データベース、ブロックレベルのストレージ、ファイルに実行できます。

データ損失に対する許容度が非常に低いビジネスクリティカルなアプリケーションには、レプリケーションを使用する DR ソリューションが最適です。

プライマリシステムが Google Cloud で実行されている場合は、選択したリージョン間でマルチリージョンバケットとマルチリージョンスナップショットが複製されます。

ブロックレベルのストレージレプリケーションには、PD 非同期レプリケーションを使用できます。PD 非同期レプリケーションにより、目標復旧時点（RPO）と目標復旧時間（RTO）を短縮した、クロスリージョンのアクティブ / パッシブな障害復旧での非同期レプリケーションが可能になります。

また、サードパーティのストレージソリューションで実現されるレプリケーションを使用することもできます。

ストレージ

Google Cloud で DR ソリューションを設計する場合、プライマリシステムが実行されている場所や保存する内容に応じて、複数のタイプのストレージを使用します。

バックアップファイルを格納する Cloud Storage バケット

Google Cloud で実行されていない SAP システムからアップロードするファイルなど、ディスクスナップショット以外のバックアップの場合は、プライマリサイトと DR サイトの両方からアクセスできるバケットを Cloud Storage に作成します。バケットを作成するときに、デフォルトのストレージクラスとロケーションを選択します。

必要なサービスレベル契約（SLA）、ストレージの予想使用量、費用的な制約に基づいて、デフォルトのストレージクラスを選択します。DR では、Coldline Storage クラスがよく使用されています。

バケットの場所に応じて、DR サイトのリージョンを含む場所を選択します。プライマリシステムが Google Cloud 上で実行されている場合は、プライマリサイトのリージョンを選択します。

プライマリシステムが Google Cloud にある場合は、プライマリサイトと DR サイトの両方のリージョンを含むマルチリージョンロケーションを選択して、両方のサイトからバケットにアクセスできるようにします。

プライマリシステムが Google Cloud にない場合、コストを削減するために、DR サイトを含むリージョン内のシングルリージョンロケーションを選択できます。

プライマリストレージが Google Cloud 上にあり、共有ストレージにサードパーティのソリューションを使用している場合、ストレージオプションはソリューションによって異なることがあります。ソリューションのドキュメントをご覧になるか、Cloud カスタマーケア担当者にお問い合わせください。

料金については、Cloud Storage の料金をご覧ください。

Compute Engine 永続ディスクスナップショットのストレージ

スナップショットを作成するときに、ストレージロケーションを指定できます。スナップショットのロケーションは、可用性に影響するとともに、スナップショットの作成または新しいディスクへの復元の際にネットワークコストを発生させる要因となる可能性があります。

スナップショットは、1 つの Cloud Storage マルチリージョンロケーション（asia など）、または 1 つの Cloud Storage リージョンロケーション（asia-south1 など）のいずれかに保存できます。

マルチリージョンのストレージロケーションを使用することにより、可用性を向上させ、スナップショットを作成または復元するときのネットワークコストを削減できます。リージョンのストレージロケーションを使用すると、データの物理的な位置をより細かく制御できます。

選択するロケーションに関係なく、スナップショットは DR サイトからアクセス可能な場所に保存する必要があります。

スナップショットのロケーションの詳細については、スナップショットのストレージロケーションの選択をご覧ください。

スナップショットストレージの料金については、永続ディスクの料金体系をご覧ください。

カスタムイメージのストレージ

カスタムイメージファイルをカスタムイメージリストに追加すると、Compute Engine はイメージのストレージを管理します。カスタムイメージリストのイメージはグローバルリソースで、どのリージョンでも使用できます。

イメージストレージの料金については、イメージストレージをご覧ください。

DR 計画のテスト

DR 計画を作成したら、定期的にテストを行い、発生する問題を確認し、それに応じて計画を調整する必要があります。

DR 計画のすべての側面をテストする必要があります。たとえば、次のような点をテストします。

バックアップとバックアップスケジュール
プラットフォーム外のサイトからのデータ転送
保存されたバックアップからの回復
セキュリティ制御とシステムアクセス
ネットワークルーティング

DR システムのテスト中、プライマリシステムは稼働したままになります。競合やスプリットブレインを避けるため、プライマリシステムとそのユーザーからテストシステムを隔離する必要があります。

Google Cloud での DR テストの一般的な情報については、障害復旧計画ガイドをご覧ください。

RPO と RTO を満たす DR ソリューションの設計

RPO と RTO を満たす DR ソリューションを設計するうえで、特定の Google Cloud プロダクト、機能、サービスが鍵となります。

RPO を満たす設計

Google Cloud で特定の RPO に対応する DR ソリューションを設計する場合、回復できる特定の時点を制御する 2 つの変数があります。

バックアップの頻度
バックアップの保持期間

バックアップの頻度

バックアップの頻度により、最後のバックアップから障害発生時までの最大経過時間が決まります。たとえば、24 時間ごとに DR バックアップを作成している場合、最後のバックアップが作成されてから 23 時間 59 分後に障害が発生すると、約 24 時間分のデータ更新が失われる可能性があります。

レプリケーションを使用すると、最後のバックアップからの最大経過時間がほぼゼロになりますが、レプリケーションはコストの高い処理のため、データベースとビジネスクリティカルなアプリケーションファイルにのみ使用するべきです。

DR ソリューションでは、復旧に必要な SAP アプリケーションファイルシステムをバックアップするため、特定の時点でコピーまたはスナップショットを作成するのが一般的です。

Google Cloud では、時間、日、週単位のスナップショットスケジュールを作成することで、Compute Engine の永続ディスクのスナップショットを自動化できます。ただし、Compute Engine スナップショットはブロックレベルでのみ整合性を制御するため、スナップショットの作成中はターゲットファイルシステムでの書き込みを一時停止し、ファイルレベルの整合性を確保する必要があります。

バックアップの頻度を決める際に重要になるのがデータ転送の費用です。ストレージの費用も重要ですが、バックアップの頻度よりもバックアップ保持ポリシーの方がストレージの費用に大きな影響を与える可能性があります。

スナップショットスケジュールの詳細については、永続ディスクのスナップショットスケジュールの作成をご覧ください。

バックアップの保持期間

バックアップの保持期間により、復旧時点を移動できる時間が決まります。バックアップコピーを保持することで、論理エラーが発生する前の時点まで復元できるので、論理エラーから保護できます。

Compute Engine スナップショットと Cloud Storage バケットの保持ポリシーを設定すると、指定時間の経過後にバックアップファイルを自動的に削除できます。

保持ポリシーを選択する際に重要になるのがストレージの費用です。Compute Engine スナップショットは、最初に完全なスナップショットが保存された後、以降はブロックレベルでの変更のみを保存します。これにより、複数のスナップショットで必要になるストレージの量が少なくなります。

スナップショット保持ポリシーの定義については、スナップショット保持ポリシーをご覧ください。

Cloud Storage バケットの保持ポリシーの設定方法については、バケットロックを使用した保持ポリシーをご覧ください。

RTO を満たす設計

特定の RTO を満たすように Google Cloud DR ソリューションを設計する場合、DR サイトのインフラストラクチャ、ソフトウェア、ファイルシステム、データの準備状況が主な制御変数になります。

たとえば、非常に低い RTO を実現する場合、事前に展開されたインフラストラクチャ、アクティブな SAP システム、複製されたデータを備えたホットスタンバイシステムを DR サイトで維持します。ただし、RTO を低く設定すると、コストが高くなります。

低コストまたは無料のインフラストラクチャを事前に設定し、いくつかの設定手順を復旧時間まで遅らせることで、費用と復旧時間のバランスを取ることができます。

たとえば、VM を構成してデプロイした後、VM をいったん停止します。外部の静的 IP や永続ディスクなど、VM に接続されているリソースは引き続き課金されることがありますが、停止した VM 自体には課金されません。

Compute Engine VM は Google Cloud 上に比較的短時間で構成してデプロイできるため、特に Terraform または Deployment Manager を使用して DR システムをデプロイするか、前もって作成したテンプレートやカスタムイメージから VM を作成する場合、RTO に対応しながら復旧時に構成とデプロイを行える可能性があります。

高 RTO DR ソリューションでの割り当てとリソースに関する考慮事項

インフラストラクチャとシステムを事前にデプロイしない場合は、DR サイトのリージョンのリソース割り当てを定期的にチェックし、DR システムのデプロイに十分な割り当てが残っていることを確認してください。

予算の許す限りの DR インフラストラクチャとシステムを事前にデプロイしてください。これにより、DR システムを割り当て内に収め、必要なときに必要な Google Cloud リソースを利用できるようになります。

目標の異なるアーキテクチャの例

次のアーキテクチャ図は、RTO が異なる DR の設計例を示しています。

各図では、左側にマルチリージョンバックアップオプションを示し、それに対応する DR サイトの SAP 簡易構成を右側に示しています。

それぞれの例は、DR 設計で可能な要素の組み合わせの 1 つを表しています。目標値と状況に合わせて DR の設計を調整する際に、これらの例の要素を適宜組み合わせることができます。

低 RTO の DR アーキテクチャの例

次のアーキテクチャ図は、低 RTO DR の設計例を示しています。

この設計では、すぐに機能する SAP システムが DR サイトで維持されています。VM はデプロイされ、アクティブな状態になっています。SAP アプリケーションサーバーとデータベースサーバーはアクティブですが、アプリケーションサービスは停止しています。

このシナリオで可能性が高いバックアップオプションは、Compute Engine に格納された OS イメージと永続ディスクスナップショット、プライマリサイトと DR サイト間のデータレプリケーションです。データレプリケーションには、PD 非同期レプリケーションを使用できます。

データレプリケーションを使用しているため、データ損失のリスクは最後のデータベース同期に限定されます。

RPO をさらに延ばすには、Cloud Storage にデータのバックアップを追加します（この図に Cloud Storage は示されていません）。永続ディスクスナップショットの場合、スケジュールを設定してスナップショットを取得し、RPO に合わせて保持ポリシーを調整できます。

この低 RTO システムを復旧するために必要なアクションは次のとおりです。

必要に応じて、ファイルの最終同期を実行するか、永続ディスクスナップショットからファイルを復旧します。
プライマリデータベースを DR サイトに切り替えます。
DR サイトでアプリケーションを開始します。

ここで示す 3 つのアーキテクチャの中で、低 RTO の例が最もコストの高いパターンになります。

RTO が最も低いオプション: DR サイトには、事前にデプロイされたアクティブ VM の SAP AS と SAP ASCS が含まれています。

中程度の RTO の DR アーキテクチャの例

次の DR アーキテクチャの例では、前の例よりも RTO が高くなっていますが、費用は少なくなっています。

この設計では、データベースサーバーはアクティブであり、プライマリサイトからのレプリケーションをサポートしています。アプリケーションサーバーの VM はアクティブではありません。

このシナリオで可能性の高いバックアップオプションは、Compute Engine に保存されている OS イメージと永続ディスクスナップショット、プライマリサイトと DR サイト間のデータレプリケーションです。データレプリケーションには、PD 非同期レプリケーションを使用できます。

データレプリケーションを使用しているため、データ損失のリスクは最後のデータベース同期に限定されます。

RPO をさらに延ばすには、Cloud Storage バケットにデータのバックアップを保存します（この図に Cloud Storage バケットは示されていません）。永続ディスクスナップショットの場合、スケジュールを設定してスナップショットを取得し、RPO に合わせて保持ポリシーを調整できます。

データベースシステムの要件によっては、プライマリサイトで必要なサイズよりも小さい DR サイトの VM にデータベースをデプロイできる場合があります。これにより、DR システムがアクティブになるまで費用を抑えることができます。この場合、復旧中に VM のサイズを必要なサイズに変更する必要があります。

このようなシステムを復旧するために必要なアクションは次のとおりです。

必要に応じて、永続ディスクのスナップショットまたはイメージから SAP NetWeaver とアプリケーションサーバーの VM インスタンスをデプロイします。
永続ディスクスナップショットまたは他のストレージからファイルシステムを同期します。
必要に応じて、データベース VM インスタンスのサイズを変更します。
プライマリデータベースを DR サイトに切り替えます。
DR サイトでアプリケーションサービスを開始します。

RTO が最も低いオプション: DR サイトには、事前にデプロイされた非アクティブ VM の SAP AS と SAP ASCS が含まれています。

高 RTO の DR アーキテクチャの例

次のアーキテクチャ図は、ここで示した例の中で RTO が最も高く、費用が最も低いオプションを示しています。

この設計では、サーバーを事前にデプロイしてから停止し、VM に対する課金を回避できます。また、復旧プロセスの中で VM をデプロイすることで、永続ディスクや他の VM 関連リソースの費用を抑えることができます。

このシナリオで可能性の高いバックアップオプションは、Compute Engine に格納された OS イメージと永続ディスクスナップショット、Cloud Storage に保存されたデータバックアップです。

RPO を満たすため、バックアップの頻度だけでなく、スナップショットスケジュールと Cloud Storage バケット内のバックアップの保持ポリシーも調整できます。