1 引言

在共享存储集群中，网络通信与心跳仲裁机制是保障集群高可用性的最后一道防线。无论缓存融合技术多么高效、存储管理多么完善，一旦集群节点间的通信出现故障，所有节点都可能误以为自己是“唯一幸存者”，从而同时操作共享数据——这就是著名的脑裂（Split Brain） 问题。
脑裂的本质是：集群中节点间通过心跳机制了解彼此的健康状态，当只有“心跳”出现问题而各个节点还在正常运行时，每个节点都认为其他的节点宕机了，自己才是整个集群环境中的“唯一健在者”，应该获得整个集群的控制权。多个无法协调的系统同时使用共享数据，会导致数据的不一致甚至损坏。
因此，一个设计完善的心跳仲裁机制，是共享存储集群必须具备的核心能力。Oracle RAC与达梦DSC在这一领域给出了两种不同的答案——前者采用双心跳+多数派算法，后者采用单心跳+控制节点选举。本文将深入对比这两种机制的底层原理与设计哲学。

2 Oracle RAC的心跳仲裁机制

2.1 CSSD：集群的“智能保安”

Oracle RAC的心跳仲裁机制由CSSD（Cluster Synchronization Services Daemon） 进程承载。CSSD运行在每个RAC节点上，是Oracle Clusterware中最核心的后台进程之一。
CSSD的职责可以概括为四个层面：
节点监控：监听其他节点是否在线
状态判断：判断自己是否还能“安全地存在于集群中”
超时判定：检查Voting Disk是否可写、是否超过超时
自我保护：在特定条件下主动让节点重启，避免脑裂
CSSD的运作可以形象地理解为“集群中的智能保安”——它一直在监听：“我是不是还能和大家说话？”“我是不是还能在共享笔记本上签字？”“别人还在吗？我是不是一个人了？”一旦它发现自己可能“误入另一个平行宇宙”，就会立刻喊一句“我走了”，然后关机自保。

2.2 双心跳机制：网络心跳 + 磁盘心跳

Oracle CSS提供两种互相独立的心跳机制：
（一）网络心跳（Network Heartbeat）
每个节点的CSSD进程的一个线程每秒通过私有网络（Interconnect）发送一个TCP协议心跳信号给RAC集群中的所有节点（包括自己）。网络心跳用于检测节点间的连通性。
网络心跳的超时阈值由misscount参数控制，默认值为30秒。当某个节点连续丢失网络心跳达到misscount设定的时间，就会被踢出集群。
（二）磁盘心跳（Disk Heartbeat）
每个节点的CSSD进程在Voting Disk（表决磁盘） 的特定位置通过读写数据维持心跳信号。每个节点每秒都会向Voting Disk写入本节点的状态信息。同时，CSS还会每秒读取一种称作“kill block”的“赐死块”——当“kill block”的内容表示本节点应被驱逐时，CSSD会触发节点重启。
磁盘心跳的超时阈值由disktimeout参数控制，默认为200秒。
（三）本地心跳（Local Heartbeat）
除了网络心跳和磁盘心跳这两种节点间的通信机制外，Oracle还提供了一种节点内部的自检机制——本地心跳（Local Heartbeat，LHB） 。
本地心跳的作用是监控节点自身的健康状况，确保本地的集群软件栈（Clusterware Stack）仍在正常运行。它解决的是一个容易被忽视的问题：节点“僵死”（hung）但网络心跳却还在发送的异常情况。如果一个节点的操作系统或关键进程已经卡死，但其网络端口仍然是打开的，其他节点可能无法通过网络心跳超时来及时驱逐它，从而形成脑裂风险。
本地心跳的运作机制是：节点的关键进程（如LMD、LMS等）必须定期向本地监控进程“报到” ，重置看门狗（Watchdog）计时器。具体而言，OCSSD进程在每秒向远端节点发送网络心跳的同时，会通过同一进程将本地OCSSD进程的状态发送给cssdagent和cssdmonitor两个代理进程。这两个代理进程负责监控本地节点的关键资源和OCSSD.bin进程的健康状态。
如果本地监控进程在预定时间内没有收到某个关键进程的“报到”，就认为本地的集群软件出现了严重问题。此时，节点会主动发起自我终止（Suicide） ，触发节点重启。这是一种“舍小保大”的策略——牺牲一个不健康的节点来保全整个集群的完整性。
本地心跳与网络心跳的一个重要关联是：由于本地心跳和网络心跳都是由相同的线程来发送的，所以二者的延迟时间默认是一致的（均为30秒的misscount阈值）。
网络心跳负责发现“别人死了”，磁盘心跳负责在“大家都说自己活着”时裁定谁该活，本地心跳则负责确认“自己还活着” ——三者共同构成了Oracle RAC从节点间到节点内的全维度健康监控体系。

2.3 Voting Disk与多数派算法

当网络分裂导致集群出现多个子集群（脑裂）时，Oracle通过Voting Disk的多数派算法（Quorum Algorithm） 进行仲裁。
仲裁的核心规则是：能够抢占到超过半数（N/2 + 1）Voting Disk的节点分区可以继续存活（survive），未能抢到的分区则被驱逐出集群。
这就是为什么Oracle建议配置奇数个（1、3、5个）Voting Disk——偶数个Voting Disk在发生故障时可能无法形成多数派。
典型仲裁场景：
以配有3个Voting Disk的双节点集群为例：当磁盘心跳出现问题时，节点1可以访问2个Voting Disk，节点2只能访问1个。基于简单多数原则，节点1（持有2个Voting Disk）会发出指令将节点2踢出集群。
对于三节点集群，当节点3与另外两个节点的网络心跳中断，但所有节点仍能正常写入Voting Disk时，节点1和节点2会更新Voting Disk上节点3的kill block状态，节点3的CSSD读取后知道自己应退出集群并主动关闭。

3 达梦DSC的心跳仲裁机制

3.1 DMCSS：合二为一的集群控制

达梦DSC的心跳仲裁机制由DMCSS（Dameng Cluster Synchronization Services，达梦集群同步服务） 承载。与Oracle将集群同步（CSS）和资源管理（CRS）分离的设计不同，DMCSS同时承担节点管理和资源管理两大职责。
每个DMDSC节点都需要运行一个DMCSS服务，这些DMCSS服务自身也构成一个集群。DMCSS集群中存在两种角色：
控制节点（Control Node） ：负责监控和管理整个DMASM集群和DMDSC集群
普通节点（Normal Node） ：不参与集群管理，仅作为候选，当控制节点故障时被选举为新的控制节点

3.2 单心跳机制：基于VOTE磁盘的磁盘心跳

与Oracle的双心跳不同，达梦DSC的心跳机制只有磁盘心跳（Disk Heartbeat），没有独立的网络心跳。
DMCSS的心跳工作原理如下：
在VOTE磁盘（非镜像环境）或DCRV磁盘（镜像环境）中，为每个被监控对象（DMASMSVR、DMSERVER、DMCSS）分配一片独立的存储区域
被监控对象每间隔1秒向VOTE磁盘写入心跳信息，包括时间戳、状态等
DMCSS控制节点定时从VOTE磁盘读取所有被监控对象的心跳信息，检查状态变化并启动相应的处理流程
被监控对象只会被动接收DMCSS控制节点的命令，执行并响应
这种设计的核心特征是 “单向心跳、集中裁决” ——所有节点只向VOTE磁盘写入，由控制节点统一读取和裁决。

3.3 控制节点选举机制

DMCSS控制节点的选举遵循以下原则：
先启动优先：先启动的DMCSS作为控制节点
节点号小优先：如果DMCSS同时启动，选择节点号小的节点为控制节点
故障后重选：如果DMCSS控制节点挂掉，将先向VOTE磁盘写入心跳信息的节点设置为新控制节点；若同时有多个节点先写入，选择节点号小的节点
DMDSC集群有且只有一个控制节点，其他都是普通节点。

3.4 VOTE磁盘的双重角色

达梦的VOTE磁盘在功能上比Oracle的Voting Disk承担了更多的职责：
心跳检测：记录集群成员信息，通过VOTE磁盘进行心跳检测，确定集群中节点的状态，判断节点是否出现故障
脑裂仲裁：当集群中出现网络故障时，使用VOTE磁盘来确定哪些DMDSC节点被踢出集群
命令传递：在集群的不同状态（启动、节点故障、节点重加入等）下，DMCSS通过VOTE磁盘传递控制命令，通知节点执行相应操作
达梦的VOTE磁盘只能配置一个，且仅支持存放在裸设备上。

3.5 第三方IP仲裁机制（DMDCR_LINK_CHECK_IP）

在仅依赖VOTE磁盘心跳的仲裁机制下，达梦DSC存在一个潜在问题：当2节点DSC集群节点间出现MAL网络异常时，如果两个节点实例都正常运行，DMCSS的默认处理逻辑是主动HALT节点号大的节点，保留节点号小的节点。这种“节点号小优先”的规则在网络故障时可能导致错误的节点被踢出——例如，如果实际是节点号小的节点（DSC0）与应用网络的连接中断了，而节点号大的节点（DSC1）与应用网络的连接是好的，按照默认规则，DMCSS反而会踢掉DSC1，保留无法对外提供服务的DSC0。
为了解决这一问题，达梦引入了DMDCR_LINK_CHECK_IP参数——第三方确认机器的IP。
（一）参数定义
DMDCR_LINK_CHECK_IP是一个可选参数，仅适用于Linux环境。它指定一个DMDSC集群各节点均可访问到的、集群环境之外的、一台独立外网机器的IP地址。配置该参数后，各DMSERVER节点通过联通确认机器IP来检测外网是否畅通。
配置完成后，需要为DMSERVER、DMASMSVR（非DMASM镜像环境）和DMASMSVRM（DMASM镜像环境）赋予ping权限来完成联通功能。具体命令如下：

# DMSERVER赋权
sudo setcap cap_net_raw,cap_net_admin=eip /opt/dmdbms/bin/dmserver

# DMASMSVR赋权
sudo setcap cap_net_raw,cap_net_admin=eip /opt/dmdbms/bin/dmasmsvr

# DMASMSVRM赋权（DMASM镜像环境）
sudo setcap cap_net_raw,cap_net_admin=eip /opt/dmdbms/bin/dmasmsvrm

（二）工作原理
DMDCR_LINK_CHECK_IP成功配置之后，当集群中出现节点间MAL网络异常时，节点不仅依赖VOTE磁盘进行仲裁，还需要尝试联通DMDCR_LINK_CHECK_IP配置的IP（类似于ping功能） 。DMCSS将MAL链路状态与第三方IP联通结果共同作为处理网络异常的参考依据。
典型应用场景如下：
DSC0与第三方确认IP无法联通，DSC1与第三方确认IP可以联通
DMCSS综合判断后，主动HALT掉DSC0节点，保留正常的DSC1节点
这一机制有效避免了默认“节点号小优先”规则在特定网络故障场景下的误判。

4 心跳仲裁机制对比总结

两种机制的核心差异：
Oracle RAC采用“分布式、多冗余、去中心化” 的设计思路——三重心跳提供多条独立的故障检测路径，多Voting Disk确保任一磁盘损坏不影响集群决策，多数派算法在网络分裂时自动裁定存活分区，IO Fencing实现物理层面的数据保护。这种设计追求的是在极端故障场景下的最高可靠性——即使部分网络中断、部分Voting Disk损坏，集群依然能够正确仲裁。
达梦DSC采用“集中式、单路径、中心化” 的设计思路——单一VOTE磁盘心跳检测节点状态，控制节点集中裁决，同时通过第三方IP仲裁（DMDCR_LINK_CHECK_IP） 弥补单心跳机制在网络故障场景下的判定精度。VOTE磁盘同时承担心跳检测、脑裂仲裁、命令传递三重职责。这种设计追求的是部署简洁与管理可控，同时通过第三方仲裁机制增强了网络分区场景下的故障判定能力。
两种设计各有取舍。Oracle的多冗余机制在极端故障场景下提供了更强的容错能力；达梦的集中式设计配合第三方仲裁，在保持部署简洁的同时有效避免了特定网络故障场景下的误判问题。
https://eco.dameng.com