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