Linux如何实现高可用？_LinuxPacemaker集群搭建实战-小浪学习网

linux实现高可用的核心在于构建集群，使用pacemaker结合corosync作为开源高可用解决方案，其中corosync负责集群成员间的心跳和消息同步，pacemaker作为集群大脑负责资源调度和故障转移。搭建pacemaker集群需准备：1）至少两台服务器并配置独立业务与心跳网络；2）共享存储如drbd；3）系统环境一致性；4）关闭防火墙与selinux；5）配置ntp时间同步；6）ssh免密登录。搭建步骤包括：1）安装核心组件；2）配置并启动集群；3）设置stonith设备；4）添加集群资源；5）配置资源组与约束。运维常见挑战包括脑裂、资源启动失败、stonith故障、网络问题和仲裁问题，需通过日志分析、定期测试、冗余配置及合理策略应对。

Linux如何实现高可用？_LinuxPacemaker集群搭建实战

Linux实现高可用，核心在于构建集群，通过软件协调多台服务器，当一台出现故障时，另一台能迅速接管服务。Pacemaker结合Corosync是目前开源界非常成熟且广泛应用的高可用集群解决方案，它能确保关键应用在硬件故障或服务异常时持续在线。

Linux如何实现高可用？_LinuxPacemaker集群搭建实战

Pacemaker和Corosync这对搭档，是Linux高可用领域里我个人觉得最实用、也最值得深入研究的组合。简单来说，Corosync负责集群成员间的“心跳”和消息同步，它确保每个节点都知道其他节点是否“活着”，并且能够快速地在节点间传递配置和状态信息。而Pacemaker，则是这个集群的“大脑”，它利用Corosync提供的集群通信能力，来管理和调度各种资源（比如IP地址、数据库服务、Web应用等）。

整个高可用机制是这样的：Pacemaker会持续监控这些资源的状态，如果发现某个资源在当前主节点上出了问题（比如服务崩溃，或者主节点直接宕机），它会立即启动“故障转移”流程。首先，它会通过STONITH（Shoot The Other Node In The Head，直译为“爆头”）机制，确保故障节点真的被隔离或关机，避免“脑裂”——这是集群最害怕的情况，即两个节点都认为自己是主节点，导致数据不一致甚至损坏。隔离完成后，Pacemaker就会在集群中的其他健康节点上启动这个资源，从而实现服务的无缝切换，用户几乎感觉不到中断。

Linux如何实现高可用？_LinuxPacemaker集群搭建实战

Pacemaker集群搭建前需要准备什么？

说实话，每次开始一个新项目，搭建Pacemaker集群前的准备工作，我觉得比实际安装配置本身还重要，甚至可以说，很多后期遇到的“奇奇怪怪”的问题，根源都出在前期准备上。

硬件与网络拓扑：
- 服务器： 至少两台，最好是物理机，虚拟机也行但要留意IO性能和虚拟化层面的高可用配置。
- 网络： 建议至少两张网卡。一张用于业务通信，另一张专用于集群心跳（Corosync通信）。独立的集群心跳网络能大大提高集群的稳定性和可靠性。确保节点间通信无阻，IP地址规划要清晰，主机名解析（
```
/etc/hosts
```
  或DNS）必须正确配置。
共享存储：
- 这是高可用的基石。如果你的应用需要共享数据，那么共享存储是必不可少的。DRBD（Distributed Replicated Block Device）是我个人偏爱的一种选择，它能在块设备层面实现数据实时同步，简单可靠。当然，NFS、iSCSI、光纤存储等也都是可选方案，但各自有其适用场景和性能考量。
系统环境一致性：
- 操作系统版本、内核版本、软件包版本，尽量保持一致。比如都用centos 7或ubuntu Server 20.04。这能避免很多兼容性问题。
- 防火墙与SELinux： 在搭建和测试阶段，我通常会先关闭防火墙（
```
firewalld
```
  或
```
ufw
```
  ）和SELinux（设置为
```
permissive
```
  或
```
disabled
```
  ），等集群稳定运行后再逐步开启并配置规则。这能省去很多初期排错的麻烦。
时间同步：
- NTP服务必须有，而且要确保所有集群节点的时间是同步的。时间不一致会导致Corosync成员资格问题，甚至影响资源调度。
SSH免密登录：
- 为了方便集群管理和自动化操作，确保
  pcs
  命令能在集群节点间进行免密SSH登录。这是使用
  pcs
  工具管理集群的基础。

Pacemaker集群的基本搭建步骤是怎样的？

好了，准备工作就绪，接下来就是“干活”了。整个过程，我习惯把它拆解成几个关键环节，一步步来，会清晰很多，也方便排查问题。

Linux如何实现高可用？_LinuxPacemaker集群搭建实战

安装核心组件： 在所有集群节点上安装Pacemaker、Corosync、pcs（集群管理工具）、Resource-agents（资源代理）和fence-agents（隔离代理）。以CentOS/RHEL为例：
```
yum install -y pacemaker corosync pcs resource-agents fence-agents
```
安装完成后，启动并启用
```
pcsd
```
服务，这是
pcs
命令行工具与集群通信的守护进程。
```
systemctl enable pcsd systemctl start pcsd
```
设置
```
hacluster
```
用户的密码，
pcs
工具需要用到这个用户来认证。
```
echo "your_password" | passwd --stdin hacluster
```
配置并认证集群： 在其中一个节点上，使用
pcs
命令认证所有节点，然后设置并启动集群。
```
# 在node1上执行 pcs cluster auth node1 node2 -u hacluster -p your_password --force pcs cluster setup my_cluster node1 node2 pcs cluster start --all
```
检查集群状态：
pcs status
。你应该能看到所有节点都已加入集群，并且集群处于在线状态。

配置STONITH（隔离）设备： 这是集群安全的关键，没有STONITH的集群，就像一辆没有刹车的汽车。它能防止“脑裂”。STONITH设备通常是硬件层面的，比如ILO/iDRAC、IPMI等。

# 示例：配置一个基于IPMI的STONITH设备 pcs stonith create fence_ipmi_node1 fence_ipmilan ipaddr=192.168.1.200 login=admin passwd=password pcmk_host_list=node1 op monitor interval=60s pcs stonith create fence_ipmi_node2 fence_ipmilan ipaddr=192.168.1.201 login=admin passwd=password pcmk_host_list=node2 op monitor interval=60s # 启用STONITH pcs Property set stonith-enabled=true

务必测试STONITH设备是否工作正常，这是生产环境部署前必须做的。

添加集群资源： 现在可以添加你想要高可用的服务了。资源可以是IP地址、文件系统、服务等。

# 示例1：添加一个虚拟IP地址资源 pcs resource create VirtualIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=10s # 示例2：添加一个nginx服务资源（假设Nginx已安装并配置好） pcs resource create NginxService systemd:nginx op monitor interval=20s

ocf:heartbeat:IPaddr2

和

systemd:nginx

是资源代理的类型，它们定义了Pacemaker如何启动、停止和监控资源。

配置资源组与约束（可选但推荐）： 当你有多个相关联的资源时，可以使用资源组（

group

）将它们绑定在一起，确保它们在同一个节点上启动。

# 将VirtualIP和NginxService放入一个组 pcs resource group add WebAppGroup VirtualIP NginxService

你还可以添加约束（

colocation

共置、

order

顺序）来定义资源间的依赖关系和启动顺序。

# 示例：让NginxService在VirtualIP启动后才启动 pcs constraint order VirtualIP then NginxService # 示例：让NginxService和VirtualIP总是在同一个节点上 pcs constraint colocation add NginxService with VirtualIP INFINITY

Pacemaker集群日常运维中常见的挑战与故障排除？

说实话，搭建起来只是第一步，真正的挑战往往在后期运维中。Pacemaker虽然强大，但它也不是万能的，而且有时候，它会给你一些“惊喜”。

脑裂（Split-Brain）： 这是集群最大的敌人，没有之一。当集群中的节点由于网络问题互相失去联系，各自认为对方已宕机，并尝试独立接管资源时，就会发生脑裂。这可能导致数据不一致甚至损坏。
- 预防： 确保STONITH设备配置正确且能正常工作，这是防止脑裂的最后一道防线。同时，保证心跳网络的高可靠性，并合理配置仲裁（quorum）机制。
- 排查： 观察
  pcs status
  输出，如果看到多个节点都声称拥有同一个资源，或者集群日志中出现大量关于“脑裂”或“仲裁丢失”的警告，那就要警惕了。
资源无法启动或漂移失败： 这是最常见的运维问题。
- 检查资源代理（Resource Agent）： 确保你的资源代理脚本（通常在
```
/usr/lib/ocf/resource.d/heartbeat/
```
  或
```
/usr/lib/systemd/system/
```
  ）权限正确，并且能独立运行。很多时候，是资源代理本身的问题，比如路径不对，依赖缺失，或者脚本逻辑有bug。
- 查看集群日志： 这是排查问题的金钥匙。
  - ```
  journalctl -u corosync
```
  ：查看Corosync的日志，了解节点间的通信和成员资格变化。
- ```
journalctl -u pacemaker
```
    ：查看Pacemaker的日志，这里会记录资源调度、启动、停止的详细过程和错误信息。
  - ```
  journalctl -u pcsd
```
  ：查看
  pcsd
  的日志，了解
  pcs
  命令的执行情况。
- 系统日志（
```
  /var/log/messages
```
  或
```
  syslog
```
  ）也可能包含底层错误。
- 使用
  
  pcs
  
  命令：
  - pcs status
    ：快速查看集群整体状态，哪些资源在哪个节点上运行，是否有错误。
  - ```
  pcs resource show <resource_name>
```
  ：查看特定资源的详细信息，包括当前状态、错误信息和上次操作结果。
- ```
pcs resource cleanup <resource_name>
```
    ：有时资源状态卡住，需要手动清理。
STONITH设备故障： 如果STONITH设备本身出现问题，导致无法隔离故障节点，那么集群在面对脑裂风险时将束手无策。
- 定期测试： 务必定期手动测试STONITH设备，确保它能正常关机或重启节点。
- 冗余配置： 考虑配置多个STONITH设备或不同的隔离方式，增加冗余。
网络问题： 心跳网络的不稳定或中断，是导致集群频繁切换、仲裁丢失甚至脑裂的罪魁祸首。
- 监控： 实时监控集群节点间的网络连通性。
- 冗余： 配置多路径或绑定（bonding）网卡，提高心跳网络的可靠性。
仲裁（Quorum）问题： 当集群中存活的节点数量不足以达到预设的仲裁阈值时（默认是超过半数），集群会停止所有资源以避免脑裂。
- 节点数： 生产环境至少3个节点，或者使用奇数个节点，这样即使一个节点故障也能保持仲裁。
- no-quorum-policy
  
  ：在某些特殊场景下（比如只有两个节点的集群，且明确知道风险），可以设置
```
pcs property set no-quorum-policy=ignore
```
  ，但这非常危险，不建议在生产环境使用。