故障现象与quorum机制的本质
RHEL集群中，quorum（仲裁）是防止脑裂的关键机制。当节点之间的通信中断或节点数量不足以形成多数派时，集群会丢失quorum。此时用pcs status查看，通常会看到类似Current DC: NONE、No quorum的提示，所有资源都处于停止状态，集群拒绝启动任何服务。很多管理员第一次遇到时会误认为节点宕机，实际上节点可能全部在线，只是心跳网络或投票配置出了问题。
在corosync层面，quorum由votequorum服务提供。默认规则是：集群中存活节点数必须大于总节点数的一半（即expected votes的50%以上）才能拥有quorum。例如三节点集群失去一个节点后还剩两个，依然满足多数派；但两节点集群失去一个后就只剩一个，不满足半数以上，因此双节点集群必须额外配置仲裁设备（如qdevice）才能正常工作。此外，如果管理员手动修改过expected_votes或使用了two_node: 1等特殊配置，也会导致quorum判断异常。
确认当前quorum状态最直接的命令是corosync-quorumtool -s，它会输出Quorate: No或Yes，同时显示成员节点和投票数。另一个重要命令是pcs quorum status，它整合了pacemaker视角的仲裁信息。如果看到Quorum: No，说明pacemaker认为当前没有仲裁，资源会被冻结。
排查步骤：从心跳到投票的逐层检查
首先检查集群成员状态。运行pcs status nodes查看所有节点是否在线、是否被标记为UNCLEAN或OFFLINE。如果某个节点显示OFFLINE但实际机器在运行，可能是该节点的corosync进程挂了或网络被防火墙阻断。此时登录该节点执行systemctl status corosync，并检查/var/log/cluster/corosync.log中的错误。常见原因包括：心跳网卡down、UDP端口5405/5406被过滤、节点时间不同步导致token超时等。
其次检查corosync配置文件/etc/corosync/corosync.conf中的quorum部分。重点看provider: corosync_votequorum是否启用，expected_votes是否等于实际节点数（包括将来要加入的节点），以及双节点场景下是否有two_node: 1。配置错误会导致投票总数计算错误。例如三节点集群但expected_votes: 4，那么即使三节点全部存活也只获得3票，不足4的半数（2票？注意规则是存活节点数大于总票数的一半，即大于2，3>2应该满足，但corosync的判断是votes >= expected_votes/2 + 1，对于4票需要至少3票，3票满足，所以可能不会有问题。但若expected_votes设成5，则需要至少3票？5/2+1=3.5取整为4？实际corosync要求total_votes > expected_votes/2，也就是存活节点所持有的票数之和必须严格大于expected_votes的一半。如果expected_votes=5，半数=2.5，存活节点票数至少3才行。如果实际只有2个节点存活且每个节点1票，则2>2.5为假，丢失quorum。所以配置错误确实会导致仲裁丢失。）务必核对准确。
如果集群曾使用qdevice或qnetd作为第三方仲裁，要检查qdevice服务是否正常运行。执行pcs qdevice status查看qdevice是否在线，以及它的投票是否被计入。qdevice通常部署在独立主机上，通过corosync-qdevice服务提供额外的一票。当双节点集群中一个节点宕机时，存活节点加上qdevice的票就能满足多数派。如果qdevice网络不通或证书过期，存活节点将无法获得qdevice的投票，从而丢失quorum。
临时恢复与永久修复方案
在紧急情况下，如果确认所有节点本身健康但quorum因配置或短暂网络抖动丢失，可以临时手动授予quorum。使用命令corosync-quorumtool -e 1可以强制设置期望票数为1，但这个方法会绕过安全机制，仅适用于测试环境或确认不会发生脑裂的场景。更规范的做法是使用pcs quorum expected-votes 1来调整期望票数，这样即使只剩一个节点也能获得仲裁。操作完成后需要尽快恢复正确配置，否则集群失去防护能力。
对于双节点生产集群，推荐配置qdevice。在两节点上都安装corosync-qdevice，然后在一台独立主机（可以是虚拟机或物理机，但不要与集群节点同机）上安装corosync-qnetd并启动服务。然后在集群节点上执行pcs quorum config相关命令将qdevice加入集群。配置完成后，qnetd会监听5403端口，qdevice进程会自动连接并参与投票。验证命令pcs quorum status应显示三个投票来源（两个节点各一票，qdevice一票）。这样即使一个节点完全宕机，另一个节点加上qdevice也能达到多数派（2票>1.5），集群可以继续运行资源。
如果集群规模较大（例如五节点以上），丢失quorum往往是多个节点同时故障或网络分区导致。此时首先要恢复节点间的网络连通性，然后观察corosync自动重建成员关系。切忌在分区情况下手动强制启动资源，否则可能造成数据不一致。可以使用pcs cluster stop --all先停止所有节点，再逐个启动，确保成员列表干净。对于反复出现quorum丢失的环境，建议检查交换机配置、网卡驱动、以及corosync的token超时参数（默认1000ms，可适当调大到3000ms以容忍网络抖动）。
最后展示一个排查过程的命令序列示例：
# 查看集群总体状态 pcs status # 查看quorum详细信息 corosync-quorumtool -s pcs quorum status # 查看节点成员 pcs status nodes # 检查corosync配置中的quorum段落 grep -A5 'quorum' /etc/corosync/corosync.conf # 临时调整期望票数（谨慎使用） pcs quorum expected-votes 1 # 恢复为实际节点数 pcs quorum expected-votes 2 # 配置qdevice（双节点集群） pcs quorum config pcs qdevice setup model net --enable --start pcs qdevice status net
通过以上步骤，管理员可以系统化地定位RHEL集群quorum丢失的根因，并选择临时或永久方案恢复集群可用性。日常运维中建议定期检查corosync日志和qdevice健康状态，避免因小问题积累导致大面积仲裁故障。