このページでは、外部レプリケーション機能の概要について説明します。
外部レプリケーションについて
外部レプリケーションでは、SnapMirror を使用して、ONTAP ベースのシステムから Google Cloud NetApp Volumes にデータを複製します。この機能は、ボリューム レプリケーションと同じオペレーション（作成、停止、再開、反転、削除など）をサポートしています。これにより、NetApp Volumes 内のボリューム間でレプリケーションを行うことができます。
外部レプリケーションでは、ボリューム移行と同じ SnapMirror テクノロジーを使用し、ベースライン転送と増分転送、認証用のクラスタ ピアリングなどの共通機能が共有されます。
次の表に、ボリューム移行と外部レプリケーションの主な違いを示します。
| ボリュームの移行 | 外部レプリケーション |
|---|---|
| ONTAP から NetApp Volumes への一方向の移行を期間限定で行うように設計されています。 | レプリケーションの方向を逆にできる障害復旧用の継続的なレプリケーション ソリューションとして設計されています。 |
考慮事項
外部レプリケーションは、API と Google Cloud CLI でのみ使用できます。 Google Cloud コンソールでは使用できません。
外部レプリケーションの前提条件
外部レプリケーションとボリューム移行には同じ前提条件が適用されます。
外部レプリケーション ワークフローの概要
外部レプリケーションはボリューム レプリケーションと同様に機能しますが、初期ソース システムは NetApp Volumes ボリュームではなく、外部 ONTAP システムのボリュームです。
ボリューム レプリケーションと同様に、外部レプリケーションもベースライン レプリケーションや増分レプリケーションなどのさまざまなフェーズを経ます。作成、停止、再開、削除、レプリケーション方向の反転などのオペレーションをサポートしています。
すべてのアクションは NetApp Volumes から開始できますが、一部のアクションでは、ユーザーが外部 ONTAP システムで ONTAP CLI コマンドを実行する必要があります。外部レプリケーションでは、クラスタ ピアリングの確立に必要なプロセスであるボリューム移行と同じ認証メカニズムが外部 ONTAP システムで使用されます。
外部レプリケーション ワークフローは、次のフェーズで構成されます。
認証
認証フェーズでは、移行元 ONTAP システムのストレージ管理者が、移行元システムからボリュームを取得する権限を NetApp Volumes に付与する必要があります。これは、ソース ONTAP システムでの管理手順（クラスタ ピアリングと SVM ピアリング）によって実現されます。外部レプリケーション プロセスでは、管理者がソースシステムで実行する必要がある ONTAP コマンドが生成されます。
ベースライン移行
レプリケーションを設定すると、スナップショットによってソース システムに整合性ポイントが作成されます。このスナップショットからキャプチャされたすべてのデータ（古いスナップショットを含む）は、ベースライン転送と呼ばれる初期フェーズで NetApp Volumes に転送されます。
ベースライン転送には、数分、数時間、数日、数週間かかることがあります。この期間は、次の要素によって異なります。
スナップショット内のデータの量。
ONTAP ソースシステムと NetApp Volumes 間のネットワーク速度。
NetApp Volumes のスループット設定。
ベースライン転送中、移行元ボリュームはワークロードの処理を継続し、クライアントによってデータの追加、変更、削除が行われます。これらの変更は、ベースラインの整合性ポイントに使用されるスナップショットには影響しません。ベースラインの進行中は、宛先ボリュームをクライアントで使用できません。ベースラインが完了すると、宛先ボリュームがオンラインになり、読み取り専用モードでクライアント アクセスに使用できるようになります。移行先のボリュームには別の IP アドレスが割り当てられます。
ボリューム レプリケーションとは異なり、外部レプリケーションでは、サイズ、プロトコルの選択、エクスポートまたはスナップショット ポリシーなどのソース ボリューム パラメータを読み取ることができません。したがって、宛先ボリュームに対してこれらの設定を正しく構成する必要があります。
クライアントは、移行先ボリュームをマッピングまたはマウントできますが、読み取り専用オペレーションのみです。
増分転送
ベースライン転送が完了すると、レプリケーションはスケジュール設定された間隔に基づいて増分転送をトリガーします。
増分転送では、次の処理が行われます。
ソース ボリュームの新しいスナップショットを取得します。
現在のスナップショットと前のスナップショットの間のデータ変更を計算します。
これらの変更の移行先への転送を開始します。
増分転送ごとに、新しいソース スナップショットが作成され、最も古い SnapMirror スナップショットが削除され、変更が計算されて転送されます。次のスケジュールされた転送の実行時に転送がまだ実行中の場合、新しい転送はスキップされます。この問題は、次の要因により、指定された間隔内で転送できるデータ量の変化を超えた場合に発生することがあります。
指定されたレプリケーション間隔が短すぎます。
ONTAP システムと NetApp Volumes 間のネットワーク帯域幅が制限されている。
移行元システムの変更率が高い。
スキップされた転送は、目標復旧時点（RPO）に悪影響を及ぼします。レプリケーションの遅延時間をモニタリングすることをおすすめします。ラグがレプリケーション間隔の 2 倍に頻繁に達する場合は、ネットワーク帯域幅の増加やレプリケーション間隔の延長などの対策を講じる必要がある場合があります。
宛先ボリュームをマウントするクライアントには、静的コンテンツを含む読み取り専用ビューが表示されます。ただし、増分転送が完了すると、ボリュームの内容は、以前のレプリケーション スナップショットから最新のレプリケーション スナップショットに、単一のアトミック オペレーションで即座に更新されます。
複数の外部レプリケーションを並行して実行する
外部レプリケーションとボリューム移行は、共通のプロジェクト割り当てを共有します。複数の外部レプリケーションとボリューム移行を並行して実行するには、十分な高い割り当てをリクエストする必要があります。