ボリュームの移動先のローカル階層にクラウド階層が接続されていない場合、クラウド階層に保存されているソース ボリュームのデータは、移動先のローカル階層のローカル階層に書き込まれます。

ONTAP 9.8 以降では、ボリュームで"Inactive Data Reporting"が有効になっている場合、FabricPoolはボリュームのヒート マップを使用して、コールド データが宛先のローカル階層に書き込まれるとすぐに階層化を開始するためにキューに登録します。

ONTAP 9.8より前のバージョンでは、ボリュームを別のローカル階層に移動すると、ローカル階層のブロックの非アクティブ期間がリセットされます。例えば、ボリューム階層化ポリシーが「Auto」で、ローカル階層に20日間非アクティブなデータがあり、まだ階層化されていない場合、ボリュームの移動後、データの温度は0日にリセットされます。

ONTAP 9.6以降、ボリューム移動の宛先ローカル階層がソースローカル階層と同じバケットを使用している場合、バケットに格納されているソースボリューム上のデータはローカル階層に戻されません。階層化されたデータはそのまま残り、ホットデータのみをあるローカル階層から別のローカル階層に移動する必要があります。この最適化されたボリューム移動により、ネットワーク効率が大幅に向上します。

たとえば、300TB の最適化されたボリュームの移動は、300TB のコールド データがローカル層から別の層に移動されても、オブジェクト ストアへの 300TB の読み取りと 300TB の書き込みがトリガーされないことを意味します。

最適化されていないボリュームの移動により、追加のネットワークおよびコンピューティング トラフィック（読み取り/GET および書き込み/PUT）が生成され、ONTAP クラスタおよびオブジェクト ストアに対する要求が増加し、パブリック オブジェクト ストアに階層化するときにコストが上昇する可能性があります。

ボリューム移動の宛先ローカル層にクラウド層が接続されている場合、クラウド層に保存されているソースボリューム上のデータは、まず宛先ローカル層のローカル層に書き込まれます。その後、ボリュームの階層化ポリシーにこの方法が適切であれば、宛先ローカル層のクラウド層に書き込まれます。

データを最初にローカル階層に書き込むことで、ボリューム移動のパフォーマンスが向上し、カットオーバー時間が短縮されます。ボリューム移動時にボリューム階層化ポリシーが指定されていない場合、デスティネーション ボリュームはソース ボリュームの階層化ポリシーを使用します。

ボリュームの移動を実行するときに異なる階層化ポリシーを指定した場合、指定された階層化ポリシーを使用してデスティネーション ボリュームが作成され、ボリュームの移動は最適化されません。