このページでは、ボリューム移行機能の概要について説明します。
ボリューム移行について
ボリューム移行機能を使用すると、SnapMirror ベースの移行を使用して、ONTAP ベースのソースから Google Cloud NetApp Volumes にボリュームを移行できます。SnapMirror はボリューム単位で動作し、ソースボリュームを別のシステムの宛先ボリュームに複製できます。
SnapMirror には、従来のデータコピー方法に比べて多くの利点があります。
あらゆる IP ネットワーク上で動作し、ネットワークの問題に強く、幅広いネットワーク速度とレイテンシをサポートします。
使用されているデータのみをコピーします。
最初のベースライン データ転送の後、以降の転送は増分転送となり、変更されたデータのみが無期限にコピーされます。増分転送の変更の計算は非常に高速で、ボリュームに保存されているデータ型に依存しません。
転送ではストレージ効率が維持されます。ソースボリュームに重複排除または圧縮されたデータが含まれている場合、これらの効率が引き継がれ、転送するデータ量が削減されます。
すべての転送は転送中に暗号化されます。
パフォーマンスに目立った影響を与えることなく、ソースボリュームを使用できます。
ベースライン転送が完了したら、宛先ボリュームを読み取り専用状態で使用できます。
複雑なアクセス制御リスト（ACL）やロックされたファイルなどのメタデータを含むすべてのデータが転送されます。
SnapMirror は、異なる地理的ロケーション間でも、ONTAP システム間でボリュームを転送します。
Google Cloud NetApp Volumes は、異なる Google リージョンの NetApp Volumes 間のボリューム レプリケーションに SnapMirror を使用します。また、SnapMirror を使用して、外部の ONTAP ベースのボリュームと NetApp Volumes 間で複製することもできます。これはハイブリッド レプリケーションと呼ばれます。
ハイブリッド レプリケーションには次の 2 種類があります。
ボリューム移行は、ONTAP から NetApp Volumes への 1 回限りの転送を目的としています。
外部レプリケーション は、レプリケーションの方向を反転できる継続的な障害復旧レプリケーションを目的としています。
移行プロセスの概要
ハイブリッド レプリケーションにより、本番環境への影響を最小限に抑えながら、ソースから宛先への高速で一貫性のある完全なデータ移行が実現します。このプロセスは次のフェーズで構成されます。
認証
認証フェーズでは、ソース ONTAP システムのストレージ管理者は、ソースシステムからボリュームを取得する権限を NetApp Volumes に付与する必要があります。これは、 ソース ONTAP システムでの管理手順（クラスタ ピアリングと SVM ピアリング）によって実現されます。ボリューム移行プロセスでは、管理者がソースシステムで実行する必要がある ONTAP コマンドが生成されます。
ベースライン転送
移行を設定すると、スナップショットによってソースシステムに整合性ポイントが作成されます。このスナップショットからキャプチャされたすべてのデータ（古いスナップショットを含む）は、ベースライン転送と呼ばれる初期フェーズで NetApp Volumes に転送されます。
ベースライン転送には、数分、数時間、数日、数週間かかることがあります。この期間は、次の要因によって異なります。
スナップショット内のデータ量。
ONTAP ソースシステムと NetApp Volumes 間のネットワーク速度。
NetApp Volumes のスループット設定。
ベースライン転送中も、ソースボリュームはワークロードの処理を継続し、データの追加、変更、削除が行われます。これらの変更は、ベースラインの整合性ポイントに使用されるスナップショットには影響しません。ベースラインの処理中は、宛先ボリュームをクライアントで使用できません。ベースラインが完了すると、宛先ボリュームがオンラインになり、読み取り専用モードでクライアント アクセスに使用できるようになります。宛先ボリュームの IP アドレスは異なります。
ボリューム レプリケーションとは異なり、ボリューム移行では、サイズ、プロトコルの選択、エクスポート ポリシー、スナップショット ポリシーなどのソースボリューム パラメータを読み取ることができません。 そのため、宛先ボリュームに対してこれらの設定を正しく構成する必要があります。
移行の終了に備えて、宛先ボリュームを VM にマウントまたはマッピングできるようになりました。
増分転送
ベースライン転送が完了すると、移行によって 1 時間ごとの増分転送がトリガーされます。
増分転送では、次のアクションが実行されます。
ソースボリュームの新しいスナップショットを取得します。
現在のスナップショットと前のスナップショットの間のデータ変更を計算します。
これらの変更の宛先への転送を開始します。
ベースライン スナップショット以降に大量の変更が発生し、次の 1 時間ごとの転送がスケジュールされているときに増分転送がまだ実行されている場合、この転送はスキップされます。次の増分転送では、新しいソース スナップショットがキャプチャされ、最も古い SnapMirror スナップショットが削除され、変更が計算されて転送されます。
宛先ボリュームをマウントするクライアントには、静的コンテンツの読み取り専用ビューが表示されます。ただし、増分転送が完了すると、単一のアトミック オペレーションによって、ボリュームの内容が前のレプリケーション スナップショットから最新のスナップショットに即座に更新されます。
ソースボリュームに追加された新しいデータの量が 1 時間以内に転送できる量を超えない限り、増分転送のサイズは転送が成功するたびに減少します。このプロセスは、ソースボリュームの 1 時間あたりの変更率で定義されたレートで安定するまで続きます。これには数回の反復が必要になる場合があります。この安定状態に達したら、カットオーバーをスケジュールできます。カットオーバーに必要なダウンタイムを最小限に抑えるため、ソースボリュームと宛先ボリューム間の変更を減らすことを目指します。
カットオーバー
カットオーバーでは、データ損失（RPO = 0）と最小限のダウンタイム（RTO）で、ワークロードをソースボリュームから宛先ボリュームに移行します。カットオーバー プロセスは、次のサブステップで構成されます。
変更を停止する
増分転送は非同期であるため、ソースボリュームには宛先ボリュームにまだ反映されていない変更が含まれている可能性があります。同期するには、次の操作を行ってソースボリュームのすべての変更を停止します。
データを変更するすべてのアプリケーションを停止します。
省略可: ボリューム権限を読み取り専用に変更して、クライアントがデータを変更できないようにします。
現在の転送を待つ
実行中の増分転送が完了していることを確認します。
手動で増分転送を実行する
手動で増分転送を実行して、最新のデータを宛先システムに送信します。これには、最後の転送以降に変更されたデータの量、ネットワーク速度、宛先ボリュームのスループット上限に応じて、数秒から数分かかります。
手動の増分転送が完了すると、宛先で最新のデータを使用できるようになります。
レプリケーションを停止する
レプリケーションで停止オペレーションを実行して、宛先ボリュームを読み取り / 書き込み可能にします。これでデータ移行が完了します。
アプリケーションを再構成して再起動する
宛先ボリュームを使用するようにアプリケーションを再構成し、再起動します。アプリケーションが誤ってソースボリュームを使用しないように、ソースボリュームへのすべてのデータアクセスが停止していることを確認してください。
クリーンアップ
カットオーバーが成功したら、次のクリーンアップ手順を実行できます。
停止したレプリケーションを削除する: 停止したレプリケーションを削除すると、 レプリケーション リソースは削除されますが、宛先ボリュームは削除されません。 このプロセスでは、バックエンドでソースシステムで使用される SnapMirror 関係も削除されます。
クラスタ ピアリングを削除する: NetApp Volumes とソースクラスタ間の最後の SnapMirror 関係である場合は、ソース ONTAP システムからクラスタ ピアリングを削除できます。また、移行のみを目的としてソースと宛先の間で構成されたネットワークを削除することもできます。