📚 课程目录第4章升级迁移前的信息采集与资产建模

4. 升级迁移前的信息采集与资产建模

滚动升级与业务迁移能否一次成功，很大程度上不取决于升级那一刻的操作，而取决于升级之前对“家底”的掌握程度。一个机柜里可能同时存在不同代的 ThinkSystem 服务器、不同固件版本的 RAID 卡、不同驱动版本的网卡，以及跨主机的集群、存储映射和业务依赖。如果这些信息只存在于几位工程师的记忆里，升级窗口内任何一次“意外”都会变成停机事故。本节要解决的就是把分散的硬件、固件、配置和业务关系，转化为可查询、可对比、可回滚的结构化资产模型。

一、资产发现：先让工具“看见”全部设备

资产发现的目标是建立一份权威设备清单，包含机型、序列号、BMC/IP、固件版本、在线状态和纳管状态。Lenovo 环境中最常用的入口是 XClarity Administrator（LXCA）。它通过带外管理网络发现设备，不依赖操作系统是否在线，因此即使某台服务器宕机也能被识别。

实际操作中，先在 LXCA 中配置发现地址范围。例如管理网段为 10.20.30.0/24，可在“发现和管理”中填入该网段，并指定凭据（BMC 用户名/密码）。LXCA 会逐个探测 XCC/IMM 接口，返回设备类型、机型（如 SR650、SR630、SR850）、序列号和当前固件基线。对于未纳管的设备，状态显示为“已发现未管理”，需要执行“管理”动作后才进入统一视图。

对于没有图形界面或需要批量脚本的场景，OneCLI 是更直接的工具。它安装在管理服务器上，通过命令行完成发现、清单导出和配置读取。典型命令如下：

# 发现指定网段设备
onecli discover --range 10.20.30.1-10.20.30.254 --user USERID --password PASSW0RD

# 导出全部受管设备清单为 CSV
onecli inventory export --type all --format csv --output /tmp/inventory.csv

# 查询单台服务器固件版本
onecli inventory show --host 10.20.30.15 --type firmware

导出的 CSV 至少应包含：主机名、机型、序列号、BMC IP、XCC 固件版本、BIOS 版本、RAID 卡型号与固件、网卡型号与固件、电源状态、是否受管。这份清单是后续所有比对和回滚的基准，建议在升级前、升级后各导出一次，用 diff 方式确认变化范围。

发现阶段常见问题是网段填错、凭据权限不足或 BMC 未启用 IPMI over LAN。若设备显示“不可达”，先确认管理口链路和防火墙是否放通 623/443 端口，再检查凭据。

二、配置导出：把“能跑”的状态固化成文件

资产发现只回答了“有什么”，配置导出回答的是“当前怎么配的”。对升级迁移而言，最关键的配置包括：BIOS/UEFI 设置、BMC 网络与用户、RAID 虚拟盘与热备、网卡端口绑定与 VLAN、启动顺序、Secure Boot 状态、电源策略。这些配置一旦在升级中丢失或被重置，业务可能无法启动。

LXCA 支持对受管服务器执行“配置备份”，将 BIOS、BMC、RAID 等设置保存为可回滚的配置文件。OneCLI 同样可以导出单机配置：

# 导出 BIOS 设置为 XML
onecli config export --host 10.20.30.15 --component bios --output bios_sr650.xml

# 导出 BMC 网络配置
onecli config export --host 10.20.30.15 --component bmc --output bmc_sr650.xml

# 导出 RAID 配置
onecli config export --host 10.20.30.15 --component raid --output raid_sr650.xml

导出后不要只存文件，应做一次“可读性校验”：打开 XML 确认关键字段存在，例如 BIOS 中的 BootMode、SecureBoot、HyperThreading，RAID 中的 VD 名称、RAID 级别、条带大小、成员盘。若字段为空或明显异常，说明导出不完整，需要重新执行。建议按“机型_序列号_组件_日期”命名，例如 SR650_7X123456_bios_20240610.xml，便于回滚时快速定位。

三、依赖关系图：把主机、存储、网络和业务串起来

资产清单和配置文件是“点”，依赖关系图是“线”。滚动升级最怕的是升级了 A 主机，却不知道 B 主机的业务依赖 A 提供的 NFS 或数据库。依赖关系图应至少覆盖四层：物理层（服务器—交换机—存储）、虚拟化层（主机—集群—数据存储）、业务层（虚拟机—应用—数据库）、网络层（VLAN—子网—网关）。

构建方法可以分三步：第一，从 LXCA 和 OneCLI 导出主机与网卡、HBA 的对应关系；第二，从存储侧导出 LUN 映射和主机组；第三，从虚拟化平台或配置管理数据库（CMDB）导出虚拟机与主机的归属。将三份数据按序列号、WWN、IP 做关联，即可得到一张可追溯的依赖图。

图中示例说明：主机 A 与主机 B 同时映射到 DE4000 的 LUN 10，且都承载集群 CL-01 的节点。若滚动升级时先升级主机 A，必须确认 LUN 10 的访问路径已切换到主机 B，否则集群可能因存储路径丢失而触发隔离。这类关系仅靠设备清单无法发现，必须通过依赖图显式标注。

四、把资产模型变成升级前的检查依据

资产模型建好后，应直接用于升级前的三项判断。第一，固件一致性检查：对比清单中同型号服务器的 BIOS、XCC、RAID 固件版本，若差异超过两个版本，建议先统一到目标基线，避免升级过程中出现兼容性分支。第二，配置差异检查：将导出的 BIOS/RAID 配置与标准基线做 diff，标记出被手工修改过的参数，例如启动模式从 UEFI 被改为 Legacy、Secure Boot 被关闭，这些都需要在升级前确认是否有意为之。第三，依赖冲突检查：在依赖图中找出共享存储、共享网络或主备关系的节点，排定升级顺序，确保同一时刻只有一个节点处于重启状态。

建议把上述结果整理成一份可执行的升级前检查表，字段包括：设备序列号、当前固件版本、目标固件版本、配置备份路径、依赖对象、升级顺序、回滚方式。这份表不需要复杂模板，但必须逐台填写，不能只写“已检查”。

配置导出文件包含 BMC 用户、网络和部分安全设置，属于敏感信息。存放路径应限制访问权限，不要与普通日志混放，更不要通过邮件明文发送。

最后需要强调，资产建模不是一次性任务。每次升级、迁移或硬件更换后，都应重新导出清单和配置，更新依赖图。只有让模型与现网保持一致，下一次滚动升级才能继续以它为基准，而不是重新从零开始摸排。