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）を中心に説明します。
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 アーキテクチャの例
次の 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 アーキテクチャの例
次のアーキテクチャ図は、ここで示した例の中で RTO が最も高く、費用が最も低いオプションを示しています。
この設計では、サーバーを事前にデプロイしてから停止し、VM に対する課金を回避できます。また、復旧プロセスの中で VM をデプロイすることで、永続ディスクや他の VM 関連リソースの費用を抑えることができます。
このシナリオで可能性の高いバックアップ オプションは、Compute Engine に格納された OS イメージと永続ディスク スナップショット、Cloud Storage に保存されたデータ バックアップです。
RPO を満たすため、バックアップの頻度だけでなく、スナップショット スケジュールと Cloud Storage バケット内のバックアップの保持ポリシーも調整できます。
このようなシステムを復旧するために必要なアクションは次のとおりです。
- 必要に応じて、Compute Engine に保存されているマルチリージョンの永続ディスク スナップショットまたはイメージから SAP NetWeaver、アプリケーション サーバー、データベース サーバーの VM インスタンスをデプロイします。
- 永続ディスク スナップショットまたは他のストレージからファイル システムを同期します。
- マルチリージョンの Cloud Storage バケットまたは他の場所にあるバックアップ ファイルからデータベースを復旧します。
- プライマリ データベースを DR サイトに切り替えます。
- DR サイトでアプリケーション サービスを開始します。
Google Cloud 上の SAP 向け DR ソリューションのパートナーとプロダクト
Google Cloud Partner ディレクトリで、DR ソリューションをサポートするパートナーを見つけることができます。
Google Cloud Marketplace で DR ソリューションをサポートするさまざまなプロダクトやパートナーを見つけることもできます。