Backup and DR バックアップ/リカバリ アプライアンスのデプロイ方法に影響する重要な考慮事項は次のとおりです。
組織の目標復旧時間（RTO）の要件は何ですか？RTO は、データが利用できない状態が許容される最大時間です。たとえば、RTO が 4 時間の場合、障害発生から 4 時間以内にデータにアクセスできる必要があります。
バックアップ管理を一元化する必要がありますか？バックアップを一元管理するかどうかを決定する必要があります。
- バックアップの一元管理とは、単一のアプライアンス管理コンソールを使用して、すべてのビジネスラインのすべてのワークロードのバックアップを管理することを意味します。これにより、1 つのアプライアンス管理コンソールのみを管理すればよいため、バックアップをより効率的に管理できます。
- バックアップ管理の分散化とは、各ビジネス部門に個別のアプライアンス管理コンソールがあることを意味します。運用モードは組織によって異なります。
バックアップのユースケースは何ですか？本番環境リージョンで障害が発生した場合の障害復旧のためにリモート バックアップが必要ですか。それとも、ローカルでデータを保護するだけで十分ですか？障害復旧機能が必要な場合は、クロスリージョン バックアップを検討する必要があります。つまり、バックアップを複数の場所に保存することで、1 つの場所が災害の影響を受けても、データにアクセスできます。
ワークロードが単一のリージョンにある
リージョン内の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
パフォーマンスを最大化してコストを削減するには、ワークロードが実行されているリージョンと同じリージョンにアプライアンス管理コンソールとバックアップ/リカバリー アプライアンスをデプロイします。バックアップ イメージをワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、バックアップを別のリージョンに保存するか、デュアルリージョン ストレージまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
パフォーマンスを最大限に高め、コストを削減するには、アプライアンス管理コンソールを本番環境ワークロード リージョンと同じリージョンにデプロイし、2 つ目のアプライアンス管理コンソールを障害復旧に使用できるリージョンにデプロイします。
本番環境のワークロード リージョンと DR リージョンの両方にバックアップ/リカバリ アプライアンスをデプロイして、目標復旧時間（RTO）を最小限に抑えます。これにより、障害が発生した場合に DR 環境が完全に事前プロビジョニングされ、使用可能になります。
バックアップ イメージを本番環境リージョンに保存し、コピーを障害復旧 DR リージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。本番環境リージョンのバックアップ コピーは、高速なパフォーマンスで定期的なバックアップのニーズを満たすことができます。DR リージョンにコピーされたデータは、本番環境リージョンがダウンした場合にワークロードを復元するために使用できます。
ワークロードが複数のリージョンにある
リージョン間の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
パフォーマンスを最大化してコストを削減するには、ワークロードが実行されているリージョンのいずれかにアプライアンス管理コンソールをデプロイします。これにより、すべてのワークロードとリージョンにわたって一元管理が可能になります。
ワークロードが実行されている各リージョンに 1 つ以上のバックアップ/復元アプライアンスをデプロイします。バックアップはワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、バックアップを別のリージョンに保存するか、デュアルリージョン ストレージまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンまたはマルチリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
本番環境ワークロードの各リージョンにアプライアンス管理コンソールをデプロイし、DR リージョンに別のアプライアンス管理コンソールをデプロイします。
本番環境のワークロード リージョンと DR リージョンの両方にバックアップ/リカバリ アプライアンスをデプロイして、目標復旧時間（RTO）を最小限に抑えます。これにより、障害が発生した場合に DR 環境が完全に事前プロビジョニングされ、使用可能になります。
バックアップを本番環境ワークロード リージョンに保存し、コピーを DR リージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。本番環境リージョンのバックアップ コピーは、バックアップのニーズを満たすために使用できます。
本番環境リージョンがダウンした場合、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 内のサービス プロジェクトにインストールされます。これにより、単一のプロジェクト内でワークロードとバックアップ/リカバリ アプライアンスをコロケーションできます。
限定公開の 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への接続を許可します。