2. AMD EPYC硬件架构与可靠性特性

要让业务连续性在服务器层面真正落地，必须先理解AMD EPYC处理器在硬件架构上提供了哪些“可被利用的可靠性抓手”。EPYC不是一颗简单的多核CPU，而是一个由多个计算芯粒（CCD）与一个中央I/O芯粒（IOD）通过Infinity Fabric互连而成的SoC化处理器。这个架构决定了内存通道、PCIe通道、缓存层级与RAS特性之间的耦合关系，也决定了故障发生时系统能够隔离到什么粒度。

核心架构：CCD、IOD与Infinity Fabric

以EPYC 9004系列（代号Genoa）为例，一颗处理器内部通常包含最多12个CCD，每个CCD集成8个Zen 4核心、32MB L3缓存，以及对应的L2/L1缓存。所有CCD通过Infinity Fabric连接到中央IOD。IOD承担内存控制器、PCIe控制器、安全处理器（PSP）、系统管理单元（SMU）以及芯片间互连（xGMI）等职责。这种“计算与I/O分离”的设计带来两个直接后果：一是内存与PCIe的物理资源集中在IOD，便于统一做ECC与错误上报；二是CCD之间不直接通信，任何跨CCD的缓存一致性流量都要经过IOD，因此Infinity Fabric的链路健康度直接影响业务连续性。

Infinity Fabric在EPYC上分为三类链路：CCD到IOD的片内链路、Socket内IOD到IOD的链路（部分型号）、以及双路系统中Socket之间的xGMI链路。xGMI通常以16 GT/s或更高速率运行，支持重传与链路级CRC。当某条xGMI链路出现持续错误时，SMU可以触发链路降速或隔离，避免错误扩散到上层业务。这一点在双路数据库、虚拟化集群中尤为关键：跨Socket内存访问延迟上升，但业务不会直接崩溃。

内存通道与ECC：业务连续性的第一道防线

EPYC 9004提供12个DDR5内存通道，每通道支持2个DIMM（2DPC），典型配置为每通道1条DIMM以获得最佳频率。每个通道由独立的UMC（统一内存控制器）管理，支持ECC。EPYC的ECC采用SEC-DED（单比特纠错、双比特检错）机制：单比特错误在读取时被自动纠正，系统继续运行；双比特错误触发不可纠正错误（UE），通常导致机器检查异常（MCE）。

对业务连续性而言，关键不是“有没有ECC”，而是“错误如何被上报与处理”。在Linux下，可通过EDAC子系统观察：

# 查看内存CE/UE计数
grep -H . /sys/devices/system/edac/mc/mc*/ce_count
grep -H . /sys/devices/system/edac/mc/mc*/ue_count

# 查看具体DIMM的CE分布
grep -H . /sys/devices/system/edac/mc/mc*/dimm*/dimm_ce_count

若某条DIMM的CE计数在短时间内快速增长（例如每小时超过100次），说明该内存颗粒正在劣化，应在计划窗口内更换。若出现UE，则需立即评估是否触发内存镜像切换或节点下线。EPYC支持内存镜像（Memory Mirroring），通常以通道为单位成对镜像：写入时同时写入主通道与镜像通道，读取时从主通道读取；当主通道出现UE时，从镜像通道恢复。镜像会牺牲约50%可用容量，因此适合对可用性要求极高、容量可妥协的场景，如核心数据库或控制节点。

PCIe通道与AER：I/O路径的故障隔离

EPYC 9004提供128条PCIe 5.0通道，可拆分为x16、x8、x4等宽度，用于连接GPU、NVMe、网卡与CXL设备。PCIe链路本身具备CRC与重传机制，但更上层依赖AER（Advanced Error Reporting）。AER将错误分为可纠正错误（Correctable）、不可纠正非致命错误（Non-Fatal）和不可纠正致命错误（Fatal）。

实际运维中，可纠正错误通常表现为链路重传增加，业务无感；但若某条链路的可纠正错误持续增长，说明信号完整性或设备固件存在问题。可通过以下方式观察：

# 查看PCIe AER错误统计
lspci -vvv | grep -A 20 "Advanced Error Reporting"

# 使用rasdaemon记录AER事件
ras-mc-ctl --errors
journalctl -u rasdaemon | grep -i aer

当出现不可纠正非致命错误时，内核可能尝试复位该PCIe设备；若复位失败，则设备被隔离，依赖该设备的业务需切换到冗余路径。因此，在业务连续性设计中，网卡与NVMe应尽量采用双端口或双卡冗余，避免单条PCIe链路成为单点。

Infinity Fabric与xGMI的容错行为

Infinity Fabric的可靠性设计包括链路级CRC、重传与降速。以双路EPYC为例，两颗CPU之间通过xGMI链路互连，典型配置为4条xGMI链路。当某条链路出现持续错误时，SMU可将其降速或标记为不可用，剩余链路继续承载跨Socket流量。此时跨Socket内存访问带宽下降，但系统不会立即宕机。运维上可通过以下方式观察xGMI状态：

# 查看xGMI链路状态与错误计数
ls /sys/class/amd_xgmi/
cat /sys/class/amd_xgmi/xgmi*/link_status
cat /sys/class/amd_xgmi/xgmi*/error_count

若发现某条xGMI链路错误计数持续上升，应检查CPU插槽接触、散热与BIOS版本，必要时在维护窗口重启或更换CPU。对于延迟敏感型业务，跨Socket访问本身就会带来额外延迟，因此更稳妥的做法是将关键业务绑定在单Socket的NUMA节点内，减少对xGMI的依赖。

把硬件RAS特性转化为业务连续性策略

理解上述架构后，业务连续性策略可以落到具体配置上。以下是一份可参考的检查清单，用于在EPYC服务器上线前确认RAS能力已正确启用：

需要强调的是，硬件RAS特性只能降低故障概率、缩小故障域，不能替代上层冗余。ECC纠正单比特错误，但双比特错误仍可能导致进程终止；内存镜像可应对通道级UE，但无法应对整颗CPU失效；PCIe AER可隔离设备，但业务仍需多路径。因此，EPYC的架构与RAS特性应被视为业务连续性栈的底层基础，与操作系统、虚拟化层、应用层的冗余机制配合使用，才能形成完整的故障切换能力。