CentOS高可用通过Pacemaker和Corosync构建集群，实现故障自动切换。Corosync负责节点通信与仲裁，Pacemaker监控并管理服务资源，确保业务连续性。需配置时间同步、主机解析和防火墙规则，安装pcs工具简化管理。核心机制包括资源代理、约束规则及STONITH防脑裂，后者通过硬件强制关闭故障节点，保障数据一致性。共享存储可选SAN（高性能）或NAS（易部署），根据场景选择GFS2/OCFS2或NFS方案，确保数据跨节点一致访问。

CentOS高可用性的实现，核心在于构建一个能自动检测并响应故障的集群系统，通常我们会利用Pacemaker和Corosync这两大开源组件来达成这个目标。它确保了当集群中的某个节点（服务器）出现问题时，关键服务能够迅速、无缝地切换到其他健康的节点上继续运行，从而最大限度地减少业务中断时间。这不仅仅是软件的部署，更是一套关于系统弹性、数据一致性以及故障恢复策略的整体考量。

实现CentOS高可用，我们通常会围绕一套成熟的开源技术栈进行构建，这套栈的核心是Pacemaker和Corosync。Corosync，你可以把它想象成集群的“心跳”和“神经系统”，它负责集群成员的管理、节点间的消息传递以及仲裁决策，确保所有节点对集群状态有统一的认知。Pacemaker则在此基础上，作为“大脑”和“执行者”，它监控着各种服务的状态，并在检测到故障时，根据预设的规则，执行一系列恢复动作，比如将虚拟IP地址、文件系统挂载点或具体的应用程序服务从故障节点转移到正常运行的节点上。

搭建一个基础的双节点高可用集群，至少需要两台CentOS服务器，它们之间需要稳定且低延迟的网络连接。在动手之前，有几个基础工作是必须的：确保所有节点的时间同步（NTP是不可或缺的），主机名能够正确解析（可以通过

/etc/hosts

或DNS），以及防火墙规则已经配置好，允许Corosync和Pacemaker所需的端口通信（例如Corosync的UDP 5405，以及Pacemaker用于管理通信的TCP 2224）。

安装Pacemaker和Corosync软件包是启动集群的第一步。在CentOS上，这通常通过

yum install pacemaker corosync pcs

命令来完成。

pcs

（Pacemaker/Corosync Configuration System）是一个非常实用的命令行工具，它极大地简化了Pacemaker集群的配置和管理工作。

配置Corosync集群需要定义节点列表、选择合适的传输协议（通常是

totem

）以及设定仲裁策略。一个健康的Corosync集群能够确保即使部分节点失联，剩余的节点也能做出正确的决策。Pacemaker的配置则更为精细，它涉及到资源的定义（例如，一个虚拟IP地址、一个共享文件系统、一个数据库服务或一个Web服务器），这些资源是集群需要保护的对象。此外，还需要定义资源约束（比如指定资源在哪个节点运行、它们的启动顺序、是否需要共置）以及STONITH（Shoot The Other Node In The Head）设备的配置。STONITH是高可用集群中一个至关重要的组成部分，它通过物理手段（如远程电源控制）强制关闭故障节点，以彻底避免“脑裂”（Split-Brain）问题，确保数据的一致性。

在实际搭建过程中，STONITH的正确配置往往是一个难点。没有有效且可靠的STONITH机制，集群在面对某些特定故障场景时可能会变得不可靠，甚至导致数据损坏。这需要根据你的硬件环境选择合适的STONITH代理，例如IPMI（智能平台管理接口）、Fence_agents等，并进行充分的测试。

一旦集群的基础框架搭建完成，接下来的任务就是定义哪些服务需要实现高可用。这可以是Nginx Web服务器、MySQL或PostgreSQL数据库、NFS共享服务，甚至是自定义的应用程序。Pacemaker通过“资源代理”（Resource Agents）来管理这些服务。这些代理是符合OCF（Open Cluster Framework）标准的脚本，它们定义了如何启动、停止、监控以及清理特定资源。

举个例子，为集群中的一个虚拟IP地址设置高可用资源：

pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=10s

这条命令会创建一个名为

VirtualIP

的资源，它是一个虚拟IP地址，集群会每10秒监控一次它的状态。如果发现问题，Pacemaker会尝试修复或将其迁移到其他节点。

对于一个需要高可用的文件系统，例如NFS共享的挂载点：

pcs resource create NFSShare ocf:heartbeat:Filesystem device="/dev/vg0/lv_nfs" directory="/mnt/nfs" fstype="xfs" op monitor interval=20s

这确保了在节点故障时，NFS共享的文件系统能够被正确地卸载并重新挂载到健康的节点上。

理解每个资源的

op monitor

操作至关重要，它决定了Pacemaker如何判断资源是否健康。如果监控操作失败，Pacemaker就会根据预设的策略尝试重启或迁移资源。

Huemint

推荐！用ai自定义和谐配色

53

查看详情

CentOS高可用集群中“脑裂”问题如何避免？

“脑裂”（Split-Brain）是高可用集群中最令人头疼的故障模式之一，它指的是当集群节点间的通信链路出现问题时，每个节点都错误地认为其他节点已经下线，从而各自独立地启动服务并尝试访问共享资源。这种情况下，不同的节点可能会对同一份数据进行修改，导致数据不一致甚至损坏，最终服务也可能陷入混乱。

避免脑裂的核心策略是确保集群始终只有一个主导者，这通常通过“多数原则”和“STONITH机制”来协同实现。

多数原则是指集群中的节点在做出任何关键决策（比如启动服务）之前，必须获得集群中大多数节点的“投票”。Corosync在集群通信层面上就实现了这一机制，它会计算集群的票数（quorum）。如果一个节点发现自己无法联系到足够多的其他节点以形成多数，它就会主动放弃服务，避免与潜在的“对立者”发生冲突。通常，我们建议部署奇数个节点（例如3个节点），这样即使一个节点故障，剩余的两个节点也能形成多数，确保集群的仲裁能力。在双节点集群中，为了避免在网络分区时两个节点都无法形成多数而导致服务中断，有时会引入仲裁磁盘（Quorum Disk）或配置

no-quorum-policy

（后者需谨慎使用，因为它可能增加脑裂风险）。

STONITH（Shoot The Other Node In The Head），这个名字听起来有些激进，但其作用却是保障数据完整性的最后一道防线。它的原理是，当Pacemaker判断某个节点发生故障时，它会通过独立的硬件通道（比如远程电源管理卡IPMI、智能PDU、虚拟化平台的API等）强制关闭或重启故障节点。这样可以确保故障节点在任何情况下都无法继续访问共享资源或提供服务，从而彻底消除脑裂的风险。STONITH是强制性的，它保证了在集群出现通信问题时，只有一个节点能够控制共享资源。

举个例子，假设我们有一个双节点集群，

node1

和

node2

，它们共享一个存储。如果连接它们的心跳线断了，

node1

和

node2

都可能认为对方挂了。如果没有STONITH，

node1

可能会启动服务并挂载共享存储，

node2

也可能做同样的事情，导致数据冲突。一旦STONITH配置到位，比如通过IPMI，当

node1

发现

node2

心跳丢失时，它会尝试通过IPMI接口强制关闭

node2

的电源。只有当

node2

被确认已经完全离线后，

node1

才会安全地启动服务。这种“宁可错杀，不可放过”的策略，虽然听起来有些粗暴，但在生产环境中却是保障数据一致性的关键。

配置STONITH时，需要根据实际的硬件环境选择合适的

fence_agent

。例如，对于物理服务器，

fence_ipmilan

是一个常见的选择；对于VMware虚拟机，可以使用

fence_vmware_soap

。配置完成后，务必进行严格的测试，模拟各种故障场景，确保STONITH能够可靠地执行。

# 示例：配置一个基于IPMI的STONITH设备，假设IPMI IP为192.168.1.200和192.168.1.201 pcs stonith create fence_ipmi_node1 fence_ipmilan ip=192.168.1.200 login=admin passwd=password pcmk_host_list=node1 op monitor interval=60s pcs stonith create fence_ipmi_node2 fence_ipmilan ip=192.168.1.201 login=admin passwd=password pcmk_host_list=node2 op monitor interval=60s # 确保STONITH资源在集群中是启用的 pcs property set stonith-enabled=true

这些配置确保了在节点故障时，集群能够通过硬件层面进行干预，彻底避免脑裂带来的灾难性后果。

如何选择适合CentOS高可用的共享存储方案？

高可用集群的有效运作，离不开可靠的共享存储。因为当服务从一个节点迁移到另一个节点时，它所依赖的数据必须在不同节点间保持一致且可访问。选择合适的共享存储方案，直接关系到集群的性能、可靠性以及整体的复杂性。这块的选择其实非常多样，没有绝对的“最佳”方案，只有最适合你的应用场景和预算的方案。

常见的共享存储方案大致可以分为几类：

1. SAN (Storage Area Network) 存储： 这是企业级应用中非常普遍的选择，通常通过光纤通道（Fibre Channel）或iSCSI协议实现。SAN将存储设备抽象成块设备，集群中的所有节点都可以直接访问这些块设备。它的主要优点是性能高、可靠性强，通常还带有硬件冗余和高级管理功能。缺点是成本较高，部署和管理相对复杂。当使用SAN时，通常会结合集群文件系统，如GFS2（Global File System 2）或OCFS2（Oracle Cluster File System 2），来允许多个节点同时安全地读写同一个文件系统，避免数据冲突。但这类集群文件系统的部署和维护也需要一定的经验。

2. NAS (Network Attached Storage) 存储： 比如NFS（Network File System）或SMB/CIFS。NAS通过网络共享文件系统层面的数据。优点是部署简单、成本相对较低，很多现成的存储设备都支持。缺点是性能通常不如SAN，且网络延迟可能影响应用性能。在HA场景下，NFS是一个不错的