Backup and DR のバックアップ/リカバリ アプライアンスのデプロイ方法に影響する重要な考慮事項は次のとおりです。
組織の目標復旧時間（RTO）の要件は何ですか？ RTO は、データが使用できない状態が許容される最大時間です。たとえば、RTO が 4 時間の場合、障害発生から 4 時間以内にデータにアクセスできる必要があります。
バックアップ管理を一元化する必要がありますか？バックアップを一元管理するかどうかを決定する必要があります。
- バックアップ管理の一元化とは、1 つのアプライアンス管理コンソールで、すべての事業部門のすべてのワークロードのバックアップを管理することを意味します。 単一のアプライアンス管理コンソールを管理するだけで済むため、バックアップをより効率的に管理できます。
- バックアップ管理の分散化とは、事業部門ごとに個別の管理コンソールを使用することを意味します。運用モードは組織によって異なります。
バックアップのユースケースは何ですか？本番環境リージョンで障害が発生した場合に備えて、障害復旧用のリモート バックアップが必要ですか。それとも、データをローカルで保護するだけで十分ですか？障害復旧機能が必要な場合は、リージョン間のバックアップを検討する必要があります。つまり、バックアップを複数の場所に保存することで、1 つの場所が障害の影響を受けてもデータにアクセスできるようにします。
ワークロードが単一のリージョンにある
リージョン内の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
最高のパフォーマンスと低コストを実現するには、ワークロードが実行されているリージョンと同じリージョンにアプライアンス管理コンソールとバックアップ/リカバリ アプライアンスをデプロイします。バックアップ イメージは、ワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、別のリージョンにバックアップを保存するか、デュアルリージョンまたはマルチリージョンのストレージを使用します。 バックアップを別のリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
最高のパフォーマンスと低コストを実現するには、本番環境ワークロード リージョンと同じリージョンにアプライアンス管理コンソールをデプロイし、障害復旧に使用できるリージョンに 2 つ目のアプライアンス管理コンソールをデプロイします。
目標復旧時間（RTO）を最小限に抑えるため、本番環境ワークロード リージョンと DR リージョンの両方にバックアップ/リカバリ アプライアンスをデプロイします。これにより、障害発生時に DR 環境が完全にプロビジョニングされ、使用可能になります。
バックアップ イメージを本番環境リージョンに保存し、コピーを障害復旧 DR リージョンに保存するか、デュアルリージョンまたはマルチリージョンのストレージを使用します。本番環境リージョンのバックアップ コピーは、パフォーマンスが向上し、通常のバックアップのニーズを満たすことができます。DR リージョンにコピーされたデータは、本番環境リージョンがダウンした場合にワークロードを復元するために使用できます。
ワークロードが複数のリージョンにある
リージョン間の最適なバックアップ戦略は、ニーズによって異なります。
障害復旧（DR）が不要な場合
最高のパフォーマンスと低コストを実現するには、ワークロードが実行されているリージョンのいずれかにアプライアンス管理コンソールをデプロイします。これにより、すべてのワークロードとリージョンで一元管理が可能になります。
ワークロードが実行されている各リージョンに 1 つ以上のバックアップ/リカバリ アプライアンスをデプロイします。バックアップは、ワークロードと同じリージョンに保存します。
バックアップ コピーをオフサイトに保存する場合は、別のリージョンにバックアップを保存するか、デュアルリージョンまたはマルチリージョンのストレージを使用します。 バックアップを別のリージョンまたはマルチリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。
バックアップと DR の両方が必要な場合
本番環境ワークロード リージョンごとにアプライアンス管理コンソールをデプロイし、DR リージョンに別のアプライアンス管理コンソールをデプロイします。
目標復旧時間（RTO）を最小限に抑えるため、本番環境ワークロード リージョンと DR リージョンの両方にバックアップ/リカバリ アプライアンスをデプロイします。これにより、障害発生時に 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 部門の中央サービスとして扱われます。サービス プロビジョニングは中央バックアップ チームが管理します。そのため、すべてのバックアップ/リカバリ アプライアンスはホスト プロジェクトにプロビジョニングされ、中央管理者はすべてのバックアップ リソースを中央プロジェクトに統合できます。この方法には、バックアップ関連のリソースとその請求を単一のプロジェクトに統合できるというメリットがあります。
サービス プロジェクト: この戦略は、サービス プロジェクトが作成され、その管理が分散チームに委任される、より分散型のチームに適しています。このシナリオでは、ダウンストリーム サービス プロジェクトに VPC をプロビジョニングすることが効果的な手法です。バックアップ/リカバリ アプライアンスは、これらの VPC 内のサービス プロジェクトにインストールされます。これにより、単一のプロジェクト内でワークロードとバックアップ/リカバリ アプライアンスを併置できます。
プライベート Google アクセス: バックアップ/リカバリ アプライアンスをインストールするサブネットごとにプライベート Google アクセスを有効にすることをおすすめします。これにより、バックアップ/リカバリ アプライアンスは、Compute Engine、Cloud Storage、Cloud Logging などの API と通信できるようになります。これは、モニタリングとアラートが機能するために重要です。API への接続を簡素化して強化するには、構成オプションの概要セクションで説明されているように、
private.googleapis.comの DNS の解決を構成することを検討してください。 Google Cloud プライベート Google アクセスの場合、バックアップ/リカバリ アプライアンスから CIDR 範囲199.36.153.8/30の TCP ポート 443 への接続を許可するようにファイアウォール ルールを構成します。