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