📚 课程目录第4章迁移前评估与发现

4. 迁移前评估与发现

迁移工程最容易出问题的阶段，往往不是切换当晚，而是切换之前对现状的“想当然”。一台虚拟机到底占多少存储、峰值时消耗多少 IOPS、和哪些虚机存在隐式依赖、有没有人还在用某个早已被遗忘的端口——这些信息如果只靠人工翻 vCenter 清单，几乎必然遗漏。本节要解决的就是把“现状”变成可量化、可追溯的数据基线，为后续的目标平台选型、迁移批次编排和回退方案提供依据。

一、评估要采集的三类数据

迁移前评估的数据可以归为三条主线，它们分别回答不同的问题：

容量数据：回答“要搬多少东西”。包括每台虚机的已分配空间、已使用空间、精简置备下的实际占用、快照占用、以及所在数据存储的剩余容量。注意已分配与已使用在精简置备环境中差异可能极大，迁移目标若采用厚置备，必须按已分配计算。
性能数据：回答“搬过去扛不扛得住”。核心是 CPU 就绪时间、内存争用、磁盘读写的 IOPS 与延迟、网络吞吐。这些指标必须看峰值而非平均值，因为迁移后的目标平台通常需要按峰值预留资源。
依赖数据：回答“能不能单独搬”。包括虚机之间的网络连接、共享存储挂载、应用层调用关系、以及对外部物理设备的依赖。依赖没理清，迁移批次就会被迫反复调整。

二、vRealize Operations：性能与容量基线

vRealize Operations（vROps）通过适配器接入 vCenter，持续采集性能计数器并做趋势分析。评估阶段建议至少保留 30 天的历史数据，覆盖一个完整的业务周期（含月末结算、批量作业等峰值场景）。

实际操作上，先在 vROps 中确认 vCenter 适配器状态正常，然后在“环境”视图中按集群或自定义分组查看虚机列表。关键动作是导出或查看以下指标：

虚机级指标（近30天）：
  cpu|usage_average            平均 CPU 使用率
  cpu|readyPct                 CPU 就绪时间占比（关键）
  mem|usage_average           平均内存使用率
  mem|ballooning             内存气球回收量
  disk|usage_average          磁盘使用率
  disk|totalLatency_average   磁盘总延迟
  net|usage_average           网络吞吐

数据存储级指标：
  disk|capacity_total         总容量
  disk|capacity_used          已用容量
  disk|numberReadAverage      读 IOPS
  disk|numberWriteAverage     写 IOPS

判断依据上，CPU 就绪时间占比持续超过 5% 说明物理 CPU 存在争用，迁移到新平台时要么提高 vCPU 与物理核的比例余量，要么考虑调整资源池。内存气球回收量长期大于零，说明内存超分过度，目标平台的内存配置不能简单照搬。磁盘延迟若在业务高峰超过 20ms，需要确认是存储后端瓶颈还是虚机自身 IO 模式问题，前者会影响迁移后的存储选型。

vROps 的“容量剩余时间”视图可以估算当前集群在现有增长趋势下还能支撑多久，这个数字对判断是否需要借迁移之机扩容很有参考价值，但它基于历史趋势外推，遇到业务突变会失真，只能作为辅助。

三、Live Optics：无代理的深度采集

Live Optics（原 DPACK）走的是另一条路线：它不依赖 vCenter 的长期历史，而是通过采集器在较短时间内高频抓取性能样本，生成一份包含 IO 分布、读写比例、块大小、队列深度的报告。它的优势在于能给出存储 IO 的“形状”，而不只是总量。

典型流程是：在环境中部署 Live Optics 采集器（Windows 或 Linux 版本），指向 vCenter 或直接采集主机，运行 24 至 72 小时。采集结束后上传数据到 Live Optics 门户，生成报告。报告中值得重点看的是：

读写 IOPS 比例与峰值时段分布；
IO 块大小直方图，判断是随机小 IO 还是顺序大 IO；
每台虚机的 IO 贡献排名，识别“吵闹邻居”；
CPU 与内存的峰值利用率分布。

这些数据直接支撑目标存储的选型。例如报告显示某业务虚机 80% 的 IO 是 4KB 随机读，那么目标存储的全闪阵列或分布式存储就需要在随机读性能上有足够余量，而不能只看总容量。

四、依赖关系梳理

依赖采集不能只靠工具，需要工具加人工确认。工具层面，可以从 vCenter 导出虚机的网络端口组、VLAN、共享数据存储挂载关系，形成初步的连接图。人工层面，需要和应用负责人确认应用之间的调用关系、数据库主从、以及对外部系统的接口。

一个实用的做法是建立“迁移批次依赖表”，把虚机按应用系统分组，标注组内依赖和跨组依赖。跨组依赖是批次编排的难点，通常需要把有强依赖的虚机放在同一批次，或者通过临时网络打通来解耦。

五、数据采集的实操要点

采集周期要覆盖业务峰值。如果只采工作日白天，很可能错过夜间批处理的高 IO 时段。建议至少覆盖一个完整的月末或季度末周期。对于 vROps，确认数据保留策略足够长；对于 Live Optics，采集窗口内不要重启采集器，否则样本会中断。

采集完成后，建议把数据整理成一份评估基线表，字段包括：虚机名称、所属应用、vCPU/内存配置、已用存储、峰值 CPU 使用率、峰值内存使用率、峰值 IOPS、平均延迟、依赖对象、迁移批次建议。这份表是后续所有决策的输入，也是迁移后验证的对照基准。

评估数据反映的是采集窗口内的状态。如果采集期间恰好有业务下线或临时扩容，数据会失真。建议在采集报告中标注异常时段，并在依赖确认阶段向应用负责人核实，避免把临时状态当成常态。

最后要强调的是，工具给出的是数据，判断仍然依赖工程经验。vROps 和 Live Optics 的报告可以告诉你“现在是什么样”，但“迁移后需要什么样”取决于目标平台的架构、业务增长预期和可用性要求。把采集数据、业务访谈和目标平台规格三者对齐，评估阶段才算真正完成。