2. ThinkSystem硬件与带外管理基础
在开始批量配置之前，必须先厘清 ThinkSystem 服务器上几个容易混淆的概念：XCC 是服务器内部的带外管理控制器，OneCLI 是运行在操作系统内的命令行工具，XClarity 是面向多台设备的集中管理平台，Redfish 与 IPMI 则是它们对外通信所依赖的接口协议。理解这五者各自的位置和职责，才能判断一条批量配置指令究竟应该发往哪里、由谁执行、结果如何回读。
一、带外管理与 XCC 的定位
带外管理（Out-of-Band）指不依赖服务器操作系统即可对硬件进行监控和控制的通道。ThinkSystem 服务器上的核心部件是 XCC（Lenovo XClarity Controller），它是一颗独立于主 CPU 和操作系统的管理芯片，只要服务器接入电源（待机供电即可），XCC 就能工作。XCC 拥有独立的网络接口（通常标注为 XCC 管理口或共享端口），并维护一套独立的 IP 地址、账号和固件。
XCC 能做的事情包括：查看电源、温度、风扇、电压等传感器读数；读取和清除系统事件日志（SEL）；控制开机、关机、重启、强制下电；挂载远程 ISO 或虚拟介质；查看固件版本并执行固件更新；配置 BIOS/UEFI 设置项；以及通过串口重定向访问控制台。这些能力正是批量配置的基础——因为 XCC 不依赖操作系统，即使目标机器尚未安装系统或系统已崩溃，仍然可以远程完成设置。
需要特别区分的是：XCC 管理的是“服务器硬件层”，而操作系统内的网卡、磁盘、服务配置并不属于 XCC 的职责范围。批量配置时，凡是 BIOS 设置、启动顺序、BMC 网络、固件版本、电源策略这类内容，走 XCC 通道；凡是操作系统内的软件包、用户、服务，则需要借助 OneCLI 或其它系统内工具。
二、OneCLI 与 XClarity 的分工
OneCLI 是安装在操作系统内部的命令行工具，它通过本地接口与 XCC 通信，因此不需要网络可达 XCC 的管理 IP。OneCLI 的典型用途是：在系统内读取硬件清单、导出/导入 BIOS 与 BMC 配置、执行固件更新、设置启动顺序。它的优势在于可以随操作系统镜像一起批量部署，适合“系统已装好、需要统一硬件配置”的场景。
XClarity 则是集中管理平台，常见形态包括 XClarity Administrator（本地部署的管理服务器）和 XClarity Controller 的 Web 界面。XClarity Administrator 可以纳管成百上千台服务器，统一执行固件合规检查、配置策略下发、事件收集和批量操作。它面向的是“多台设备、跨机房、需要策略一致性”的场景，是批量配置在管理侧的入口。
三者的关系可以概括为：XCC 是被管理的执行单元，OneCLI 是系统内的本地操作入口，XClarity 是跨设备的集中编排入口。批量配置时，通常由 XClarity 或脚本通过 Redfish/IPMI 直接与各台 XCC 通信，OneCLI 则用于系统内补充操作。
三、Redfish API 与 IPMI 的差异
Redfish 是基于 HTTPS 和 JSON 的现代管理接口，由 DMTF 标准化。它使用 REST 风格，资源以 URI 表示，例如 /redfish/v1/Systems/1 代表一台服务器，/redfish/v1/Managers/1 代表 XCC 自身。Redfish 支持读取和写入配置、执行动作（如重启、更新固件）、订阅事件，返回结构清晰，便于脚本解析。
IPMI 是更早的带外管理协议，基于 UDP 623 端口，使用二进制消息。它能完成电源控制、传感器读取、SEL 读取等基础操作，但配置类能力有限，且不同厂商的扩展实现差异较大。IPMI 的优势是兼容性广、工具成熟（如 ipmitool），适合做电源和健康状态的批量巡检。
在批量配置中，两者的分工通常是：IPMI 负责“开关机、查状态”这类轻量动作；Redfish 负责“改配置、刷固件、读详细清单”这类需要结构化数据的动作。Redfish 正在逐步取代 IPMI 成为配置类操作的首选接口。
四、批量配置中的实际关联
把上述概念落到批量配置任务上，可以形成一条清晰的判断链。假设需要为 50 台新到货的 SR650 V3 统一设置：XCC 管理 IP、管理员密码、NTP 服务器、BIOS 启动模式为 UEFI、并升级 XCC 固件。合理的做法是：
- 先通过 DHCP 或临时静态地址让每台 XCC 网络可达，确认 Redfish 端口 443 可访问。
- 用 Redfish 的
PATCH /redfish/v1/Managers/1/EthernetInterfaces/1批量下发管理网配置，用PATCH /redfish/v1/AccountService/Accounts/1修改密码。 - 用
PATCH /redfish/v1/Systems/1/Bios提交 BIOS 属性，再触发重启使设置生效。 - 用 Redfish 的 UpdateService 上传固件包，或由 XClarity Administrator 统一推送固件策略。
- 对已装系统的机器，可用 OneCLI 在系统内执行
onecli config set做补充配置。
如果只是批量开关机或采集健康状态，用 IPMI 的 ipmitool -I lanplus -H <XCC_IP> -U <user> -P <pass> power status 即可，脚本简单、开销小。但涉及配置写入时，应优先使用 Redfish，因为它的返回是结构化 JSON，便于判断成功与失败。
五、一个可复用的批量配置检查清单
在实际执行前，建议按以下清单逐项确认，避免批量任务中途失败：
| 检查项 | 确认内容 | 常用手段 |
|---|---|---|
| XCC 可达性 | 管理 IP 可 ping 通，443/623 端口开放 | ping、Redfish GET /redfish/v1 |
| 账号权限 | 使用的账号具备 Configure 权限 | Redfish 查询 AccountService |
| 固件基线 | XCC 与 BIOS 版本满足目标要求 | Redfish 读取 FirmwareInventory |
| 配置模板 | BIOS/BMC 属性名与目标机型匹配 | 先在一台机器导出配置作为模板 |
| 回读验证 | 写入后重新 GET 确认值已生效 | Redfish GET 对应资源 |
| 异常回滚 | 保留原始配置，便于单台恢复 | 导出配置文件存档 |
其中“先在一台机器导出配置作为模板”是最容易被忽略但最有效的一步。不同型号、不同固件版本的 ThinkSystem 服务器，BIOS 属性名可能略有差异，直接套用其它机型的模板会导致 PATCH 返回 400。正确做法是选一台代表机，用 Redfish 或 OneCLI 导出当前配置，确认属性名后再批量下发。
理解 XCC、OneCLI、XClarity、Redfish、IPMI 五者的层次与分工，是后续所有批量配置操作的前提。简单说：XCC 是执行者，Redfish 和 IPMI 是通信语言，OneCLI 是系统内的本地入口，XClarity 是多台设备的统一指挥。选对通道，批量配置才能稳定、可验证、可回滚。