CentOS集群搭建怎么操作_CentOS高可用集群配置方法-小浪学习网

centos高可用集群核心组件包括Corosync、Pacemaker、STONITH、共享存储和资源代理；通过Corosync实现节点通信与心跳检测，Pacemaker调度服务资源，STONITH防止脑裂，共享存储保障数据一致，资源代理管理具体服务，结合pcs工具进行配置与监控，确保服务自动切换与业务持续可用。

CentOS集群搭建怎么操作_CentOS高可用集群配置方法

搭建CentOS高可用集群，核心思路是利用Corosync进行节点间通信和心跳检测，再由Pacemaker作为资源管理器来调度服务，并辅以共享存储和至关重要的Fencing（故障隔离）机制，确保在任何一个节点失效时，服务能自动且平滑地切换到其他健康节点上，从而实现业务的持续可用。

解决方案

说实话，搞定一个CentOS高可用集群，过程可能有点繁琐，但只要理清思路，一步步来，也没想象中那么难。我个人觉得，最关键的是前期规划和对Fencing机制的理解。

首先，得把所有参与集群的节点都准备好。这包括：

操作系统安装：CentOS 7或8都行，确保系统是最小化安装，减少不必要的服务。
网络配置：每个节点至少两张网卡，一张用于业务，一张专用于集群心跳通信（虽然Corosync可以跑在单网卡上，但冗余才是王道）。确保IP地址、子网掩码、网关都配置正确，并且节点间可以互相ping通。
主机名解析：修改
```
/etc/hosts
```
文件，把所有集群节点的主机名和IP地址都写进去，确保每个节点都能通过主机名解析到其他节点。这比依赖DNS更直接，也更可靠。
时间同步：NTP服务是必须的，集群节点间的时间必须高度一致，否则会引发各种奇奇怪怪的问题，比如日志时间错乱，甚至集群状态判断失误。
禁用SElinux和Firewalld：这俩货在集群搭建初期是出了名的“拦路虎”。暂时禁用它们能省去很多不必要的麻烦。等集群跑起来了，再根据需要逐步开启并配置规则。
```
# 禁用SELinux setenforce 0 sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config  # 禁用Firewalld systemctl stop firewalld systemctl disable firewalld
```

接下来是核心组件的安装和配置：

共享存储：高可用集群的数据一致性依赖于共享存储。常见的有iSCSI、NFS、GFS2或者DRBD。iSCSI相对简单，这里以它为例，假设你已经配置了一个iSCSI Target，并在所有集群节点上都挂载了相同的LUN。

# 在所有节点上安装iSCSI客户端 yum install -y iscsi-initiator-utils  # 发现并登录iSCSI Target (假设Target IP是192.168.1.100) iscsiadm -m discovery -t st -p 192.168.1.100 iscsiadm -m node -L all  # 格式化并挂载（只在一个节点上操作，然后其他节点只挂载） # mkfs.ext4 /dev/sdb # 假设LUN被识别为/dev/sdb # mount /dev/sdb /mnt/shared # 挂载到共享目录 # 记得配置fstab自动挂载，但对于集群资源，通常由Pacemaker管理挂载点

安装Pacemaker和Corosync：
```
yum install -y pacemaker corosync pcs Resource-agents fence-agents
```
pcs
是管理Pacemaker/Corosync集群的命令行工具，
```
resource-agents
```
包含了各种服务的资源代理脚本，
```
fence-agents
```
则是Fencing机制所需的代理。
设置hacluster用户密码：
pcs
命令需要
```
hacluster
```
用户进行认证。
```
echo "your_password" | passwd --stdin hacluster
```
在所有节点上都执行。

授权并建立集群：

# 在任意一个节点上执行 pcs cluster auth node1 node2 -u hacluster -p your_password --force # node1, node2 是你的集群节点主机名  # 创建集群 (集群名称可自定义) pcs cluster setup my_ha_cluster node1 node2  # 启动集群 pcs cluster start --all  # 检查集群状态 pcs status

如果一切顺利，你会看到集群状态正常，所有节点都处于online状态。

配置Fencing (STONITH)：这是防止“脑裂”（Split-Brain）的关键。没有Fencing的集群，就如同没有安全带的汽车。Fencing的目的是在某个节点发生故障时，强制将其隔离，确保它不再访问共享资源，避免数据损坏。配置STONITH设备取决于你的环境。如果是虚拟机，可以使用

fence_xvm

；物理机则常用

fence_ipmilan

（通过IPMI接口硬关机）。这里以一个通用的虚拟设备为例，实际生产环境需要配置真实的Fencing设备。

# 禁用STONITH（不推荐，仅用于测试理解） # pcs Property set stonith-enabled=false  # 启用STONITH pcs property set stonith-enabled=true  # 添加一个Fencing设备 (例如，一个虚拟的，生产环境请替换为真实设备) # 假设你有一个支持IPMI的服务器，IPMI地址是192.168.1.200 pcs stonith create fence_device_node1 fence_ipmilan ipaddr=192.168.1.200 login=admin passwd=password pcmk_host_list=node1 pcs stonith create fence_device_node2 fence_ipmilan ipaddr=192.168.1.201 login=admin passwd=password pcmk_host_list=node2 # 注意：这里的pcmk_host_list是指定该Fencing设备可以对哪个主机进行操作

添加集群资源：现在集群框架搭好了，可以把服务（资源）放进去了。比如，一个虚拟IP地址（VIP）和一个apache Web服务。

Ajelix

处理Excel和GoogleSheets表格的AI工具

查看详情

# 创建虚拟IP资源 pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=10s  # 创建Apache Web服务资源 pcs resource create web_server ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf statusurl="http://localhost/server-status" op monitor interval=20s  # 将VIP和Web服务绑定到一起，确保它们在同一个节点上运行 pcs constraint colocation add virtual_ip with web_server INFINITY  # 定义启动顺序，确保VIP先启动，Web服务后启动 pcs constraint order virtual_ip then web_server

检查资源状态：

pcs status resources

测试：这是最关键的一步。尝试手动关闭一个节点，观察服务是否能自动漂移到另一个节点。
```
# 在node1上模拟故障（比如直接关机） # systemctl stop pacemaker corosync # 模拟软件故障 # 或者直接 reboot / poweroff
```
观察
pcs status
的输出，看VIP和Web服务是否已经成功在node2上运行。

CentOS高可用集群的核心组件有哪些？

在我看来，构建一个稳定可靠的CentOS高可用集群，离不开以下几个核心组件，它们各司其职，共同构筑起服务的“不倒翁”：

Corosync (集群通信层)：这是集群的心脏和神经系统。它负责节点间的通信、心跳检测、成员管理和消息传递。说白了，就是让集群里的所有机器知道“我们是一个团队”，并且能实时感知到其他队友的“健康状况”。如果某个节点的心跳停了，Corosync就会通知Pacemaker，然后Pacemaker才能采取行动。它的配置相对简单，主要定义了集群的IP地址、端口和成员列表。
Pacemaker (集群资源管理器)：如果说Corosync是集群的感知层，那Pacemaker就是集群的大脑和决策者。它根据Corosync提供的信息，结合预设的资源配置和策略，决定哪些服务（资源）应该运行在哪个节点上。当节点发生故障时，Pacemaker会根据资源约束（比如哪些资源必须在一起，哪些必须分开，启动顺序等）来重新调度资源到健康的节点上。它支持各种复杂的资源类型，从IP地址、文件系统到数据库、Web服务，几乎无所不包。
STONITH (Shoot The Other Node In The Head – 故障隔离机制)：这个名字听起来有点暴力，但它却是高可用集群中不可或缺的“保命符”，也是避免“脑裂”的唯一有效手段。STONITH的目的是，当集群判断某个节点发生故障时，强制将其从集群中移除，通常是通过远程电源控制（比如IPMI、ILO、DRAC）或虚拟机管理接口（如virsh）直接将其断电或重启，确保故障节点无法再访问共享存储或提供服务，从而避免数据损坏和资源争抢。没有STONITH的集群，在高可用性方面几乎是形同虚设。
共享存储：这是集群数据一致性的基石。无论是iSCSI、NFS、GFS2还是DRBD，其核心目标都是确保所有集群节点都能访问到同一份数据。当服务从一个节点漂移到另一个节点时，新的节点能够立即接管并访问到最新的数据。选择哪种共享存储，取决于你的具体需求、预算和性能考量。我个人觉得，对于大多数中小规模应用，iSCSI或NFS已经足够应对。
资源代理 (Resource Agents)：这些是Pacemaker用来管理各种具体服务的脚本。它们定义了如何启动、停止、监控某个服务（比如Apache、mysql、虚拟IP等）。Pacemaker通过调用这些代理脚本来执行操作。有了这些代理，Pacemaker就能以标准化的方式管理各种异构的服务，大大简化了集群的配置和管理。

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

“脑裂”（Split-Brain）是高可用集群中最致命的问题之一，也是我个人在实践中遇到过最头疼的挑战。简单来说，脑裂就是当集群中的通信链路出现故障时，两个或多个节点都误以为其他节点已经失效，从而各自独立地启动服务，甚至同时尝试写入共享存储，这会导致数据严重不一致，甚至数据损坏。

避免脑裂的唯一有效且可靠的方案就是强制性的Fencing（STONITH）机制。除此之外，没有其他任何纯软件的手段能够100%保证避免脑裂。

具体来说，如何避免：

理解STONITH的必要性：当集群的某个节点无法响应心跳时，Pacemaker并不能直接判断它是真的宕机了，还是仅仅是网络暂时中断了。如果没有Fencing，Pacemaker可能会让另一个节点启动服务，而那个“假死”的节点可能在网络恢复后也继续运行服务，这就是脑裂的根源。STONITH的作用，就是在Pacemaker决定让另一个节点接管服务之前，强制将故障节点“杀死”，确保它彻底停止服务，从而消除脑裂的可能性。它就像一个“执行者”，确保任何时候只有一个节点拥有对共享资源的独占访问权。
正确配置STONITH设备： STONITH设备的类型多种多样，选择适合你环境的设备至关重要。
- IPMI/ILO/DRAC：对于物理服务器，这是最常用也是最可靠的方式。通过服务器的带外管理接口，可以直接控制电源开关，实现硬关机。
- 虚拟化平台API：对于虚拟机，可以通过Hypervisor的API（如VMware vCenter、openstack Nova、KVM的virsh等）直接关闭或重启虚拟机。
- 存储设备Fencing：有些高端存储设备支持Fencing功能，可以直接隔离故障节点对存储的访问。配置时，需要为每个节点配置一个或多个STONITH设备，并且确保每个设备都有权限操作对应的节点。例如，使用
```
fence_ipmilan
```
  时，需要提供IPMI的IP地址、用户名和密码。
```
# 示例：为node1配置一个IPMI Fencing设备 pcs stonith create fence_node1 fence_ipmilan ipaddr=192.168.1.200 login=admin passwd=your_ipmi_password pcmk_host_list=node1 # pcmk_host_list 指定这个Fencing设备是用来隔离哪个集群节点的
```
务必测试Fencing设备是否能正常工作。尝试手动触发一个节点的Fencing，看它是否能被强制关机。
Quorum（法定人数）机制： Corosync引入了Quorum的概念，即集群必须有超过半数的节点处于在线状态，才能被认为是“健康”的，才能执行资源操作。如果集群中的在线节点数量低于Quorum，整个集群可能会进入“停滞”状态，不再执行任何资源操作，等待足够多的节点恢复。这在一定程度上也能防止脑裂，因为如果通信中断导致集群分裂成两部分，只有拥有Quorum的那部分才能继续运行服务，另一部分则会自行停止。然而，Quorum并不能完全替代STONITH，它只是一个“自保”机制，STONITH才是“杀伐决断”的机制。默认情况下，
pcs
会开启Quorum。你可以通过
```
pcs property show | grep quorum-policy
```
查看。
冗余的心跳网络：虽然这不是直接的脑裂解决方案，但一个稳定、冗余的心跳网络能大大降低通信中断的风险，从而减少脑裂发生的可能性。建议使用独立的网卡或VLAN来承载Corosync的心跳流量。

总的来说，要避免CentOS高可用集群的脑裂，核心就是始终确保STONITH机制的有效性。这是集群稳定运行的最后一道防线。

在CentOS集群中，如何高效管理和监控集群资源？

管理和监控集群资源，是确保高可用集群长期稳定运行的关键。这不仅仅是配置一次就完事儿，日常的维护和故障排查同样重要。

使用

pcs

命令行工具进行日常管理：
pcs
是Pacemaker和Corosync的官方命令行接口，功能强大且直观。我个人觉得，掌握
pcs
是管理CentOS高可用集群最基本也是最重要的技能。
- 查看集群状态：
  pcs status
  可以快速了解集群的整体健康状况、节点状态、资源状态等。
- 查看资源详情：
```
pcs resource show
```
  或
```
pcs resource show <resource_id>
```
  可以查看特定资源的详细配置和当前状态。
- 添加/删除资源：
```
pcs resource create
```
  和
```
pcs resource delete
```
  用于管理集群中的服务。
- 修改资源配置：
```
pcs resource update <resource_id> <param>=<value>
```
  可以动态调整资源的参数。
- 管理约束：
```
pcs constraint
```
  系列命令用于添加、删除、查看资源间的各种约束（协同、顺序、位置等），这些约束是Pacemaker调度资源的核心依据。
- 节点维护：
```
pcs node standby <node_id>
```
  可以将某个节点置于维护模式，让资源自动漂移走，方便进行系统升级或维护。
```
pcs node unstandby <node_id>
```
  则让节点重新加入调度。
利用Pacemaker的资源代理 (Resource Agents)： Pacemaker通过资源代理来管理各种服务。这些代理脚本通常位于
```
/usr/lib/ocf/resource.d/heartbeat/
```
目录下。
- 标准化操作：每个资源代理都提供
```
start
```
  、
```
stop
```
  、
```
monitor
```
  、
```
meta
```
  等标准操作，Pacemaker通过调用这些操作来管理服务。
- 服务兼容性：Pacemaker提供了大量预定义的资源代理，涵盖了常见的服务，如IP地址（IPaddr2）、文件系统（Filesystem）、Apache（apache）、MySQL（mysql）等。这大大简化了将现有服务集成到集群中的工作。
- 自定义代理：如果你的服务没有现成的资源代理，也可以编写自定义的shell脚本或python脚本，遵循OCF（Open Cluster Framework）标准，作为自定义资源代理集成到Pacemaker中。
日志分析：当集群出现问题时，日志是排查故障的第一手资料。
- /var/log/messages
  
  ：系统级别的日志，包含了Corosync和Pacemaker的事件信息。
- /var/log/cluster/corosync.log
  
  ：Corosync的专用日志，记录了心跳、成员变化等集群通信相关的信息。
- /var/log/pacemaker.log
  
  ：Pacemaker的专用日志，记录了资源调度、Fencing操作等详细事件。通过
```
journalctl -f
```
  或
```
tail -f
```
  命令实时查看日志，可以帮助你快速定位问题。
集成到现有监控系统：虽然
pcs status
能提供实时的集群状态，但对于长期的趋势分析和预警，集成到专业的监控系统（如zabbix、prometheus、grafana）是更好的选择。
- Zabbix：可以通过编写自定义的Zabbix Agent脚本，定期执行
  pcs status
  并解析输出，将集群状态、资源状态、节点健康度等数据发送给Zabbix Server。
- Prometheus：可以使用
```
textfile_exporter
```
  或自定义
```
node_exporter
```
  模块，将
  pcs status
  的输出转换成Prometheus可识别的指标，然后通过Grafana进行可视化展示。通过监控，可以及时发现潜在问题，如资源漂移失败、Fencing设备异常、节点通信延迟等，从而在问题影响业务之前进行干预。