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集群的基本搭建步骤是怎样的？
好了，准备工作就绪，接下来就是“干活”了。整个过程，我习惯把它拆解成几个关键环节，一步步来，会清晰很多，也方便排查问题。
安装核心组件：在所有集群节点上安装Pacemaker、Corosync、pcs（集群管理工具）、resource-agents（资源代理）和fence-agents（隔离代理）。以CentOS/RHEL为例：
yum install -y pacemaker corosync pcs resource-agents fence-agents
安装完成后，启动并启用
pcsd
服务，这是
pcs
命令行工具与集群通信的守护进程。
systemctl enable pcsdsystemctl start pcsd
设置
hacluster
用户的密码，
pcs
工具需要用到这个用户来认证。
ViiTor实时翻译
AI实时多语言翻译专家！强大的语音识别、AR翻译功能。
116 查看详情 
echo "your_password" | passwd --stdin hacluster
配置并认证集群：在其中一个节点上，使用
pcs
命令认证所有节点，然后设置并启动集群。
# 在node1上执行pcs cluster auth node1 node2 -u hacluster -p your_password --forcepcs cluster setup my_cluster node1 node2pcs 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=60spcs stonith create fence_ipmi_node2 fence_ipmilan ipaddr=192.168.1.201 login=admin passwd=password pcmk_host_list=node2 op monitor interval=60s# 启用STONITHpcs 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
：查看特定资源的详细信息，包括当前状态、错误信息和上次操作结果。
pcs resource cleanup
：有时资源状态卡住，需要手动清理。
STONITH设备故障：如果STONITH设备本身出现问题，导致无法隔离故障节点，那么集群在面对脑裂风险时将束手无策。
定期测试： 务必定期手动测试STONITH设备，确保它能正常关机或重启节点。冗余配置： 考虑配置多个STONITH设备或不同的隔离方式，增加冗余。
网络问题：心跳网络的不稳定或中断，是导致集群频繁切换、仲裁丢失甚至脑裂的罪魁祸首。
监控： 实时监控集群节点间的网络连通性。冗余： 配置多路径或绑定（bonding）网卡，提高心跳网络的可靠性。
仲裁（Quorum）问题：当集群中存活的节点数量不足以达到预设的仲裁阈值时（默认是超过半数），集群会停止所有资源以避免脑裂。
节点数： 生产环境至少3个节点，或者使用奇数个节点，这样即使一个节点故障也能保持仲裁。
no-quorum-policy
： 在某些特殊场景下（比如只有两个节点的集群，且明确知道风险），可以设置
pcs property set no-quorum-policy=ignore
，但这非常危险，不建议在生产环境使用。
排查思路通常是从底层往上：先检查网络和硬件，再看Corosync的通信，最后才是Pacemaker的资源调度。日志是你的最佳伙伴，学会阅读和分析日志，能解决绝大部分问题。
crm_mon -r
或
pcs status
是实时监控集群状态的利器，多用它们，你就能更好地理解集群的“脾气”。
以上就是Linux如何实现高可用？_LinuxPacemaker集群搭建实战的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/422354.html
微信扫一扫 
支付宝扫一扫 
