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

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

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

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

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

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

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

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

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

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

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

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

設定の変更

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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-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 サービスレベルの場合、ボリューム レプリケーションは同じリージョングループに属するリージョン間でサポートされます。次の表に、さまざまなロケーションのリージョン グループを示します。

  	ロケーション
  	南北アメリカ	アジア太平洋	ヨーロッパ、中東、アフリカ
  リージョン グループ	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 サービスレベルの場合: ソース ボリュームと宛先ボリュームの両方が、同じプロジェクトとリージョン グループに存在する必要があります。ただし、異なる VPC に存在することは可能です。

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

    • 同じプロジェクトに存在する移行元ボリュームと移行先ボリュームの両方が完全にサポートされています。

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

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

• サービスレベル ベースのサポート: レプリケーション元とレプリケーション先のボリュームは、同じサービスレベルである必要があります。ただし、Premium と Extreme のサービスレベルのボリュームは、レプリケーションで混在させることができます。

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

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 以降

次のステップ

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