服务器集群状态从来不是只看“正常”或“异常”那么简单，它至少包含节点状态、集群整体状态和服务健康状态三个层级，其中运维最该盯住的是“多数派存活”和“是否发生脑裂”。
服务器集群状态有哪些：先分清三个判断层级
很多人一上来就问集群状态有哪些，其实这个问题得分层回答，把集群当成一个团队，节点是成员，整体是团队士气，而业务是最终交付的成果，三者状态相互关联,但监控手段完全不同。
节点级状态：成员本身活着吗
节点状态是集群状态的基础单位，指的是物理机或虚拟机本身的运行情况,常见状态包括：
- 在线（Online）：节点心跳正常，能响应管理请求
- 离线（Offline）：心跳丢失，管理端无法联系该节点
- 降级（Degraded）：节点活着但性能受限，比如磁盘IO飙升、内存耗尽
- 启动中（Joining）：新节点加入集群，尚未完成数据同步
- 离开中（Leaving）：节点正在优雅退出，数据还在迁移
集群级状态：整体还能不能对外提供服务
集群级状态是节点状态的汇总结果，再叠加一致性判断,主要形态有：
- 健康（Healthy）：所有核心组件存活，数据处于同步状态
- 降级（Degraded）：部分节点失效，但多数派仍在，集群继续服务
- 只读（Read-only）：主节点故障，集群自动进入只读保护模式
- 脑裂（Split-brain）：节点间心跳中断，形成两个各自为政的小团体
- 不可用（Down）：成员不足法定人数，集群停止服务
服务级状态：业务视角下的集群表现
节点和集群都正常，不代表业务就是好的，服务级状态关注的是请求成功率、响应时间、队列积压情况，这类状态往往通过负载均衡器或应用性能监控系统捕捉，web服务器集群负载过高”时的连接数激增和超时率上升,就是一个典型信号。
集群节点状态怎么看：从命令行到管理面板的完整路径
Kubernetes 集群的节点查看方式
如果你用的是 K8s，节点状态就是 kubectl get nodes 输出的内容，STATUS 列常见值是 Ready、NotReady、Unknown 和 SchedulingDisabled。
kubectl get nodes kubectl describe node work-node-01
当节点显示 NotReady 时，优先排查 kubelet 是否存活，再查容器运行时（containerd）的状态。SchedulingDisabled 则说明节点被主动维护，不会调度新 Pod。
传统高可用集群的心跳查看方式
以 Pacemaker 和 Corosync 为代表的传统集群,看节点状态用一行命令：
pcs status crm_mon -1
输出里的 Online、Standby、Offline 直接告诉你每个节点的心跳情况。pcs status 里还有一个容易被忽略的细节Failed Actions，历史上失败的资源操作都会记录在这里,它往往比当前在线状态更能暴露隐患。
存储和数据库集群的独立状态体系
Ceph 存储集群有自己的一套健康状况说法，执行 ceph -s 后能看到 HEALTH_OK、HEALTH_WARN 或 HEALTH_ERR。HEALTH_WARN 不等于不能用，比如某块盘接近写满，但业务还在跑,这时候重点看告警列表里到底挂了几条。
MySQL 的 Group Replication 则通过 performance_schema 表来展示成员状态,执行以下语句可以看到每个节点的读写状态：
SELECT FROM performance_schema.replication_group_members;
ONLINE、RECOVERING、ERROR 三个状态值，覆盖了绝大多数 MySQL 集群的节点判断场景，状态是表象，事务能不能同步才是核心，因此还要接着看 replication_group_member_stats 表。
集群脑裂怎么处理：仲裁机制才是集群状态的守门员
集群状态里最隐蔽也最危险的场景就是脑裂，行业共识认为，脑裂发生的概率不高，但一旦出现，后果往往比多个节点宕机还严重，因为两边都在写数据,恢复时谁的数据都信不过。
脑裂的触发条件是什么
脑裂的本质是心跳通不上，但存储等资源仍然共享，比如交换机某个端口坏了，节点A和节点B之间心跳断了，但两边都能访问同一个共享存储，这时候节点A认为B挂了，节点B认为A挂了,两边同时接管虚拟IP和存储资源。
如何用仲裁机制避免脑裂
直接的办法是引入仲裁设备（QDisk），让第三方来投票，在传统的集群软件里，仲裁盘需要配置 qdisk 和 expected_votes，多数派原则是核心逻辑：只有拿到多数票的节点组才能继续工作，举例说明，3节点集群，法定人数是2，任何一个节点失联，剩余2个节点还能继续服务，如果是2节点集群，就必须额外增加一个仲裁设备,否则一根网线松动就可能导致集群整体停摆。
pcs quorum status corosync-quorumtool -s
上面两条命令能查看当前集群的法定人数配置，你会在输出里看到 Quorum device 的信息，如果这里显示 Not configured,那你的两节点集群其实处在一个很敏感的悬空状态。
脑裂已经发生了怎么办
停掉一侧的集群服务是第一步，保留数据更完整的那一侧，接着手动指定合法的法定人数，把集群拉起，再让另一侧作为新成员重新加入，这里有一个原则需要记住：处理脑裂永远先止损，再恢复，所谓止损，就是抢在两边同时写入之前,先把写操作切断。
服务器集群健康检查到底查什么
健康检查的三个核心维度
服务器集群健康检查是日常巡检里最有价值的部分,它的核心检查点可以拆成三块：
- 心跳与成员关系：节点是否还在集群列表里，成员数量是否等于预期值
- 资源使用与数据同步：CPU、内存、磁盘是否告警，主从之间的复制有没有延迟
- 依赖服务可用性：DNS能不能解析、时间同步有没有偏差、许可证是否即将过期
业内专家指出，很多集群故障发生的第一个信号不是节点宕机，而是时间偏移超过几秒钟，NTP 一旦出问题，集群的认证和日志就会先乱,接着才是心跳失效。
自动巡检怎么做更有效
把健康检查脚本化，比手动敲命令靠谱得多，可以写一个简单的 crontab 检查，每两分钟跑一次 pcs status 并把输出写入日志文件,再配合告警阈值。
/2 crm_mon -1 > /var/log/cluster_status.log 2>&1
真正靠谱的状态监控还要结合第三方的可观测平台，Prometheus 的 node_exporter 配合 Alertmanager 是最常见的组合，它能把“集群节点状态怎么看”这个问题转成一条条可量化的指标,再根据历史基线做异常检测。
状态变化背后藏着什么：从现象看运维重点
节点反复横跳一定是配置问题
有一种很折腾人的状态叫节点 flapping，节点一会儿在线一会儿离线，集群状态不断重排，这种情况多半不是硬件故障，而是心跳超时设置太短，或者网络设备启用了节能模式导致偶发丢包，处理思路是把心跳超时参数从默认的 3 秒放宽到 5 到 8 秒,同时检查交换机的端口缓存。
状态明明正常但业务卡顿，优先查存储
无论是本地机房部署还是云上的托管集群，存储延迟都是最容易被忽略的隐藏变量，数据库集群的状态显示全绿，但业务接口已经慢得不像话，这时候大多不是集群自身出了问题，而是共享存储所在存储网络的带宽被占满，用 iostat 和 ceph -w 这类工具看延迟,比盯着集群状态本身更直接。
web服务器集群负载过高时的处置节奏
当集群状态正常但负载过高时，先看连接数分布是不是倾斜的，用负载均衡器的管理界面观察每个后端的并发连接数，如果某个节点连接数明显高出其他节点，就要检查是不是会话保持策略把流量都拴在了同一个节点上，随后再看 keepalived 或者 LVS 层的健康检查判定阈值，会发现负载均衡器依然认为集群所有节点都是健康的,但其实某些节点已经在超负荷运行。
关于服务器集群状态的常见问题
集群节点状态怎么看能最快定位问题？
先看集群成员数量是否等于预期值，再看 pcs status 或 kubectl get nodes 里有没有非正常节点，最后查心跳日志和系统日志，这三步走完,绝大多数节点异常都能定位到具体原因。
集群状态出现降级要不要马上处理？
降级不等于业务中断，但它是故障的倒计时，如果降级是因为一个节点离线，你得先确认法定人数是否仍然满足，满足的话可以继续观察，但要设一个处理窗口，超过窗口期没恢复就强切，不满足法定人数的降级，必须立刻介入,这种状态随时会升级成集群不可用。
一个节点挂了会影响整个集群吗？
取决于集群架构和已配置的冗余策略，在多数派机制下，3节点集群允许挂1个，5节点集群允许挂2个，但如果是两节点集群，挂掉一个就相当于丢掉了法定人数，集群会主动停止服务，这也就是为什么生产环境里至少会部署3个节点，也是为什么仲裁设备的配置对关键业务如此重要，集群状态永远是为业务服务的，判读状态的核心逻辑只有一条，那就是在这个状态下,数据的完整性和可用性还能不能保住。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/791413.html
