Backup and DR サービスのデプロイを設定、計画する

このページでは、バックアップと DR サービスの初期アクティベーションを実行し、プロジェクトの構成を設定する方法について説明します。

バックアップと DR のアーキテクチャのコンポーネント

バックアップと DR サービスのアーキテクチャは、次のコンポーネントによって提供されます。

  • 管理コンソール: 管理コンソールは、バックアップ/復元アプライアンスの管理プレーンとして機能します。各バックアップと DR のデプロイには、任意の数のバックアップ/リカバリ アプライアンスを管理する単一の管理コンソールがあります。管理コンソールはバックアップ管理プロジェクトにデプロイされ、デプロイされたリージョン内で高可用性を実現し、ゾーンの停止に対する復元力を備えています。

  • バックアップ/リカバリ アプライアンス: バックアップ/リカバリ アプライアンスは、企業内のバックアップ データのライフサイクルを効率的にキャプチャ、移動、管理するデータ移行ツールです。バックアップ/リカバリ アプライアンスは、クラウド ワークロードのワークロード エンティティにデプロイされます。

  • バックアップと DR エージェント: バックアップと DR エージェントは、アプリケーション固有の API を呼び出して、本番環境のアプリケーションから永続増分方式でデータを効率的にキャプチャし、復元時にアプリケーションの認識を提供します。エージェントは、保護するアプリケーションが存在するアプリケーション ホストにインストールされます。VM 全体またはディスクの一部のみを保護する場合は、バックアップと DR エージェントは必要ありません。

管理コンソールがサービス プロデューサー VPC ネットワークで有効になっています。このサービス プロデューサーの VPC は、Private Google Access を使用してプロジェクトと通信します。

実装に関する注意事項

バックアップと DR サービスのデプロイ方法に影響する重要な考慮事項は次のとおりです。

  • 組織の目標復旧時間（RTO）の要件は何ですか？RTO は、データを使用できない状態が許容される最大時間です。たとえば、RTO が 4 時間の場合、障害発生から 4 時間以内にデータにアクセスできる必要があります。

  • バックアップ管理を一元化する必要があるか？バックアップを一元管理するかどうかを決定する必要があります。

    • バックアップの一元管理とは、すべてのビジネスラインのすべてのワークロードのバックアップを 1 つの管理コンソールで管理することを意味します。管理コンソールを 1 つだけ管理する必要があるため、バックアップをより効率的に管理できます。
    • 分散バックアップ管理とは、ビジネスラインごとに個別の管理コンソールがあることを意味します。運用モードは組織によって異なります。

  • バックアップのユースケースは何ですか？本番環境リージョンで障害が発生した場合に障害復旧の準備のためにバックアップが必要ですか？それとも、ローカルでデータを保護するだけで十分ですか？障害復旧機能が必要な場合は、クロスリージョン バックアップを検討する必要があります。つまり、バックアップを複数のロケーションに保存して、1 つのロケーションが障害の影響を受けた場合でも、データにアクセスできるようにします。

ワークロードが単一のリージョンにある

リージョン内の最適なバックアップ戦略は、ニーズによって異なります。

障害復旧（DR）が不要な場合

パフォーマンスを最大限に高め、コストを削減するには、ワークロードが実行されているリージョンに管理コンソールとバックアップ/リカバリ アプライアンスをデプロイします。バックアップ イメージはワークロードと同じリージョンに保存します。

オフサイトにバックアップ コピーも配置する場合は、バックアップを別のリージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。バックアップを別のリージョンに保存すると、ネットワーク料金とストレージ料金が発生します。

バックアップと DR の両方が必要である場合

パフォーマンスを最大限に高め、費用を削減するには、本番環境ワークロード リージョンと同じリージョンに管理コンソールをデプロイし、障害復旧に使用できるリージョンに 2 つ目の管理コンソールをデプロイします。

本番環境ワークロード リージョンと DR リージョンの両方にバックアップ/リカバリ アプライアンスをデプロイして、復旧時間目標（RTO）を最小限に抑えます。これにより、DR 環境が完全に事前プロビジョニングされ、障害が発生した場合に使用できるようになります。

バックアップ イメージを本番環境リージョンに保存し、コピーを障害復旧 DR リージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。本番環境リージョンのバックアップ コピーは、高速なパフォーマンスで日常的なバックアップのニーズを満たすことができます。DR リージョンにコピーされたデータは、本番環境リージョンが停止した場合にワークロードを復元するために使用できます。

ワークロードが複数のリージョンにある

リージョン間で最適なバックアップ戦略は、ニーズによって異なります。

障害復旧（DR）が不要な場合

パフォーマンスを最大化し、費用を削減するには、ワークロードが実行されているリージョンのいずれかに管理コンソールをデプロイします。これにより、すべてのワークロードとリージョンで一元管理できます。

ワークロードが実行されている各リージョンに 1 つ以上のバックアップ/復元アプライアンスをデプロイします。バックアップはワークロードと同じリージョンに保存します。

オフサイトにバックアップ コピーも配置する場合は、バックアップを別のリージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。別のリージョンまたはマルチリージョンにバックアップを保存すると、ネットワーク料金とストレージ料金が発生します。

バックアップと DR の両方が必要である場合

本番環境ワークロード リージョンのそれぞれに管理コンソールをデプロイし、DR リージョンに別の管理コンソールをデプロイします。

本番環境ワークロード リージョンと DR リージョンの両方にバックアップ/リカバリ アプライアンスをデプロイして、復旧時間目標（RTO）を最小限に抑えます。これにより、DR 環境が完全に事前プロビジョニングされ、障害が発生した場合に使用できるようになります。

バックアップを本番環境ワークロード リージョンに保存し、コピーを DR リージョンに保存するか、デュアルリージョンまたはマルチリージョン ストレージを使用します。本番環境リージョンのバックアップ コピーを使用して、バックアップのニーズを満たすことができます。

DR のバックアップ イメージは、本番環境リージョンが停止した場合にワークロードを復元するために使用できます。

Google Cloud コンソールでバックアップと DR サービスを設定する

Google Cloud コンソールに移動して、Backup and DR Service API を有効にし、アカウントの権限を設定します。

Google Cloud のバックアップと DR を有効にする

バックアップ/リカバリ アプライアンスのタイプ

Backup and DR Service は、Compute Engine VM、VMware VM、データベース、ファイル システムなどのさまざまなワークロード用に最適化されたアプライアンス タイプを提供します。ニーズに最適なアプライアンス タイプを選択できます。ワークロードに最適なアプライアンス タイプを選択することが重要です。バックアップ/リカバリ アプライアンスがサービスに投入されると、アプライアンスは永続的に継続的に実行され、バックアップ、復元などのジョブをいつでも実行、再実行できる状態になります。

バックアップと DR サービスには、次のアプライアンス タイプがあります。

  • Compute Engine VM または SAP HANA データベースの標準: Persistent Disk を使用して Compute Engine インスタンスまたは SAP HANA データベースのみをバックアップする場合は、このオプションを選択します。デフォルトでは、このアプライアンスは、最小 Persistent Disk 容量が 10 GB の e2-standard-4 マシンタイプを追加します。このアプライアンスは、最大 5,000 個の Compute Engine VM を管理できます。
  • VMware VM とその他のデータベースまたはリソース向けの標準: データベース、VMware VM、その他のリソースのバックアップに最適なパフォーマンスをサポートする標準構成を使用する場合は、このオプションを選択します。デフォルトでは、このアプライアンスは n2-standard-16 マシンタイプを追加します。これにより、最小ディスク容量として 4 TB のバランスディスク容量が追加されます。このアプライアンスは最大 1,500 個のアプリケーションを管理できます。

  • VMware VM とその他のデータベースまたはリソース用の基本: データベース、VMware VM、その他のリソースのバックアップに中程度のパフォーマンスをサポートする基本構成を使用する場合は、このオプションを選択します。デフォルトでは、このアプライアンスは e2-standard-16 マシンタイプを追加します。このアプライアンスは最大 1,500 個のアプリケーションを管理できます。データを保存するディスクタイプは、次のいずれかを選択できます。

    • 最小容量の Persistent Disk: このオプションでは、最小ディスク容量が 10 GB になります。このストレージ タイプでは、バックアップは Persistent Disk スナップショットとして保存され、バックアップ/リカバリー アプライアンスのローカル ストレージを使用しません。
    • Standard Persistent Disk: 効率的なブロック ストレージが必要な場合は、このストレージ タイプを選択します。これは、Compute Engine VM のほか、I/O 負荷が中程度の Google Cloud VMware Engine VM、データベース、ファイル システム アプリケーションにおすすめです。これにより、最小ディスク容量として 4 TB の Persistent Disk 容量が追加されます。
    • SSD Persistent Disk: 高速なブロック ストレージが必要な場合は、このストレージ タイプを選択します。これは、Compute Engine VM のほか、I/O 負荷が非常に高い Google Cloud VMware Engine、データベース、ファイル システムのアプリケーションにおすすめします。これにより、最小ディスク容量として 4 TB の Persistent Disk 容量が追加されます。

アプライアンスをデプロイすると、アプライアンスのタイプに関係なくサービス アカウントが自動的に作成されます。サービス アカウントは、[サービス アカウント] ページで確認できます。

サービス アカウントの名前は、メールアドレス形式の my-service-account@my-project.iam.gserviceaccount.comで表示されます。ここで、appliance-name はアプライアンスの名前、projectid は Google Cloud プロジェクトの ID です。

ストレージの種類を選択する

バックアップ/リカバリ アプライアンスは、バックアップ データをローカル アプライアンス スナップショット プールに保存します。長期保存のためにオブジェクト ストレージにコピーできます。Google Cloud には、次の 3 種類のローカル オブジェクト ストレージがあります。

  • 最小容量の Persistent Disk: バックアップ イメージは Persistent Disk スナップショットとして保存され、バックアップ/リカバリー アプライアンスのローカル ストレージは使用されません。

  • Standard Persistent Disk: このストレージ タイプは、4 TB の Persistent Disk をはじめとする効率的なブロック ストレージを提供します。これは、I/O 負荷が中程度から高い VMware Engine や、データベースまたはファイル システムのアプリケーションにおすすめです。

  • SSD 永続ディスク: このストレージ タイプは、4 TB の永続ディスクから高速なブロック ストレージを提供します。これは、 Google CloudVMware Engine VM と、I/O 負荷が非常に高いデータベースまたはファイル システム アプリケーションにおすすめです。

ディスクプールの容量は後で拡張できます。

長期保存が必要なバックアップは、データへのアクセスの必要性に応じて、 Google Cloud Standard、Nearline、Coldline ストレージに移動できます。

バックアップと DR サービスに推奨されるネットワーク トポロジ

Google Cloud では、バックアップと DR サービスをデプロイする際に共有 VPC を使用することをおすすめします。共有 VPC を使用すると、組織は複数のプロジェクトから共通の VPC（VPC）ネットワークにリソースを接続できるため、そのネットワークの内部 IP を使用して、安全で効率的な相互通信を行うことができます。共有 VPC を使用する場合、プロジェクトをホスト プロジェクトとして指定し、他のサービス プロジェクトをホスト プロジェクトに接続します。ホスト プロジェクトの VPC ネットワークは、共有 VPC ネットワークといいます。サービス プロジェクトの適格リソースは、共有 VPC ネットワーク内のサブネットを使用できます。

組織管理者は共有 VPC を使用して、サブネット、ルート、ファイアウォールなどのネットワーク リソースを集中管理しながら、インスタンスの作成や管理などの管理責任をサービス プロジェクト管理者に委任できます。

管理コンソールは、サービス プロデューサーの VPC ネットワーク VPC で有効になります。このサービス プロデューサー VPC は、限定公開の Google アクセスを使用してプロジェクトと通信します。この接続の主な目的は、管理コンソールとバックアップ/リカバリ アプライアンスがメタデータを交換することです。バックアップ トラフィックは、このリンクを通過しません。ただし、管理コンソールは、任意のネットワークにデプロイされたすべてのバックアップ/リカバリ アプライアンスと通信する必要があります。

共有 VPC のベスト プラクティス

次のベスト プラクティスをおすすめします。

  • 管理コンソールに接続する: サービス プロバイダ ネットワークをネットワーク内の共有 VPC に接続することをおすすめします。管理コンソールからのすべてのトラフィックは、この VPC を経由してホスト プロジェクトを通過します。共有 VPC を介してバックアップと DR サービスへの接続をプロビジョニングすると、ワークロードが実行されているプロジェクト（サービス プロジェクト）とバックアップと 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 解決を構成することを検討してください。また、バックアップ/リカバリ アプライアンスからファイアウォール ルールを構成して、TCP ポート 443 の CIDR 範囲 199.36.153.8/30 への接続を許可します。

ファイアウォールの構成

バックアップ サービスと DR サービスへの上り（内向き）に必要な次のファイアウォール ルールが自動的に追加されます。

目的 ソース ターゲット ポート（TCP）
サポート トラフィック（アプライアンスへのサポート） SSH クライアントを実行しているホスト バックアップ / リカバリ アプライアンス 26
iSCSI バックアップ（ホストからアプライアンス） Backup and DR エージェントを実行しているホスト バックアップ / リカバリ アプライアンス 3260
StreamSnap トラフィック（アプライアンス間） バックアップ / リカバリ アプライアンス バックアップ / リカバリ アプライアンス 5107
バックアップ/リカバリ アプライアンスと管理コンソールの接続 バックアップ/リカバリ アプライアンスの IP またはサブネット *.backupdr.googleusercontent.com 443

このルールの構成方法の詳細については、Backup and DR サービスをデプロイする準備をご覧ください。

バックアップ エージェントと DR エージェントを実行しているホストの場合は、上り（内向き）ファイアウォール ルールによる接続を許可するために、次の TCP ポートを手動で追加する必要があります。

目的 ソース ターゲット ポート（TCP）
エージェント トラフィック（アプライアンスからホスト） バックアップ / リカバリ アプライアンス Backup and DR エージェントを実行しているホスト 5106

バックアップ トラフィックに NFS を使用するホスト、またはマウントに NFS を使用している VMware Engine で実行されている ESX ホストの場合は、上り（内向き）ファイアウォール ルールによる接続を許可するために、次の TCP ポートと UDP ポートを手動で追加する必要があります。

目的 ソース ターゲット ポート（TCP/UDP）
NFS バックアップまたはマウント エージェントを実行しているホストまたはマウントを実行している ESXi ホスト バックアップ / リカバリ アプライアンス 111、756、2049、4001、4045

このオペレーションで使用される権限の一覧については、バックアップと DR のインストール権限のリファレンスをご覧ください。

サポートされているリージョン

次のセクションでは、管理コンソールとバックアップ/リカバリ アプライアンスでサポートされているリージョンを示します。

管理コンソールでサポートされているリージョン

バックアップと DR サービスを使用して、Google Cloud の任意のリージョンでサポートされているワークロードをバックアップできますが、管理コンソールは次のリージョンでのみ有効にできます。管理コンソールを別のリージョンに移動することはできません。

地域 リージョン名 リージョンの説明
南北アメリカ
us-central1 アイオワ リーフアイコン 低 CO2
us-east1 サウスカロライナ
us-east4 北バージニア
us-west1 オレゴン リーフアイコン 低 CO2
us-west2 ロサンゼルス
us-west4 ラスベガス
southamerica-east1 サンパウロ リーフアイコン 低 CO2
ヨーロッパ
europe-west1 ベルギー リーフアイコン 低 CO2
europe-west2 ロンドン リーフアイコン 低 CO2
europe-west3 フランクフルト リーフアイコン 低 CO2
europe-west4 オランダ リーフアイコン 低 CO2
アジア太平洋
asia-east1 台湾
asia-southeast1 シンガポール
australia-southeast1 シドニー
インド
asia-south1 ムンバイ
asia-south2 デリー

バックアップ/リカバリ アプライアンスのサポートされているリージョン

バックアップと DR サービスのバックアップ/リカバリ アプライアンスは、Google Cloud ゾーンにデプロイできます。バックアップ/リカバリ アプライアンスのデプロイを実行するワークフロー サービスは、記載されているリージョンでサポートされています。バックアップ/リカバリ アプライアンスがデプロイされているリージョンで Workflow サービスを使用できない場合、バックアップと DR サービスはデフォルトで us-central1 リージョンでワークフローを実行します（アプライアンス自体は選択したリージョンに作成されます）。他のリージョンでリソースの作成を禁止するように設定されている組織のポリシーがある場合は、us-central1 リージョンでリソースの作成を許可するように組織のポリシーを一時的に更新する必要があります。バックアップ/リカバリ アプライアンスのデプロイ後に us-central1 リージョンを制限できます。

次のステップ