ボリューム レプリケーションについて

このページでは、ボリューム レプリケーションを使用してデータを保護する方法について説明します。

ボリューム レプリケーションについて

クロスロケーションのボリューム レプリケーションによってデータを保護できます。このレプリケーションでは、あるロケーションにあるソース ボリュームが別のロケーションにある宛先ボリュームに非同期で複製されます。この機能により、ロケーション全体のサービス停止や障害が発生した場合に、複製されたボリュームを重要なアプリケーション アクティビティに使用できるようになります。複製されたボリュームは、通常の使用時には読み取り専用のコピーとしても使用できます。

ボリューム レプリケーションでは、初期転送時に使用済みのデータブロックのみが移動され、増分転送時に変更されたブロックのみが転送されます。転送されるバイトに対してのみ課金されるため、転送時間が最適化され、コストが削減されます。

ボリューム レプリケーションのワークフロー

ボリューム レプリケーション中、初期転送と呼ばれるプロセスにより、すべてのソース ボリューム コンテンツが宛先ボリュームに複製されます。初期転送プロセスでは、ソースシステムでスナップショットを取得し、そのコンテンツを宛先ボリュームに転送します。初期転送が完了すると、レプリケーション ミラーのステータスが [Mirrored] に変わります。その結果、宛先ボリュームは読み取り専用になり、ソース ボリュームのスナップショットの内容が反映されます。これには、最初のスナップショットの前に取得されたすべてのスナップショットが含まれます。

初期転送プロセスが完了すると、スケジュール設定されたレプリケーション間隔は、次の順序で増分更新の形式で進行します。

1. このプロセスでは、ソース ボリュームに新しいスナップショットが作成されます。

2. 新しいスナップショットと以前のスナップショットの間で変更されたデータを計算します。

3. このプロセスでは、これらの変更が移行先ボリュームに転送されます。レプリケーション リソースの転送ステータスが [転送中] に変わります。

   すべての変更が転送されると、移行先ボリュームのコンテンツが古いスナップショットから新しいスナップショットに移行します。

設定の変更

レプリケーションがミラーリング状態である限り、ソース ボリュームまたは宛先ボリュームに適用された設定の変更は、両方のボリュームに自動的に適用されます。ただし、次の設定は送信元ボリュームと宛先ボリューム間で同期されません。

• ラベルとボリュームの説明: これらの設定は、ソースプールと宛先プールで個別に構成する必要があります。

• Active Directory ポリシー: このポリシーは移行元プールと移行先プールの両方に設定され、変更できません。

• CMEK ポリシー: このポリシーは移行元プールと移行先プールの両方に設定され、変更できません。

• バックアップ ポリシー: この設定は、移行元ボリュームと移行先ボリュームの両方で個別に構成する必要があります。

  レプリケーションが停止すると、レプリケーション先ボリュームのバックアップ スケジュールが有効になります。レプリケーションが ミラーリング状態の間は、バックアップ スケジュールは無効です。

• バックアップ Vault: この設定は、移行元と移行先のボリュームで個別に構成する必要があります。

• 自動階層化: この設定は、移行元ボリュームと移行先ボリュームで個別に構成する必要があります。

• スナップショット ディレクトリを表示する: この設定は、ソース ボリュームと宛先ボリュームで個別に構成する必要があります。

• Unix 権限: この API パラメータは、ルート inode の初期 UNIX 権限を定義します。これは、レプリケーション プロセス中に宛先ボリュームに複製されます。

• ボリュームの削除をブロックする: この設定は、移行元ボリュームと移行先ボリュームで個別に構成する必要があります。

• 手動 QoS と自動 QoS: この設定は、送信元プールと宛先プールのタイプに応じて、手動または自動で構成できます。自動 QoS プールのボリュームの場合、スループットはサイズとサービスレベルによって設定されます。ただし、手動 QoS プール内のボリュームのスループットは、ソース ボリュームと宛先ボリュームで個別に構成できます。

ソース ボリュームのサービスレベルが別のプールに移動することで変更されても、宛先ボリュームは変更されません。

レプリケーションが停止すると、ソース ボリュームと宛先ボリュームは独立します。移行元または移行先のボリュームに加えたデータや設定の変更は、もう一方のボリュームには適用されません。停止したレプリケーションを再開すると、このセクションに記載されている例外を除き、ソース ボリュームの設定によって宛先ボリュームの設定が上書きされます。

ボリューム レプリケーションに関する考慮事項

ボリューム レプリケーションを実行する前に、次の点を考慮してください。

• Standard、Premium、Extreme のサービスレベルの場合、NetApp Volumes は次の特定のリージョンペア間のボリューム レプリケーションをサポートしています。

  • asia-southeast1 と australia-southeast1

  • europe-west2 と europe-west3

  • europe-west2 と europe-west4

  • europe-west3 と europe-west4

  • europe-west3 と europe-west6

  • europe-west4 と europe-west6

  • europe-southwest1 と europe-west3

  • northamerica-northeast1 と northamerica-northeast2

  • northamerica-northeast1 と us-central1

  • australia-southeast1 と asia-southeast1

  • us-central1 と us-east4

  • us-central1 と us-west2

  • us-central1 と us-west3

  • us-central1 と us-west4

  • us-east4 と us-west2

  • us-east4 と us-west4

  • us-west2 と us-west4

  • us-west3 と us-west4

• Flex Unified サービスレベルの場合、ボリューム レプリケーションは同じリージョングループ内のゾーン間でサポートされています。同じリージョン内の別のゾーンへのレプリケーションもサポートされています。次の表に、さまざまなロケーションのリージョン グループを示します。

  	ロケーション
  	南北アメリカ	アジア太平洋	ヨーロッパ、中東、アフリカ
  リージョン グループ	southamerica-east1 us-central1 us-east1 us-east4 us-west1 us-west4	asia-northeast1 asia-northeast2 asia-south1 asia-southeast1 australia-southeast1	europe-west1 europe-west3 europe-west4 me-west1

• Flex ファイル サービスレベルの場合、ボリューム レプリケーションは同じリージョングループに属するリージョン間でサポートされています。次の表に、さまざまなロケーションのリージョン グループを示します。

  	ロケーション
  	南北アメリカ	アジア太平洋	ヨーロッパ、中東、アフリカ
  リージョン グループ	southamerica-east1 southamerica-west1 northamerica-northeast1 northamerica-northeast2 us-central1 us-east1 us-east4 us-east5 us-south1 us-west1 us-west2 us-west3 us-west4	asia-east1 asia-east2 asia-northeast1 asia-northeast2 asia-northeast3 asia-south1 asia-south2 asia-southeast1 asia-southeast2 australia-southeast1 australia-southeast2	africa-south1 europe-central2 europe-north1 europe-southwest1 europe-west1 europe-west2 europe-west3 europe-west4 europe-west6 europe-west8 europe-west9 europe-west10 europe-west12 me-central1 me-central2 me-west1

• 割り当ての割り当て: プロジェクトのレプリケーション要件によっては、特定のリージョンまたはサービスレベルでレプリケートされたソース ボリュームと宛先ボリュームの数の割り当てを増やす必要がある場合があります。割り当ての増加をリクエストするには、Google Cloud コンソールの NetApp Volumes の割り当てページを使用します。

• トポロジのサポート: ボリューム レプリケーションは、カスケード トポロジとファンイン / アウト トポロジをサポートしていません。たとえば、ボリュームを移行元ボリュームと移行先ボリュームの両方にすることはできません。

• 移行元と移行先のボリュームのロケーション:

  • Flex Unified Default-mode サービスレベルの場合、次の考慮事項が適用されます。

    • 移行元と移行先の両方のボリュームは、同じプロジェクトとリージョン グループに存在する必要があります。ボリュームを同じリージョン内の別のゾーンに複製できます。

    • 通常の Flex 統合プール内または大容量の Flex 統合プール内のボリュームを複製できますが、これらの 2 つのプールタイプ間で複製することはできません。

    • 同じプロジェクト内でボリュームを複製できます。

    • ソース ボリュームと宛先ボリューム間のプロジェクト間のボリューム レプリケーションは、リクエストに応じて利用できる機能です。この機能へのアクセスをリクエストするには、セールスにお問い合わせください。レプリケーションは API、Google Cloud CLI、または Terraform を使用して作成しますが、 Google Cloud コンソールで管理できます。クロス プロジェクト レプリケーションを作成するには、両方のプロジェクトに対する netapp.replications.create 権限が必要です。標準のボリューム レプリケーションとは異なり、プロジェクト間のレプリケーションでは、ソース ボリュームと宛先ボリューム間でエクスポート ルールが複製されません。

  • Flex File サービスレベルの場合: ソース ボリュームと宛先ボリュームの両方が同じプロジェクトとリージョン グループに存在する必要があります。同じリージョン内の別のゾーンへのレプリケーションはサポートされていません。

  • Standard、Premium、Extreme のサービスレベルの場合、次の考慮事項が適用されます。

    • 移行元と移行先の両方のボリュームが同じプロジェクト内にある場合、レプリケーションがサポートされます。宛先ボリュームは、別のリージョン ペアに存在する必要があります。

    • ソース ボリュームと宛先ボリューム間のプロジェクト間のボリューム レプリケーションは、リクエストに応じて利用できる機能です。この機能へのアクセスをリクエストするには、セールスにお問い合わせください。これらのレプリケーションは API、Google Cloud CLI、または Terraform のみを使用して作成されますが、その後の管理は Google Cloud コンソールを使用して行うことができます。プロジェクト間のレプリケーションを作成するには、両方のプロジェクトに対する netapp.replications.create 権限が必要です。一般的なボリューム レプリケーションとは異なり、プロジェクト間のレプリケーションでは、ソースと宛先の間でエクスポート ルールが複製されません。

  • ソース ボリュームと宛先ボリュームは、異なる VPC に存在できます。

• サービスレベルに基づくサポート: レプリケーション元とレプリケーション先のボリュームは、同じサービスレベルである必要があります。ただし、Premium と Extreme のサービスレベルのボリュームは、レプリケーションで混在させることができます。Flex Unified ONTAP モードとの間でレプリケーションを行うには、ONTAP でレプリケーションを行うをご覧ください。ここで、ONTAP モードのプールは ONTAP システムです。ONTAP モードのシステムまたは ONTAP ベースのシステムと ONTAP モード間のレプリケーションは、標準の ONTAP SnapMirror レプリケーションです。これに応じて管理する必要があります。詳細については、ONTAP SnapMirror 非同期障害復旧についてをご覧ください。

ボリューム レプリケーションの料金

NetApp Volumes では、レプリケーションの料金はボリューム容量とは別に請求されます。料金は、プライマリ ボリュームとセカンダリ ボリューム間で転送されたバイト数に基づいて計算されます。詳細については、NetApp Volumes の料金をご覧ください。

目標復旧時点（RPO）

ボリューム レプリケーションはスケジュールされた非同期レプリケーションであるため、宛先ボリュームの内容は常にソース ボリュームより遅れます。目標復旧時点（RPO）は、宛先ボリュームのデータの最新度と、保存されるデータの特定の時点のバージョンを指定します。障害が発生した場合、RPO を使用して失われたデータの量を特定できます。

ボリューム レプリケーションの RPO は、遅延時間またはレプリケーション スナップショットを確認することで判断できます。遅延時間は RPO をすばやく推定する方法ですが、レプリケーション スナップショットの方がより正確な測定方法です。

• 遅延時間: 宛先ボリュームに最後に複製されたソースボリュームのスナップショットが作成されてからの経過時間。タイムラグは、ソース ボリューム データに対する宛先ボリューム データの経過時間の差を表します。5 分ごとに更新され、RPO の概要が提供されます。レプリケーションでレプリケーション間隔がスキップされている場合は、 Google Cloud コンソールのラグタイムの横に警告アイコンが表示されます。この状態が続く場合は、移行元ボリュームのデータ変更率が高すぎて、レプリケーション間隔内に転送できません。ソースでの大量のデータ変更アクティビティなどの一回限りの状況では、レプリケーション間隔を長くするか、警告を無視することをおすすめします。

• レプリケーション スナップショット: レプリケーション スナップショットは、特定の時点でのデータがそのままキャプチャされたものです。レプリケーション スナップショットは、RPO を最も正確に把握できます。ボリューム レプリケーションでは、レプリケーションに 2 つのローリング スナップショットを使用します。宛先ボリュームの最新のレプリケーション スナップショットのタイムスタンプは、宛先ボリュームの最新のデータの特定の時点（UTC）を指定します。

  タイムスタンプ（replication-<timestamp>）は、UTC 形式（YYYY-MM-DD-HHMMSS）に従うレプリケーション スナップショット名から取得できます。

ストレージ プールの要件

移行元と移行先のボリュームを含むストレージ プールは、次の要件を満たしている必要があります。

• サービスレベルに応じて、有効なロケーション ペアまたはリージョン グループの一部である必要があります

• 同じ Active Directory ポリシー構成である必要があります

• 同じ Active Directory を指している必要がある

• 同じ LDAP 設定が必要

レプリケーションのスケジュール

レプリケーション スケジュールは、指定された間隔でレプリケーションを実行しようとします。以前のレプリケーションが進行中の場合、現在のサイクルのレプリケーションはスキップされ、次の間隔で再度チェックされます。この動作は、最初のレプリケーションで最も一般的です。最初のレプリケーションでは、最初のボリューム ブロックが転送され、レプリケーションに最も時間がかかります。レプリケーション スケジュールは、スケジュール タイプごとに次の時間に基づいて実行されます。

レプリケーション スケジュールの頻度	スケジュールされたオペレーションの時刻
10 分おき	:00, :10, :20, :30, :40, :50
毎時	:05（毎正時後）
毎日	毎日午前 :10 以降

次のステップ

ボリューム レプリケーションを作成する。