4. 现有存储环境发现与资产梳理

迁移项目最容易出问题的环节，往往不是目标端配置，而是对源端“家底”掌握不清。一次企业级迁移涉及的对象远不止几块 LUN：主机、HBA、多路径、卷、快照、克隆、复制关系、保护组、性能基线与容量趋势，彼此交织成一张依赖网。本节的目标是建立一套可执行的发现与梳理方法，把这张网完整地画出来，作为后续方案设计与割接窗口评估的输入。

一、先明确采集范围与数据来源

发现工作应覆盖四个层面：物理/逻辑资产（阵列、控制器、端口、卷、快照、克隆）、主机侧映射（主机、HBA WWN、iSCSI IQN、多路径、文件系统/集群）、数据保护关系（快照策略、本地/远程复制、保护组、一致性组）、运行特征（IOPS、带宽、时延、队列深度、容量增长）。

数据来源通常有三类：阵列管理界面或 REST API、主机操作系统命令、以及监控/CMDB 系统。以 Pure Storage FlashArray 为例，可通过 purearray、purevol、purehost、purepgroup、purehgroup 等 CLI 或 REST 接口批量导出；主机侧则用 multipath -ll、lsblk、lsscsi、powermt display dev=all 等命令交叉验证。建议先做一次全量导出，再按业务系统分组，避免遗漏“孤儿卷”和已下线但未清理的映射。

二、主机与卷的映射梳理

主机侧梳理的核心是回答三个问题：谁在用、用哪块卷、通过哪条路径。建议按“主机 → HBA/发起端 → 目标端口 → 卷 → 文件系统/集群资源”的链路逐层记录。多路径环境下，同一卷会出现多条设备路径（如 sda/sdb/sdc/sdd），必须记录聚合后的设备名与路径数量，因为迁移后路径策略若不一致，可能引发性能下降或挂载失败。

对于集群（如 Oracle RAC、VMware vSphere、Windows 故障转移集群），还需记录共享卷、仲裁盘、心跳盘以及集群资源与卷的绑定关系。这些对象在迁移中通常要求“同组同批”，不能拆散。

三、快照、克隆与复制关系

快照与克隆决定了迁移的“时间点”和“回退能力”。需要采集：快照名称、创建时间、保留策略、是否挂载给主机、是否被克隆引用。克隆卷要特别标注其父卷，因为父卷迁移时克隆可能失效或需要重建。

复制关系是割接窗口的关键约束。要记录复制方向（单向/双向）、模式（同步/异步）、RPO、保护组归属、一致性组成员。若源端与目标端存在级联复制或三角复制，必须画出拓扑，否则割接时容易出现“停了一个方向、另一个方向仍在写”的隐蔽问题。

四、性能基线的采集方法

性能基线不是“看一眼当前 IOPS”，而是要有统计意义的分布。建议采集窗口不少于 14 天，覆盖工作日高峰、月末结算、备份窗口和批处理时段。关键指标包括：每卷读/写 IOPS、读/写带宽（MB/s）、平均与 P95 时延、队列深度、缓存命中率。若源端为全闪阵列，还需关注写放大与垃圾回收对时延的影响。

采集方式上，阵列侧可用性能 API 按卷粒度导出时间序列；主机侧可用 iostat -x 5、esxtop、perfmon 等做交叉验证。两者出现明显偏差时，通常意味着多路径、队列或主机侧限流存在问题，需要在迁移前定位。

五、容量与依赖关系的量化

容量梳理要区分“物理占用”和“逻辑分配”。精简卷的逻辑容量可能远大于实际占用，迁移时若目标端按逻辑容量规划，会造成严重浪费。建议记录：卷逻辑容量、实际占用、快照占用、克隆占用、增长率（GB/月）。增长率可用最近 3 个月数据做线性拟合，作为目标端容量冗余的依据。

依赖关系则要形成“卷 → 主机 → 应用 → 业务系统”的链路。共享卷、仲裁盘、心跳盘、数据库数据盘与日志盘必须成组标记，因为它们对割接顺序有强约束。例如 Oracle 的数据盘与归档日志盘若分属不同保护组，割接时需保证一致性组内同时切换。

六、可执行的资产台账字段示例

下表给出一个可直接使用的台账字段结构，实际项目中可按业务系统拆分为多个工作表。示例中的数值为教学假设，不代表真实环境实测结果。

完成上述采集后，你会得到一份包含主机、卷、快照、复制、性能、容量、依赖七类信息的资产台账。它既是迁移方案设计的输入，也是割接窗口评估、回退方案制定和迁移后验证的基准。下一阶段的所有决策，都应能追溯到这份台账中的具体字段。