1. 课程导入与高可用平台设计总览

在数据中心里，业务连续性从来不是靠单台服务器的“强壮”来保证的。真正决定一套平台能否长期稳定运行的，是它面对故障时的整体应对能力：CPU 是否具备足够的核心密度与内存带宽承载关键业务，内存与 I/O 路径是否存在单点，虚拟化或容器层能否在节点失效时快速迁移负载，监控与告警能否在用户感知之前发现问题。本课程围绕 AMD EPYC 平台，讨论如何从硬件选型、冗余设计、资源调度到运维观测，构建一套可落地的高可用业务平台。

学习目标

完成本章后，你应当能够：

• 说明高可用（High Availability, HA）在业务平台中的衡量方式，理解可用性等级与年停机时间之间的对应关系；
• 描述 AMD EPYC 平台在高可用架构中的核心价值，包括核心密度、内存通道、PCIe 通道与安全特性；
• 画出高可用业务平台的整体分层架构，并指出每一层可能出现的单点故障；
• 掌握平台设计的四条基本原则：冗余、隔离、可观测、可恢复，并能将其对应到具体部件与配置项。

可用性不是“不坏”，而是“坏得快恢复”

高可用通常用可用性百分比描述。以一年 365 天为基准，99.9% 可用性对应约 8.76 小时停机，99.99% 对应约 52.6 分钟，99.999% 则只有约 5.26 分钟。这个数字提醒我们：高可用设计的目标不是让硬件永不故障，而是把故障影响范围压缩到最小，并把恢复时间（RTO）和数据丢失量（RPO）控制在业务可接受范围内。

因此，平台设计要回答三个问题：故障发生在哪一层？这一层是否有冗余？切换需要多长时间、是否会丢数据？例如，单电源服务器在机房一路市电中断时会直接宕机，而双电源接入 A/B 两路 PDU 后，单路故障不影响运行；再如，单节点虚拟化集群中宿主机宕机，其上虚拟机全部中断，而多节点集群配合共享存储或分布式存储，可将虚拟机在数十秒到数分钟内自动重启到其他节点。

AMD EPYC 平台的核心价值

AMD EPYC 处理器采用 Chiplet 设计，将多个 CPU 核心复合体（CCD）与 I/O 芯片（IOD）分离制造。以 EPYC 9004 系列为例，单路最高可达 96 个 Zen 4 核心、192 线程，支持 12 通道 DDR5 内存和 128 条 PCIe 5.0 通道。对高可用平台而言，这些参数的意义并不只是“性能高”，而是直接改变冗余设计方式：

• 核心密度高：单台双路服务器可提供 192 核 384 线程，使 N+1 集群中“少一台节点仍能承载全部业务”成为可能，降低冗余成本；
• 内存通道多：12 通道 DDR5 提供更高带宽与更多 DIMM 插槽，便于按通道均匀插满内存，避免因单通道故障或带宽瓶颈影响业务；
• PCIe 通道充足：128 条 PCIe 5.0 可同时连接多块 NVMe SSD、双口/四口网卡和 GPU，便于构建无单点的存储与网络路径；
• 安全能力内建：AMD Infinity Guard 提供安全加密虚拟化（SEV-SNP）等功能，在多租户或混合负载场景中降低横向攻击风险。

需要强调的是，EPYC 的高核心数并不自动等于高可用。如果内存只插了部分通道、网卡只有单口、电源只有单路，平台依然存在明显单点。硬件能力必须通过架构设计转化为可用性。

高可用业务平台的整体架构

从下往上，可将平台划分为基础设施层、资源抽象层、业务运行层和运维观测层。基础设施层包括服务器、电源、网络、存储；资源抽象层包括虚拟化集群、分布式存储、软件定义网络；业务运行层包括虚拟机、容器与业务应用；运维观测层包括监控、日志、告警与自动化恢复。每一层都需要独立的冗余与切换机制，任何一层缺失都会拉低整体可用性。

四条设计原则

冗余：任何可能失效的部件都要有成对或 N+1 配置。电源、风扇、网卡、上行链路、存储节点、管理网络都应成对出现。冗余不是简单“多买一个”，而是要让两条路径在物理上分离，例如双电源分别接入不同 PDU，双上行分别接入不同交换机。

隔离：故障域要尽量小。通过 NUMA 绑定、CPU 亲和性、SR-IOV 或独立网卡，把关键业务与普通业务分开；通过 VLAN、VRF 或独立存储网络，把管理流量、业务流量和存储流量隔离，避免某一类流量突发拖垮整机。

可观测：没有观测就没有高可用。至少应采集 CPU 温度与功耗、内存 ECC 错误计数、PCIe 链路降速、网卡丢包与错包、NVMe 介质磨损、集群心跳延迟等指标。以内存为例，若 EDAC 报告 correctable error 持续增长，说明某条 DIMM 正在劣化，应在它变成 uncorrectable error 之前安排更换。

可恢复：恢复动作要预先定义并尽量自动化。例如，当集群检测到某节点心跳丢失超过 30 秒，自动将其上的虚拟机在剩余节点重启；当监控发现某块 NVMe 延迟超过阈值，自动将该盘标记为待更换并触发数据重建。恢复流程必须经过演练，否则真实故障时容易因权限、脚本或依赖问题失败。

一个可参考的起步配置示例

假设要搭建一套面向内部业务的高可用虚拟化平台，初期规模为 3 台服务器，承载约 60 台虚拟机。可采用如下示例配置（参数为教学假设，实际需按业务压测调整）：

这套配置的可用性逻辑是：单台服务器整机故障时，虚拟化集群在剩余两台节点上重启虚拟机，业务在数分钟内恢复；单块 NVMe 故障时，分布式存储通过副本重建数据，业务无感知；单台交换机或单路电源故障时，网络与供电自动切换到备用路径。真正需要警惕的是“看似冗余、实则共享”的情况，例如两台交换机共用同一路电源，或三副本数据实际落在同一台服务器的不同磁盘上。