4. EPYC服务器批量发现与资产录入
当EPYC服务器从几十台扩展到几百台时，靠人工逐台登记资产会迅速成为瓶颈：带外地址、序列号、固件版本、CPU型号、内存容量、网卡MAC、机架位置等信息分散在BIOS、BMC、交换机、DHCP租约和采购单里，任何一处不一致都会让后续的批量配置、固件升级和故障定位失去可靠基础。本节要解决的核心问题是：如何让服务器在接入网络后自动"自报家门"，并把可信数据写入CMDB，形成可校验、可追溯的资产基线。
一、发现通道：IPMI与Redfish的分工
EPYC平台的带外管理由BMC（如AMI MegaRAC、OpenBMC）提供，对外暴露两套接口：传统IPMI（UDP 623）和现代Redfish（HTTPS 443）。IPMI适合做低层探测，例如通过ipmitool -I lanplus -H <bmc_ip> -U admin -P *** mc info读取厂商、固件版本，用fru print读取FRU中的序列号和产品名。但IPMI的FRU字段常因厂商实现差异而缺失或格式不一，且并发能力弱。Redfish以JSON返回结构化资源树，路径规范，更适合批量采集。
实际发现通常分两步：先用IPMI做"存活+身份"粗筛，确认BMC在线并拿到基础标识；再用Redfish做"深度采集"，遍历/redfish/v1/Systems/1、/redfish/v1/Chassis/1、/redfish/v1/Managers/1等资源，提取CPU型号（如EPYC 9654）、核心数、内存DIMM容量与速率、网卡MAC、电源与散热状态、BIOS/BMC固件版本。采集脚本应设置超时与重试，并对返回字段做空值保护，避免个别机型导致整批任务中断。
二、DHCP与DNS联动：让地址与名字自动对齐
批量发现的前提是"知道去哪里找"。DHCP负责分配带内管理地址，DNS负责把主机名解析为地址。建议在DHCP中为服务器网段配置Option 12（主机名）和Option 81（FQDN），并启用DDNS，让客户端注册A记录和PTR记录。这样采集器只需从DHCP租约文件（如ISC DHCP的dhcpd.leases）或通过omshell查询租约，就能获得"IP—MAC—主机名"的对应关系，再结合DNS正向解析确认FQDN。
一个实用的做法是：以MAC作为跨系统关联键。DHCP租约给出MAC与IP，Redfish的EthernetInterface资源给出MAC与网卡型号，CMDB以MAC关联到具体服务器。当DNS未及时注册时，采集器应记录"DNS缺失"告警，但不要因此丢弃资产，而是以IP作为临时主键，待DDNS补齐后再合并。
三、CMDB资产模型设计
资产模型不必一开始就追求大而全，但必须保证唯一键、必填字段和关系清晰。针对EPYC服务器，建议至少定义以下CI类型：
| CI类型 | 关键属性 | 唯一键 | 关系 |
|---|---|---|---|
| Server | 序列号、厂商、型号、CPU型号、核心数、内存总量、BIOS版本 | 序列号 | 位于 Rack，包含 BMC/NIC/DIMM |
| BMC | IP、MAC、固件版本、Redfish版本、账号策略 | MAC | 管理 Server |
| NIC | MAC、速率、PCI地址、驱动版本 | MAC | 属于 Server |
| DIMM | 容量、速率、插槽、厂商 | 序列号+插槽 | 属于 Server |
| Rack | 机房、机柜号、U位 | 机房+机柜号 | 包含 Server |
其中"序列号"是服务器最稳定的身份标识，但部分白牌机可能为空或重复，因此需要"序列号+主MAC"组合唯一键。CPU和内存信息建议以子对象存储，便于后续按型号统计容量和规划升级。
四、批量导入与校验
采集结果通常先落为CSV或JSON，再导入CMDB。导入前必须做三层校验：第一层是格式校验，检查IP、MAC、序列号是否符合正则；第二层是业务校验，检查必填字段是否为空、CPU型号是否在支持列表、内存容量是否为合理值；第三层是冲突校验，检查序列号或MAC是否已存在，若存在则比较字段差异，决定更新还是标记冲突。
# 示例：从Redfish采集并生成导入CSV（字段为示例）
python3 collect_epyc.py --range 10.20.30.0/24 \
--user admin --password '***' \
--output assets.csv
# assets.csv 示例行
serial,model,cpu,cores,mem_gb,bmc_ip,bmc_mac,nic_mac,bios,bmc_fw,rack
"EPYC-0001","R23-EPYC","9654",96,768,"10.20.30.11","aa:bb:cc:00:01:01","aa:bb:cc:00:02:01","1.2.3","4.5.6","A01-U12"
导入后应输出一份校验报告，列出成功、更新、冲突、失败四类数量，并对冲突项给出差异字段。例如某台服务器序列号已存在但BMC IP变化，说明可能发生了板卡更换或地址调整，应人工确认后再更新。只有校验通过且差异被确认，资产才真正进入"可信基线"。
整体来看，批量发现与资产录入不是一次性动作，而是一条"发现—归一化—建模—校验—持续同步"的数据链。IPMI/Redfish解决"采得到"，DHCP/DNS解决"找得到"，CMDB模型解决"存得对"，校验与定时任务解决"用得久"。四者配合，才能让EPYC服务器群具备可自动化运维的资产底座。