1. 引言
EPICS (Experimental Physics and Industrial Control System)作为分布式控制系统的行业标准，在粒子加速器、同步辐射光源及大型核聚变装置等领域发挥着核心作用。在其架构中，IOC (Input/Output Controller)作为连接底层硬件与上层应用的关键中间层，通过Channel Access (CA)协议向上层暴露PV (Process Variable)，实现设备数据的采集与控制指令的下发。然而，在像全超导托卡马克(EAST)这样对运行时间要求极高的国家级大型实验装置中，IOC往往需要长期高负载运行。一旦发生故障，不仅会导致控制数据丢失、设备失控，更可能直接中断宝贵的实验窗口。因此，在EPICS控制系统中建立一套高可靠性、状态完整的IOC冗余机制，以保障实验的连续性和系统的安全性，是至关重要的。
现有的EPICS IOC冗余技术方案主要包括传统硬件冗余方案和基于网络协议的冗余方案。其中，传统硬件冗余方案(如双机热备Active/Standby架构)依赖专用硬件实现故障切换与状态同步，具有高可靠性和配置简便的优点，但硬件成本较高、系统扩展性差，难以满足大型科研装置中多节点控制系统的灵活部署需求。基于网络协议的冗余方案(如利用PROFINET实现的冗余控制系统)能够在I/O层面实现数据冗余和链路保护，具有较好的实时性与兼容性，但在IOC层的状态同步和故障切换机制上仍不完善，一旦控制进程发生故障，系统无法快速恢复，存在控制中断与数据丢失风险。
针对上述不足，本文提出了一种基于高可用集群的EPICS IOC冗余系统设计。该方案以Pacemaker 和Corosync作为集群调度与通信框架，结合ETCD的分布式锁机制和DRBD的块级数据同步技术，实现主备节点间的自动切换与数据一致性保障。同时，引入EPICS平台中的关键工具Autosave与Archiver Appliance，分别负责PV (Process Variable)实时值的保存与历史数据的归档存储，从而在控制层与数据层双重保障系统的稳定运行[1]。
2. 系统架构
冗余技术是一种通过引入额外设备或资源，以提升系统可靠性与运行安全性的常用手段[1]。在本设计中，IOC冗余指的是：当主节点发生故障或IOC服务中断时，备用服务器能够自动接管控制任务并启动对应的IOC实例；一旦主节点恢复正常，备用节点则自动终止自身的IOC服务，恢复由主节点对外提供的控制功能。
本系统基于两台配置一致的DELL PowerEdge R740服务器与一台联想服务器构建，运行环境为CentOS 8.5操作系统，集成了Pacemaker 2.1、Corosync 3.1、Autosave R5和Archiver Appliance 2.0等关键软件组件，围绕EPICS IOC冗余方案展开系统性的设计与实现[1]。图1展示了该系统的整体架构：节点1与节点2分别承担主、备角色，均部署有功能相同的IOC、Autosave和Archiver Appliance服务模块，协同对外提供设备控制与数据归档能力；节点3部署ETCD服务器，用作分布式键值存储组件，负责协调集群中资源的运行状态与访问控制。
为实现主备节点之间的状态一致性，系统采用DRBD (Distributed Replicated Block Device)进行块级数据实时同步，确保关键控制数据在切换过程中的完整性与一致性。systemd作为现代Linux系统中的服务管理框架，负责服务单元的启动流程、生命周期管理及依赖控制。在本系统中，IOC、Autosave与Archiver Appliance等关键服务均被注册为systemd管理单元，并与Pacemaker集群调度机制集成，实现服务的统一启动、运行状态监控与故障自动恢复[2]。
Figure 1. System overall architecture diagram
图1. 系统整体架构图
3. 软件结构
为实现系统功能的模块化与高内聚低耦合设计，本控制系统从功能分工与服务边界出发，整体划分为三个协同运行的核心层级，分别承担集群调度、状态控制以及本地服务管理的职责[3]。图2展示了该系统的软件架构。
Figure 2. System software architecture diagram
图2. 系统软件架构图
Cluster management：通过Pacemaker和Corosync实现高可用感知与资源控制。
State control：ETCD引入基于租约(Lease)的机制，作为集群中资源控制权判断的分布式“锁服务”；DRBD实现主备节点之间的块级数据实时同步，保障关键IOC状态文件与归档数据在切换过程中的一致性与完整性[4] [5]。
Control services：systemd负责统一接管IOC、Autosave 和 Archiver Appliance等服务的启动流程与运行状态反馈；控制服务(IOC、Archiver Appliance、Autosave)被注册为systemd管理的资源单元，通过配套脚本实现服务的自动化启动、状态监控以及故障联动响应，确保运行流程高效、可靠[6]。
3.1. Pacemaker与Corosync架构
Pacemaker与Corosync最初源自传统高可用集群软件Heartbeat，后逐步演化为两个独立的模块。Pacemaker是集群的资源调度核心，负责主节点选举、服务状态监测以及资源接管策略的执行；而Corosync则作为底层通信总线，提供节点间的心跳检测、投票仲裁与状态同步功能，构建起集群内部可靠通信的基础框架[5] [6]。图3展示了Pacemaker与Corosync的核心组件架构，在集群运行过程中，策略引擎(PEngine)会解析集群信息库(Cib)中记录的资源配置与节点状态，生成资源调度图，从而确定资源由哪个节点承担运行职责，即主节点的选定。随后调度图由集群资源管理器(Crmd)分发至各节点，用于协调资源状态维护与调度执行。当某节点被指定为主控节点后，其本地资源代理(Lrmd)将接收资源启动指令，并调用系统注册的systemd服务单元。
3.2. ETCD
Pacemaker与Corosync构建了完整的主节点判定、服务启动、健康检测及故障切换恢复机制。在此基础上，系统进一步引入了ETCD组件，以增强资源控制的可靠性与一致性。ETCD是由CoreOS开发的开源分布式键值存储系统，基于Raft共识算法实现强一致性[7] [8]，并通过租约(Lease)机制为分布式锁控制提供了可靠支撑。
在本系统中，每个受控资源在ETCD中对应一个唯一键。该机制特别适用于两节点集群结构，有效避免因网络异常引发的“双主”(脑裂)问题[1]。具体而言，节点在被Pacemaker调度后不会立即启动服务，而是首先向ETCD发起租约申请：若成功写入对应资源键，视为已获取主控权限，方可进入服务激活流程；若租约申请失败，即使获得调度资格，也不会启动服务，从机制上防止“双主”冲突的发生。
Figure 3. HA cluster architecture diagram
图3. HA集群架构图
3.3. 数据同步
系统的主备节点上分别部署了Autosave和Archiver Appliance软件，其中主节点和备节点上的Autosave和Archiver Appliance软件不会同时运行，仅主节点上的软件处于活动状态。Autosave在IOC启动或重启时，从最近保存的文件中恢复各个PV的值，确保设备控制逻辑的连续性[9]。Archiver Appliance将历史数据根据时间跨度划分至三个独立目录：ST (Short-Term)用于短期缓存，MT (Medium-Term)负责中期数据存储，LT (Long-Term)用于长期归档，支持数据的分层访问与集中管理[10]。
为确保主备IOC数据的一致性，部署时，在每台服务器上预留专用分区作为DRBD设备，并配置DRBD主备节点角色。集群在选举主备节点的同时选举主备DRBD。Autosave与Archiver Appliance的数据目录统一部署在DRBD设备中。运行期间只有主节点能将Autosave与Archiver Appliance的数据写入DRBD设备，DRBD工具自动将主节点上DRBD设备数据同步给备节点的DRBD设备。
3.4. 系统运行流程与状态模型
本系统将系统运行流程抽象为一个有限状态机(Finite State Machine, FSM)。图4详细展示了这一FSM的完整状态转换图。核心状态包括：
① Standby：节点已加入集群但尚未取得主控资格，处于待命状态。
② Primary (idle)：被PEngine选为主节点，但尚未获得ETCD租约，资源未激活。
③ Primary (active)：节点被Pacemaker的PEngine模块选为主节点，但尚未成功获取ETCD租约，资源尚未激活。
④ Failed：因服务启动异常、ETCD不可达、租约失效等问题，节点进入故障状态。
⑤ Terminated：节点因断网、宕机等严重故障彻底失去服务运行资格。
Figure 4. System operational status diagram
图4. 系统运行状态图
系统运行逻辑可分为三个阶段：主控节点选举、主控资源激活、故障检测与切换。以下是典型的一次主控激活过程：
系统初始启动后，各节点处于Standby状态，等待Pacemaker的选举决策。PEngine解析集群状态后，选定某节点为主控节点，该节点随即进入Primary (idle)状态，表示获得调度资格但尚未真正启动资源。
在Primary (idle)状态下，节点通过systemd启动服务单元，进入资源激活流程。控制脚本首先尝试从ETCD获取租约，若租约申请成功，状态转入Primary (active)，表示该节点具备主控权限并正式启动IOC及相关服务。系统运行过程中，节点定期向ETCD续约，若发生租约续约失败、服务运行异常或底层故障(如DRBD挂载失败)，状态将转入Failed。Pacemaker检测到服务异常后，自动发起降级操作(stop service + demote)，回收资源控制权，并重新进入选主流程，调度备用节点接管，完成资源迁移与恢复。若节点遭遇严重系统故障，将直接进入Terminated状态，退出资源参与。
4. 测试与结果
基于第二章的软件架构，本文构建了EPICS IOC冗余控制系统的测试环境，旨在验证系统在主控节点失效场景下的容错能力、主备切换效率以及PV数据一致性保障能力。测试模拟主节点故障，通过网络断开方式触发切换机制，并通过工具持续观察PV状态变化和归档数据同步情况。
4.1. 控制权接管验证
测试开始前，使用EPICS工具camonitor对目标PV变量reduance:sync:test1进行持续监听。图5展示了监听过程中关键日志变化。初始阶段，camonitor成功连接至主节点xgs提供的PV，并持续接收数据。于11:04:55模拟主节点故障(断开网络连接)，客户端立即检测到连接中断，并进入重连状态。最终在11:05:21成功连接至备节点epicstest，其已接管原IOC服务并继续提供相同PV。PV值维持在6.0，与断网前一致，表明服务状态完全恢复，主备切换顺利完成。
本轮测试从故障触发至连接恢复总耗时约25秒，PV数据无明显中断，验证了系统具备良好的切换稳定性和容错能力。
Figure 5. IOC switchover test interface
图5. IOC切换测试界面
4.2. 主备状态可视化展示
系统通过Phoebus工具在人机界面中实时呈现主备角色状态与服务活动情况。图6显示了主备IOC的标识信号。其中，主节点与备节点分别配置状态标识PV：“主IOC”与“备IOC”，便于快速区分角色。此外设置的心跳信号PV可反映服务活动状态：主节点信号呈周期性跳变，表示服务活跃；而备节点心跳信号保持恒定，体现待命状态。通过界面反馈，操作者可直观判断系统当前运行状态及角色归属。
Figure 6. Phoebus interface
图6. Phoebus界面
4.3. 归档数据同步测试
为进一步验证Archiver Appliance的数据同步能力，测试中使用其客户端工具查看PV test的历史归档曲线，图7展示了切换后在备节点上的历史数据查询结果。系统配置中，主备节点各自持有名为test的PV，其中主节点信号呈正弦函数变化，备节点信号为{−1, 1}的阶跃波。测试结果表明，备节点Archiver Appliance成功检索到了主节点生成的PV历史曲线，说明归档数据已顺利完成同步。
图7中存在一个时间段为21:13:17至21:13:45的数据断点，反映了归档服务在主备切换过程中的恢复耗时约30分钟。尽管存在短暂中断，整体数据一致性和历史记录完整性仍保持在可接受范围内，验证了系统的归档可靠性。
Figure 7. Archiver Appliance testing interface
图7. Archiver Appliance测试界面
5. 结论
本文围绕EPICS控制系统中对IOC稳定性与高可用性的核心需求，设计并实现了一种基于Linux高可用集群架构的IOC冗余系统。该系统集成Pacemaker与Corosync集群调度框架、ETCD分布式锁机制、DRBD块级数据同步服务，以及Autosave和Archiver Appliance数据持久化工具，实现了控制资源的自动接管与控制状态、历史数据的一致性保障。
通过多轮故障模拟测试，验证了系统在控制权切换、PV值保持和数据归档同步等方面的稳定性与有效性。结果表明，在网络中断或进程异常等典型故障场景下，系统能够在30 s内完成无人工干预的主备切换，PV数据连续性良好，归档信息无明显中断，具备满足高可靠性控制系统实时性与连续性要求的能力。
基金项目
合肥综合性国家科学中心能源研究院(安徽省能源实验室)项目(Grant No.24KZS304)；国家重点研发计划国家磁约束核聚变能发展研究专项(Grant No.2022YFE03010002和Grant No.2024YFE03020003)。
NOTES
*通讯作者。