Linux高可用搭建教程：Pacemaker集群配置详解

今天golang学习网给大家带来了《Linux高可用怎么实现？Pacemaker集群搭建教程》，其中涉及到的知识点包括等等，无论你是小白还是老手，都适合看一看哦~有好的建议也欢迎大家在评论留言，若是看完有所收获，也希望大家能多多点赞支持呀！一起加油学习~

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

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

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

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

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集群的基本搭建步骤是怎样的？

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

1. 安装核心组件： 在所有集群节点上安装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

2. 配置并认证集群： 在其中一个节点上，使用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。你应该能看到所有节点都已加入集群，并且集群处于在线状态。

3. 配置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设备是否工作正常，这是生产环境部署前必须做的。

4. 添加集群资源： 现在可以添加你想要高可用的服务了。资源可以是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如何启动、停止和监控资源。

5. 配置资源组与约束（可选但推荐）： 当你有多个相关联的资源时，可以使用资源组（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虽然强大，但它也不是万能的，而且有时候，它会给你一些“惊喜”。

1. 脑裂（Split-Brain）： 这是集群最大的敌人，没有之一。当集群中的节点由于网络问题互相失去联系，各自认为对方已宕机，并尝试独立接管资源时，就会发生脑裂。这可能导致数据不一致甚至损坏。

   • 预防： 确保STONITH设备配置正确且能正常工作，这是防止脑裂的最后一道防线。同时，保证心跳网络的高可靠性，并合理配置仲裁（quorum）机制。
   • 排查： 观察pcs status输出，如果看到多个节点都声称拥有同一个资源，或者集群日志中出现大量关于“脑裂”或“仲裁丢失”的警告，那就要警惕了。

2. 资源无法启动或漂移失败： 这是最常见的运维问题。

   • 检查资源代理（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 ：查看特定资源的详细信息，包括当前状态、错误信息和上次操作结果。
     • pcs resource cleanup ：有时资源状态卡住，需要手动清理。

3. STONITH设备故障： 如果STONITH设备本身出现问题，导致无法隔离故障节点，那么集群在面对脑裂风险时将束手无策。

   • 定期测试： 务必定期手动测试STONITH设备，确保它能正常关机或重启节点。
   • 冗余配置： 考虑配置多个STONITH设备或不同的隔离方式，增加冗余。

4. 网络问题： 心跳网络的不稳定或中断，是导致集群频繁切换、仲裁丢失甚至脑裂的罪魁祸首。

   • 监控： 实时监控集群节点间的网络连通性。
   • 冗余： 配置多路径或绑定（bonding）网卡，提高心跳网络的可靠性。

5. 仲裁（Quorum）问题： 当集群中存活的节点数量不足以达到预设的仲裁阈值时（默认是超过半数），集群会停止所有资源以避免脑裂。

   • 节点数： 生产环境至少3个节点，或者使用奇数个节点，这样即使一个节点故障也能保持仲裁。
   • no-quorum-policy： 在某些特殊场景下（比如只有两个节点的集群，且明确知道风险），可以设置pcs property set no-quorum-policy=ignore，但这非常危险，不建议在生产环境使用。

排查思路通常是从底层往上：先检查网络和硬件，再看Corosync的通信，最后才是Pacemaker的资源调度。日志是你的最佳伙伴，学会阅读和分析日志，能解决绝大部分问题。crm_mon -r或pcs status是实时监控集群状态的利器，多用它们，你就能更好地理解集群的“脾气”。

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~