Backup and DR のバックアップ / リカバリ アプライアンスのデプロイ方法に影響する重要な考慮事項は次のとおりです。
組織の目標復旧時間（RTO）の要件は何ですか？RTO は、データがなくても許容できる最大時間です。たとえば、RTO が 4 時間の場合、障害発生から 4 時間以内にデータにアクセスできる必要があります。
バックアップ管理を一元化する必要があるか。バックアップを一元管理するかどうかを決定する必要があります。
- バックアップ管理の一元化とは、単一のアプライアンス管理コンソールを使用して、すべての事業部門のすべてのワークロードのバックアップを管理することを意味します。1 つのアプライアンス管理コンソールを管理するだけでよいため、バックアップをより効率的に管理できます。
- 分散型のバックアップ管理では、事業部門ごとに個別のアプライアンス管理コンソールを使用します。運用モードは組織によって異なります。
バックアップのユースケースは何ですか？本番環境リージョンで障害が発生した場合に備えて、障害復旧用のリモート バックアップが必要ですか？それとも、データをローカルで保護するだけで十分ですか？障害復旧機能が必要な場合は、クロスリージョン バックアップを検討する必要があります。つまり、バックアップを複数の場所に保存することで、1 つの場所が災害の影響を受けても、データにアクセスできるようにします。
ワークロードが単一のリージョンに存在している
リージョン内の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
パフォーマンスを最大化し、コストを削減するには、ワークロードが実行されているリージョンにアプライアンス管理コンソールとバックアップ / リカバリ アプライアンスをデプロイします。バックアップ イメージをワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、バックアップを別のリージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
パフォーマンスを最大限に高め、コストを削減するには、本番環境のワークロード リージョンと同じリージョンにアプライアンス管理コンソールをデプロイし、障害復旧に使用できるリージョンに 2 つ目のアプライアンス管理コンソールをデプロイします。
目標復旧時間（RTO）を最小限に抑えるため、本番環境のワークロード リージョンと DR リージョンの両方にバックアップ / リカバリ アプライアンスをデプロイします。これにより、DR 環境が完全に事前プロビジョニングされ、障害が発生した場合に利用できるようになります。
バックアップ イメージを本番環境リージョンに保存し、コピーを障害復旧 DR リージョンに保存するか、デュアルリージョンまたは Multi-Regional Storage を使用します。本番環境リージョンのバックアップ コピーは、より高速なパフォーマンスで日常的なバックアップのニーズを満たすことができます。DR リージョンにコピーされたデータは、本番環境リージョンがダウンした場合にワークロードを復元するために使用できます。
ワークロードが複数のリージョンにある
リージョンをまたぐ最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
パフォーマンスを最大化してコストを削減するには、ワークロードが実行されているリージョンのいずれかにアプライアンス管理コンソールをデプロイします。これにより、すべてのワークロードとリージョンを一元管理できます。
ワークロードが実行されている各リージョンに 1 つ以上のバックアップ / 復元アプライアンスをデプロイします。バックアップをワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、バックアップを別のリージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンまたはマルチリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
本番環境のワークロード リージョンごとにアプライアンス管理コンソールをデプロイし、DR リージョンに別のアプライアンス管理コンソールをデプロイする。
本番環境のワークロード リージョンと DR リージョンの両方にバックアップ / リカバリ アプライアンスをデプロイして、目標復旧時間（RTO）を最小限に抑えます。これにより、DR 環境が完全に事前プロビジョニングされ、障害が発生した場合に利用できるようになります。
バックアップを本番環境ワークロード リージョンに保存し、コピーを DR リージョンに保存するか、デュアルリージョンまたは Multi-Regional Storage を使用します。本番環境リージョンのバックアップ コピーは、バックアップのニーズを満たすために使用できます。
本番環境リージョンが停止した場合、DR のバックアップ イメージを使用してワークロードを復元できます。
Backup and DR に推奨されるネットワーク トポロジ
Google Cloud では、Backup and DR のデプロイ時に共有 VPC を使用することをおすすめします。共有 VPC を使用すると、組織は複数のプロジェクトから共通の VPC（VPC）ネットワークにリソースを接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC を使用する場合、プロジェクトをホスト プロジェクトとして指定し、他のサービス プロジェクトをホスト プロジェクトに接続します。ホスト プロジェクトの VPC ネットワークは、共有 VPC ネットワークといいます。サービス プロジェクトの適格リソースは、共有 VPC ネットワーク内のサブネットを使用できます。
組織管理者は共有 VPC を使用して、サブネット、ルート、ファイアウォールなどのネットワーク リソースを集中管理しながら、インスタンスの作成や管理などの管理責任をサービス プロジェクト管理者に委任できます。
アプライアンス管理コンソールは、サービス プロデューサー VPC ネットワーク VPC で有効になります。このサービス プロデューサー VPC は、プライベート Google アクセスを使用してプロジェクトと通信します。この接続の主な目的は、アプライアンス管理コンソールとバックアップ / 復元アプライアンスがメタデータを交換することです。バックアップ トラフィックはこのリンクを通過しません。ただし、アプライアンス管理コンソールは、任意のネットワークにデプロイされたすべてのバックアップ / リカバリ アプライアンスと通信する必要があります。
共有 VPC のベスト プラクティス
ここで推奨事項を紹介します。
アプライアンス管理コンソールへの接続: サービス プロバイダ ネットワークをネットワーク内の共有 VPC に接続することをおすすめします。アプライアンス管理コンソールからのすべてのトラフィックは、この VPC を経由してホスト プロジェクトを通過します。共有 VPC を介して Backup and DR への接続をプロビジョニングすると、ワークロードが実行されているプロジェクト（サービス プロジェクト）と Backup and DR の間のシームレスな接続も可能になります。
バックアップ / リカバリ アプライアンスの場所: バックアップ / リカバリ アプライアンスは、アプライアンス管理コンソールへの接続のために限定公開の Google アクセスが有効になっているサブネットにデプロイする必要があります。バックアップ / リカバリ アプライアンスのプロジェクトを選択するには、次の 2 つの戦略をおすすめします。
中央ホスト プロジェクト: この戦略では、Backup and DR は IT の中央サービスとして扱われます。中央のバックアップ チームがサービスのプロビジョニングを管理します。そのため、すべてのバックアップ / 復元アプライアンスがホスト プロジェクトにプロビジョニングされ、中央管理者はすべてのバックアップ リソースを中央プロジェクトに統合できます。このアプローチには、バックアップ関連のすべてのリソースとその課金を 1 つのプロジェクトに統合できるというメリットがあります。
サービス プロジェクト内: この戦略は、サービス プロジェクトが作成され、その管理が分散チームに委任される、より分散されたチームに適しています。このシナリオでは、ダウンストリーム サービス プロジェクトに VPC をプロビジョニングすることをおすすめします。バックアップ / リカバリ アプライアンスは、これらの VPC 内のサービス プロジェクトにインストールされます。これにより、ワークロードとバックアップ / リカバリ アプライアンスを 1 つのプロジェクト内に配置できます。
プライベート Google アクセス: バックアップ / リカバリ アプライアンスをインストールするサブネットごとにプライベート Google アクセスを有効にすることをおすすめします。これにより、バックアップ / リカバリ アプライアンスは、Compute Engine、Cloud Storage、Cloud Logging などの API と通信できます。これは、モニタリングとアラートを機能させるために重要です。 Google Cloud API への接続を簡素化して強化するには、構成オプションの概要セクションの説明に沿って、
private.googleapis.comの DNS 解決を構成することを検討してください。プライベート Google アクセスの場合は、バックアップ / リカバリ アプライアンスから TCP ポート 443 で CIDR の範囲199.36.153.8/30への接続を許可するようにファイアウォール ルールを構成します。