4. 高可用集群基础与EPYC适配

在业务连续性体系中，高可用集群解决的是“单点故障导致服务中断”的问题。它的核心思想不是让硬件永不损坏，而是让故障发生时，服务能在可接受的时间内由其他节点接管。理解集群模式与EPYC平台的适配关系，是后续部署Pacemaker/Corosync或Windows Server Failover Clustering（WSFC）的前提。

主动-被动与主动-主动：两种基本模式

主动-被动（Active-Passive）模式中，同一时刻只有一个节点对外提供服务，其余节点处于待命状态。当主动节点发生故障，集群资源（如虚拟IP、共享存储挂载点、数据库实例）整体迁移到被动节点。这种模式逻辑简单、数据一致性容易保证，适合数据库、文件服务等对写一致性要求高的场景。代价是备用节点在正常情况下不承担业务负载，资源利用率偏低。

主动-主动（Active-Active）模式中，多个节点同时对外提供服务，通常通过负载均衡器将请求分发到各节点。任一节点故障时，剩余节点继续处理请求，容量下降但服务不中断。它资源利用率高、扩展性好，但要求应用本身支持并发访问，或通过共享存储、分布式锁、数据复制来保证一致性。对于无状态Web前端、API网关等场景，主动-主动是更自然的选择。

两种模式并非互斥。实际生产集群常采用混合形态：前端Web层主动-主动，后端数据库层主动-被动。选择哪种模式，取决于应用的有状态程度、数据一致性要求和可接受的恢复时间目标（RTO）。

EPYC平台上的集群适配要点

AMD EPYC处理器在集群部署中有几个需要特别关注的特性。首先是NUMA拓扑。EPYC 9004系列采用Chiplet设计，每个CPU包含多个CCD（Core Complex Die），内存控制器分布在不同的I/O Die上。在主动-主动集群中，如果虚拟机或容器跨NUMA节点调度，可能引入额外的内存访问延迟。建议在BIOS中启用NUMA感知，并在Pacemaker资源代理中通过cpuset或numa-policy参数将关键资源绑定到特定NUMA节点。

其次是SEV-SNP安全加密虚拟化。如果集群运行在EPYC的SEV-SNP加密虚拟机中，实时迁移（Live Migration）需要额外配置。Pacemaker的虚拟IP和共享存储资源本身不受影响，但涉及虚拟机迁移的ocf:heartbeat:VirtualDomain资源需要确保源和目标主机都支持SEV-SNP迁移，否则迁移会失败并触发不必要的故障切换。建议在集群属性中设置migration-threshold，避免因迁移失败反复切换。

第三是PCIe拓扑与设备直通。当集群节点使用GPU或NVMe直通设备时，EPYC的PCIe通道分配会影响故障切换的可行性。被动节点必须具有相同的设备拓扑，否则资源无法在节点间迁移。在规划阶段，应确保所有集群节点的PCIe设备位置一致，或使用设备别名而非固定BDF地址。

Pacemaker/Corosync关键配置

Corosync负责集群成员管理和心跳通信，Pacemaker负责资源调度。在EPYC平台上部署时，以下配置值得关注：

# /etc/corosync/corosync.conf 关键片段
totem {
    version: 2
    cluster_name: epyc-ha
    transport: knet
    crypto_cipher: aes256
    crypto_hash: sha256
    interface {
        ringnumber: 0
        bindnetaddr: 192.168.1.0
        mcastport: 5405
        ttl: 1
    }
    interface {
        ringnumber: 1
        bindnetaddr: 10.0.0.0
        mcastport: 5405
        ttl: 1
    }
}
quorum {
    provider: corosync_votequorum
    expected_votes: 3
    two_node: 0
}

双ring配置利用EPYC平台的多网卡优势，将心跳流量分散到两个物理网络。如果只有一个交换机，双ring仍能防止单网卡故障，但无法防止交换机故障。对于两节点集群，需要配置two_node: 1并配合wait_for_all: 1，否则脑裂时无法正确判定quorum。

Pacemaker资源定义示例：

# 创建虚拟IP资源
pcs resource create VirtualIP ocf:heartbeat:IPaddr2 \
    ip=192.168.1.100 cidr_netmask=24 \
    nic=ens1f0 op monitor interval=10s timeout=20s

# 创建数据库服务资源
pcs resource create DBService systemd:mariadb \
    op monitor interval=15s timeout=30s

# 约束：DBService 与 VirtualIP 同节点
pcs constraint colocation add DBService with VirtualIP INFINITY

# 顺序：先启动IP，再启动DB
pcs constraint order VirtualIP then DBService

# 资源粘性：避免频繁切换
pcs resource defaults resource-stickiness=100

在EPYC平台上，resource-stickiness的设置需要结合NUMA延迟考虑。如果资源迁移到远端NUMA节点会导致性能下降超过30%，可以适当提高粘性值，让集群倾向于在原节点恢复而非立即迁移。

Windows Server Failover Clustering配置要点

WSFC在EPYC平台上的配置与Pacemaker有相似逻辑，但工具链不同。关键步骤包括：验证集群配置、创建集群、配置仲裁、添加角色。

# 验证集群配置（所有节点执行）
Test-Cluster -Node "EPYC-NODE1","EPYC-NODE2" -Include "Inventory","Network","Storage"

# 创建集群
New-Cluster -Name "EPYC-CLUSTER" -Node "EPYC-NODE1","EPYC-NODE2" `
    -StaticAddress "192.168.1.100" -NoStorage

# 配置仲裁（两节点建议使用文件共享见证）
Set-ClusterQuorum -FileShareWitness "\\FS01\Witness"

# 添加文件服务器角色
Add-ClusterFileServerRole -Name "FS-CLUSTER" -Storage "Cluster Disk 1" `
    -StaticAddress "192.168.1.101"

WSFC的仲裁配置对两节点集群尤为关键。EPYC平台通常具有较高的核心数，WSFC的节点投票权重默认按节点计算，不按核心数加权。如果使用云见证或文件共享见证，需确保见证资源所在位置与EPYC节点之间的网络延迟低于5ms，否则可能触发误判。

模式选择与验证方法

部署完成后，必须验证故障切换是否按预期工作。对于主动-被动集群，可以手动触发资源迁移：

# Pacemaker：手动迁移资源
pcs resource move VirtualIP EPYC-NODE2
pcs resource clear VirtualIP

# 查看集群状态
pcs status --full

# WSFC：模拟节点故障
Stop-ClusterNode -Name "EPYC-NODE1"
Get-ClusterGroup

验证时应观察三个指标：切换耗时（RTO）、数据一致性（切换后数据是否完整）、以及切换后性能是否可接受。在EPYC平台上，由于核心数多、内存带宽高，切换后剩余节点通常能承载原负载的60%～80%，具体取决于应用类型。如果切换后性能下降超过预期，需要检查NUMA绑定和网络中断亲和性设置。

主动-主动集群的验证更侧重负载均衡和会话保持。可以使用curl或ab持续发送请求，同时关闭一个节点，观察请求是否全部由剩余节点处理、是否有连接中断。对于有状态服务，还需验证共享存储或数据复制是否在节点故障时保持一致。