3. 迁移前期评估与调研

迁移项目真正开始之前，最容易被低估、却最决定成败的环节，是前期评估与调研。很多迁移失败并非发生在 cutover 当晚，而是因为一开始就没有把“源端到底有什么、谁在用、能停多久”搞清楚。本节围绕四件事展开：存储清单采集、容量与性能分析、协议依赖梳理、应用关联关系与停机窗口评估。它们不是四个独立任务，而是一条逐步收敛的调研链——从“看得见”的物理与逻辑对象，到“算得清”的容量与性能，再到“理得顺”的协议与依赖，最后落到“停得起”的窗口判断。

一、存储清单采集：先建立可信的源端台账

清单采集的目标是形成一份可核对、可追溯的源端对象台账。在 ONTAP 环境中，采集应覆盖三层：物理层（节点、磁盘架、聚合）、逻辑层（SVM、卷、LUN、qtree、共享）、访问层（NFS 导出、CIFS 共享、iSCSI/FC LUN 映射、SnapMirror 关系）。

实际采集时，优先使用 ONTAP 自带命令而非人工登记，避免遗漏与过期信息。例如查看聚合与卷的容量分布：

cluster1::> aggr show -fields size,availsize,used
cluster1::> volume show -fields size,used,available,percent-used,style
cluster1::> lun show -fields size,ostype,mapped
cluster1::> vserver export-policy rule show
cluster1::> cifs share show -fields path,comment
cluster1::> snapmirror show -fields source-path,destination-path,state,lag-time

采集结果建议整理成台账表，字段至少包含：对象类型、名称、所属 SVM、容量、已用率、协议、关联应用、负责人、是否迁移、备注。台账不是一次性文档，而应在调研期间持续更新，作为后续容量测算和窗口评估的输入。

二、容量与性能分析：算清“搬多少”和“搬多快”

容量分析不能只看卷的 size，而要看真实需要迁移的数据量。关键点有三：一是区分逻辑容量与物理占用，精简卷、快照、重复数据删除都会让两者不一致；二是扣除不需要迁移的内容，如过期快照、临时目录、归档数据；三是为迁移过程预留增量空间，因为迁移期间源端仍在写入。

一个可参考的估算方式是：迁移数据量 ≈ 卷已用空间 − 可清理快照 − 可排除目录 + 迁移期间增量。例如某卷 size 10 TB、已用 7.2 TB，其中快照占 1.5 TB、可排除临时数据 0.4 TB，迁移窗口内预计新增 0.3 TB，则实际迁移量约为 5.6 TB。这个数字才是选择迁移工具和估算耗时的依据。

性能分析关注三个指标：源端读写吞吐、IOPS 与延迟、以及迁移链路带宽。若源端卷日常读吞吐约 300 MB/s，而迁移链路只有 1 GbE（理论约 125 MB/s），则迁移必然成为瓶颈，需要评估是否启用更高带宽链路或分批迁移。同时要观察业务高峰时段，避免把迁移安排在源端本身最繁忙的时段。

三、协议依赖梳理：别让“看不见的挂载”拖垮切换

协议依赖是迁移中最隐蔽的风险点。一个卷看起来只是 NFS 导出，但可能同时被多台主机以不同版本挂载，还绑定了导出策略、DNS 名称、LDAP 认证。切换时若只改了存储侧，客户端仍指向旧 IP 或旧导出路径，业务就会中断。

梳理时应逐项确认：NFS 的版本（v3/v4.1）、挂载点与挂载参数（如 hard/soft、rsize/wsize）、导出策略规则；CIFS 的共享名、访问权限、ACL 与本地用户映射；iSCSI/FC 的 initiator、igroup、LUN ID 与多路径配置；以及 SVM 依赖的 DNS、LDAP、NIS、Kerberos 等服务。建议为每个协议对象记录“客户端—挂载方式—认证方式—切换后目标”四要素，作为切换脚本和回退方案的依据。

四、应用关联关系与停机窗口评估

应用关联关系回答的是“这个卷停了，谁会受影响”。做法是从应用出发反向映射：应用 → 主机 → 挂载点/LUN → 卷 → 聚合。一个应用可能跨多个卷，一个卷也可能被多个应用共享，必须画出映射矩阵，识别出共享卷和关键路径。

停机窗口评估则把容量、性能、依赖三者合到一起判断。以示例数据说明：某业务允许停机 4 小时，需迁移数据 5.6 TB，链路有效速率约 125 MB/s，则纯传输时间约为 5.6×1024×1024 MB ÷ 125 MB/s ≈ 46976 s ≈ 13 小时，远超窗口。此时可选策略包括：提升链路带宽、先做基线同步再增量切换、按应用分批迁移，或对非关键数据采用后台迁移。评估结论必须明确写出“窗口是否可行、依据是什么、若不可行的替代方案”，而不是只给一个“可以/不可以”。

把上述四步做完，迁移项目才真正具备可执行的输入：一份可信台账、一个算得清的迁移量、一张协议依赖清单、一份应用映射与窗口结论。后续的工具选型、迁移方案设计和切换演练，都应建立在这份调研成果之上。