本页详细介绍了如何规划迁移。
估算单个卷的迁移时长
卷迁移时长受多种因素的影响：
源卷的速度：SnapMirror 流量的优先级低于 NFS 和 SMB 流量。源卷上的高工作负载可能会降低出站 SnapMirror 流量的性能。
NetApp Volumes 吞吐量：服务等级和卷大小决定了其吞吐量。卷上的 NFS 或 SMB 流量也可能会降低 SnapMirror 性能。
网络连接吞吐量：SnapMirror 会尽可能提高速度，但可能会占用源 ONTAP 系统与 NetApp Volumes 之间网络连接上与其他用户共享的带宽。
源卷中使用的实际数据量：数据量越大，迁移所需的时间就越长。
源卷数据更改速率：迁移过程中数据更改速率越高，增量传输同步所需的时间就越长。
您可以使用经验法则粗略估算迁移时长。
示例
请考虑以下迁移时长计算场景：
源卷：容量为 15 TiB，已使用 12 TiB 数据。
要转移的数据：12 TiB。
ONTAP 存储效率可以减小传输大小，但在此练习中，您可以忽略这一点。
假设性能能力不是限制因素。
变化率：每天 10%。
每日数据变化率：1.2 TiB。
在此示例中，10% 是一个假设值；实际的更改率通常要低得多。
网络连接：本地基础架构通过 10 Gbps 互连连接到 Google。
- 有效 TCP 带宽：大约 1000 MiBps，可供独占使用。
目标卷：服务等级为 Premium 的 12 TiB 卷。
- 吞吐量上限：12 × 64 MiBps = 768 MiBps。
计算方式
在此示例中，限制因素是目标卷的吞吐量上限 768 MiBps。源卷的性能被视为无限，网络带宽为 1000 MiBps。
基准转移
要转移的数据：12 TiB
吞吐量上限：768 MiBps
时间计算：（12 TiB x 1024^2 MiB/TiB）/ 768 MiBps = 16384 秒
基准转移的总时间：4.6 小时
首次增量转移
自基准转移以来已过时间：5 小时
数据更改：（12 TiB x 1024 GiB/TiB）* 10% *（5 小时/24 小时）= 256 GiB
时间计算：（256 GiB x 1024 MiB/GiB）/ 768 MiBps = 341 秒
首次增量转移的总时间：约 6 分钟
第二次增量转移
自首次增量转移以来经过的时间：1 小时
数据更改：（12 TiB x 1024 GiB/TiB）* 10% *（1 小时/24 小时）= 51.2 GiB
时间计算：（51.2 GiB x 1024 MiB/GiB）/ 768 MiBps = 68 秒
第二次增量传输的总时间：约 70 秒
后续增量转移
在首次增量转移后，所有后续转移通常只需不到一小时。在第二次增量转移之后，所有后续转移所需的时间大致相同。
切换流程
在增量转移完成后立即开始割接流程，以最大限度减少更改数据的累积。
总迁移时间：大约 4.7 小时。
并行运行多次迁移或外部复制
在 API 中，卷迁移和外部复制作为混合复制的两种变体进行管理，并消耗相同的 Google 项目配额。
配置的混合复制数量受特定于区域的项目配额限制，默认设置为 1。您可以使用 Google Cloud 控制台为 NetApp Volumes API 申请提高配额。相关配额如下：
netapp.googleapis.com/standard_hybrid_replicated_volumes_per_regionnetapp.googleapis.com/hybrid_replicated_volumes_per_region
如果您需要迁移的卷数量超出当前配额允许的上限，则必须按顺序执行这些操作。建议将属于同一工作负载的卷分组，以便同时迁移，这也有助于一起切换它们。
对于外部复制，您的项目配额必须足以容纳所有已配置的外部复制，以及任何可能的卷迁移。