3. 服务器硬件与固件基线
在RHEL企业Linux服务器标准化建设中，硬件与固件基线是操作系统稳定运行的物理根基。很多生产事故并非源于内核或应用配置错误，而是由于服务器型号不在认证范围内、BIOS/UEFI参数与RHEL电源管理策略冲突、或同一集群内固件版本参差不齐导致行为不一致。因此，硬件与固件基线必须与OS基线同步规划、同步验收。
一、硬件兼容性列表：从“能装”到“被认证”
RHEL的硬件兼容性并非简单的“能启动、能识别”。Red Hat通过Red Hat Ecosystem Catalog维护认证硬件列表，涵盖服务器整机、CPU、RAID卡、HBA卡、网卡、GPU等。认证状态通常分为三类：Certified（整机或部件通过Red Hat认证测试）、Compatible（可运行但未完成完整认证）、Unsupported（不在支持范围）。企业基线应优先选择Certified条目，并记录认证对应的RHEL主版本，例如RHEL 8与RHEL 9的认证结果可能不同。
实际选型时，不能只看整机型号。以一台典型2U机架服务器为例，整机可能已认证，但若选配了非认证的25GbE网卡或第三方NVMe背板，仍可能触发驱动缺失或性能异常。因此，硬件兼容性列表应细化到整机型号 + CPU代际 + RAID/HBA型号 + 网卡芯片 + 固件版本范围。建议在采购前将配置单与Catalog逐项比对，并保存认证页面截图或PDF作为验收依据。
二、BIOS/UEFI设置基线：影响稳定性与可观测性的关键项
BIOS/UEFI设置直接决定操作系统看到的硬件拓扑、电源状态和性能特性。RHEL标准化建设中，以下参数应纳入基线并统一固化：
- 启动模式：UEFI模式配合GPT分区，支持Secure Boot；Legacy BIOS仅用于无法改造的老旧设备。
- Secure Boot：生产环境建议启用，确保内核模块签名校验；若使用第三方DKMS驱动，需提前验证签名兼容性。
- CPU电源管理：将“Power Profile”设为Performance或Maximum Performance，避免OS层cpufreq与BIOS节能策略冲突导致延迟抖动。
- Hyper-Threading：数据库、高并发中间件场景建议开启；若应用对逻辑核敏感，需在基线中明确关闭。
- NUMA：保持Enabled，配合RHEL的numad或手动绑核，避免跨节点内存访问。
- SR-IOV / IOMMU：虚拟化或DPDK场景需开启VT-d/AMD-Vi，并确认内核启动参数包含
intel_iommu=on或amd_iommu=on。 - Boot Order：固定为本地磁盘优先，禁用网络PXE，防止意外重启进入安装镜像。
这些设置应通过厂商带外管理工具（如iDRAC、iLO、XCC）批量导出为配置文件，形成“BIOS基线模板”，新机器上架时直接导入，避免逐台手工设置。
三、固件版本统一：消除“同型号不同行为”
固件包括BIOS/UEFI、BMC、RAID卡、网卡、HBA、硬盘等。同一型号服务器若BIOS版本不同，可能出现ACPI表差异、PCIe链路速率协商不一致、甚至内核panic。因此，固件基线应明确每个部件的最低版本和推荐版本，并尽量在同一批次内统一。
以某企业RHEL 9集群为例，基线要求：BIOS不低于2.15.1，iDRAC不低于6.10.80.00，PERC H755 RAID卡固件不低于52.21.0-4606，Broadcom 57414网卡固件不低于22.91.06.00。升级固件时，应遵循“先BMC、再BIOS、后外设”的顺序，并在升级前记录当前版本、升级后通过dmidecode、ethtool -i、storcli /c0 show等命令复核。
四、验收方法与记录
硬件与固件基线的验收不能停留在“装好了、能开机”。建议按以下闭环执行：
- 采集：使用
dmidecode、lspci、ethtool -i、storcli、nvme等命令采集整机、BIOS、网卡、RAID、NVMe的型号与固件版本。 - 比对：将采集结果与基线表逐项比对，标记“符合/不符合/待确认”。
- 整改：不符合项按厂商指导升级或调整BIOS参数，升级后重新采集。
- 归档：将最终采集输出、BIOS配置文件、固件升级日志存入CMDB或配置管理库，作为后续变更的基准。
dmidecode和ethtool，输出JSON报告，便于批量验收和差异追踪。硬件与固件基线是RHEL标准化建设中“看不见但最致命”的一层。只有把兼容性、BIOS/UEFI参数和固件版本三者同时纳入基线并完成验收，才能为后续的OS安装、内核调优、集群部署提供一致、可复现的物理底座。