2. RHEL生产平台架构与验收基线

RHEL生产平台的验收，第一步不是登录服务器敲命令，而是先把“这套平台长什么样、边界在哪里、按什么标准算合格”讲清楚。架构与验收基线是后续所有检查项、测试用例和交付文档的源头：架构决定了要验哪些对象，基线决定了每个对象达到什么状态才算通过。本节围绕典型架构、部署拓扑、硬件与虚拟化要求、网络与存储规划、验收基线定义五个方面展开，并给出可直接用于验收的基线条目示例。

一、典型架构：从物理资源到业务服务的分层

一套标准的RHEL生产平台通常可以拆成四层，自下而上依次是：物理/虚拟资源层、操作系统层、平台服务层、业务承载层。物理/虚拟资源层提供CPU、内存、磁盘、网卡或虚拟化资源池；操作系统层是RHEL本身，包括内核、文件系统、systemd、SELinux、防火墙等；平台服务层是运行在RHEL之上的中间件与基础服务，如Web服务器、数据库、消息队列、容器运行时、高可用集群；业务承载层则是最终对外提供能力的应用进程与访问入口。

分层的目的在于明确验收责任边界。例如，操作系统层的验收关注内核参数、补丁级别、SELinux状态；平台服务层的验收关注服务是否开机自启、监听端口是否正确、集群资源是否在线；业务承载层的验收关注应用健康检查接口是否返回正常。若不分层，验收时容易出现“应用不通就归咎于操作系统”的扯皮，而分层后每一层都有独立的通过判据。

二、部署拓扑：单机、主备与集群的取舍

部署拓扑直接决定可用性等级和验收复杂度。常见拓扑有三类：

• 单机拓扑：一台RHEL主机承载全部角色，结构简单、验收快，但存在单点故障，仅适用于测试或非关键业务。
• 主备拓扑：两台主机通过Pacemaker/Corosync或数据库自带复制实现故障切换，验收重点是切换时间、数据一致性和VIP漂移。
• 集群/分布式拓扑：多节点组成集群，配合负载均衡、共享存储或分布式存储，验收重点是节点加入退出、仲裁、脑裂防护和横向扩展能力。

选择拓扑时，应把业务RTO（恢复时间目标）和RPO（恢复点目标）作为输入。例如RTO要求小于5分钟，主备拓扑通常可以满足；若要求接近零中断，则需要集群加负载均衡。拓扑一旦确定，验收用例就应围绕该拓扑的故障场景设计，而不是只验证“正常启动”。

三、硬件与虚拟化要求

硬件要求不是越高越好，而是要与业务负载匹配并留出余量。验收时应核对以下参数：CPU核数与主频、内存容量、本地磁盘类型与容量、RAID级别、网卡数量与速率、电源与风扇冗余。对于虚拟化环境，还要确认虚拟CPU与物理CPU的超分比、内存是否预留、是否启用NUMA亲和性、虚拟磁盘是否使用厚置备或精简置备。

一个常见的验收陷阱是只看“配置单”不看“实际识别值”。例如配置单写32核，但操作系统内 lscpu 只识别到16核，可能是虚拟化层未正确透传或BIOS未开启相关选项。因此硬件验收必须包含“配置单—虚拟化层—操作系统内”三级一致性核对。

四、网络与存储规划

网络规划要明确三类流量：管理流量、业务流量、存储流量。生产环境建议物理隔离或VLAN隔离，避免存储流量与业务流量争抢带宽。验收时需确认：IP地址规划表与实际配置一致、网关与DNS可达、bond/team配置正确、MTU与交换机一致、防火墙规则仅放行必要端口。

存储规划要明确本地盘、共享存储和备份存储的用途。对于使用LVM的场景，验收应检查卷组、逻辑卷、文件系统类型、挂载选项（如 noatime）、以及 /etc/fstab 中的UUID是否与实际一致。对于共享存储，还要验证多路径（multipath）状态、路径冗余和故障切换。

五、验收基线定义

验收基线是“可判定”的集合，而不是模糊描述。一条合格的基线条目应包含：检查对象、检查方法、期望值、判定方式。例如“SELinux必须为enforcing”是对象和期望值，但缺少检查方法；完整写法是“执行 getenforce，输出为 Enforcing 则通过，否则不通过”。

基线通常分为强制项和推荐项。强制项不通过则整体验收不通过，推荐项不通过可记录为整改项。以下是一份可直接参考的基线条目示例（示例参数，实际项目应按业务调整）：

六、把架构与基线串起来

架构图回答“验什么”，基线表回答“怎么算过”。两者必须一一对应：架构中出现的每一层、每一个关键组件，都应在基线中有对应条目；基线中不应出现架构里不存在的对象。验收前建议做一次“架构—基线映射”检查，确认没有遗漏的组件，也没有多余的检查项。完成映射后，再进入具体的命令执行与证据收集阶段，验收工作才有据可依、可复现、可交付。