在客户现场排查集群故障时我最常用的命令就是pcs status。很多人第一次听到PCS脑子里蹦出来的是储能逆变器但在Linux高可用集群这个圈子里PCS指的是Pacemaker/Corosync Configuration System也就是管理Pacemaker和Corosync集群的核心命令行工具。这篇文章就围绕Linux系统中PCS命令的使用展开从概念解析到环境准备再到资源管理、故障切换验证最后是排障经验把我在生产环境里真正用到的pcs命令讲透适合刚接触HA集群的运维新人也适合已经在用但想系统梳理一遍的同学。1. PCS命令到底在管什么1.1 先把概念理清楚先把这个名字拆开。PCS全称Pacemaker/Corosync Configuration System它是个命令行工具用来配置和管理由Pacemaker和Corosync组成的高可用集群。Corosync负责集群成员间的通信、心跳检测和投票机制Pacemaker则根据集群状态决定资源在哪台节点上运行。PCS把这两者的配置文件统一管理起来让你不用手动去改XML格式的CIBCluster Information Base文件。很多初学者会问既然Pacemaker和Corosync是核心为什么非要再用一个PCS早年管理Corosync集群确实没有统一工具要手动编辑/etc/corosync/corosync.conf然后用crm命令或直接操作cibadmin去改CIB。RHEL 7之后官方把pcs作为标准管理工具预装进来取代了早期版本里的ricci和luci组合。pcs命令的价值在于它把认证、配置文件生成、资源管理、约束配置、日志查看都收拢到一套命令族里极大降低了操作门槛。1.2 为什么实际工作中离不开pcs命令在RHEL 8/9、Rocky Linux、AlmaLinux以及一系列国产化Linux发行版里pcs都已经成为RHCSRed Hat Cluster Suite高可用组件的默认管理入口。生产环境里做数据库双机、Web服务主备、NFS故障切换底层跑的基本都是CorosyncPacemakerpcs这套组合。我在项目里最深的感受是pcs命令的设计思路非常贴近运维习惯。它把操作分成几个清晰的命令族pcs cluster管集群本身pcs resource管资源pcs constraint管约束pcs property管全局属性pcs node管节点状态pcs status看全貌。这种模块化的设计让排查问题时能很快定位到对应命令而不是在一大堆XML里翻找。注意RHEL 6时代的RHCS用的是rgmanagerCMAN管理命令是clustat和clusvcadm和现在的pcs完全是两套东西。如果你看的旧教程里全是clusvcadm那多半是过时内容要留意版本差异。2. 上手之前的准备2.1 环境规划与基础配置我在实际部署时最少会用两台节点搭一个集群来演示生产环境一般三台起步。节点的hostname必须唯一而且最好在/etc/hosts里把各节点的主机名和IP对应关系写清楚。这个细节经常坑人Corosync默认依赖主机名解析来识别节点如果主机名解析不到IP后端的服务就会报错集群状态也一直起不来。两个节点的操作系统我习惯统一避免因为系统库版本差异带来不必要的麻烦。所有节点都要能互相通过SSH访问后续pcs cluster auth认证过程要用到这个。如果有多块网卡建议指定独立的集群通信网段不要跟业务流量混在一起否则高负载时的网络抖动很可能触发节点被误判为故障生产环境里我吃过这个亏。2.2 安装与初始认证以Rocky Linux 9为例先在所有节点上安装软件包yum install -y pcs pacemaker corosync fence-agents-all这里fence-agents-all不一定要装全但建议至少装上跟你实际环境对应的fence agent后面配置stonithfencing会用到不然集群默认stonith-enabled没关资源切换可能会被卡住。安装完成后需要设置hacluster用户密码这个用户是pcs用来在各节点间通信的专用账号passwd hacluster然后启动pcsd服务并设为开机自启systemctl enable --now pcsd.service准备工作做完了接下来才是关键。先执行集群认证把当前节点和需要加入集群的节点互相“握手”pcs host auth node1.cloud.local node2.cloud.local -u hacluster -p 你的密码提示生产环境里不要把密码直接写在命令行里建议使用交互式输入。写本文是为了方便展示实际脚本里可以用--force配合密钥或使用pcs host auth的交互模式。3. 核心操作从创建集群到日常管理3.1 创建集群并启动认证完成后在其中一个节点上创建集群。这里要指定集群名称和参与集群的节点列表pcs cluster setup mycluster node1.cloud.local node2.cloud.local这个命令会自动生成/etc/corosync/corosync.conf并把配置同步到所有认证过的节点。生成完后启动集群pcs cluster start --all启动后第一件事就是用pcs status确认集群是否正常。一个健康的集群输出大概长这样Cluster name: mycluster WARNINGS: No stonith devices and stonith-enabled is true Cluster Summary: * Stack: corosync * Current DC: node1 * Last updated: ... * Last change: ... * 2 nodes configured * 0 resource instances configured PCSD Status: node1: Online node2: Online如果看到Current DC能选出来节点节点状态都是Online说明集群底层通信已经建立。这里经常有新手被WARNINGS吓到其实就是在提醒你还没配fencing设备先把stonith-enabled关了或者把fence配好就行后面会细说。3.2 资源管理的常用命令集群建好后用pcs resource系列命令来定义业务资源。先看两个基本操作# 创建一个IP地址资源 pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip192.168.1.100 cidr_netmask24 op monitor interval5s # 查看当前资源状态 pcs resource show这里有个概念要理解ocf:heartbeat:IPaddr2这一串是资源代理的类型。OCF是Open Cluster Framework标准heartbeat是代理集合名IPaddr2是具体代理脚本。pcs只是把这些信息组装成资源定义真正执行检测和控制的是对应脚本。资源常见的操作还有# 将资源迁移到指定节点一般会先standby目标节点 pcs resource move virtual_ip node2 # 清理资源的状态和failcount pcs resource cleanup virtual_ip # 禁用/启用资源 pcs resource disable virtual_ip pcs resource enable virtual_ipcleanup命令是我最常用的重置手段。资源一旦连续多次监控失败Pacemaker会记录failcount超过阈值后资源会停止迁移如果代码逻辑有问题或者网络抖动导致监控失败failcount一高资源就可能一直停在某个节点上不动。这时候pcs resource cleanup能清空失败计数让Pacemaker重新评估。3.3 约束与属性配置只创建资源还不够要让资源合理地运行在集群里还得配置约束。约束分三种顺序约束order、位置约束location、排列约束colocation。举一个典型的Web高可用场景虚拟IP要跟着Apache服务走Apache起来了VIP才能配置上去而且这两个资源最好调度到同一个节点。对应命令如下# 创建Apache资源 pcs resource create web_service systemd:httpd --no-default-ops # 设置顺序约束先启动virtual_ip再启动web_service pcs constraint order start virtual_ip then start web_service # 设置排列约束web_service和virtual_ip必须在同一节点 pcs constraint colocation add web_service with virtual_ip INFINITY # 设置位置约束让web_service尽量跑到node1 pcs constraint location web_service prefers node150顺序约束解决依赖问题排列约束解决“同一资源组必须在一起”的问题位置约束影响资源调度优先级。这三类约束都用pcs constraint管理用pcs constraint list可以查看当前所有约束。属性配置方面用得最多的是pcs property。比如no-quorum-policy、stonith-enabled、cluster-recheck-interval这些# 双节点集群没有冗余投票需要设置忽略仲裁 pcs property set no-quorum-policyignore # 没有fencing设备时先关闭stonith pcs property set stonith-enabledfalse注意no-quorum-policyignore只在双节点时是合理的因为两台节点挂一台就没了法定票数如果不开ignore另一台节点会主动释放资源业务直接中断。三台及以上节点强烈建议保留默认的stop策略并在仲裁上做合理规划。4. 一个完整示例用pcs部署Web高可用集群4.1 准备阶段这里我以两台Rocky Linux 9节点为例主机名分别是ha1和ha2业务IP规划如下节点管理IP集群通信IP备注ha1192.168.1.1110.10.10.11主节点ha2192.168.1.1210.10.10.12备节点虚拟IP192.168.1.100-对外提供服务先在每台节点上安装必要的软件包这里把httpd和之前提到的pcs/pacemaker/corosync一起装好dnf install -y pcs pacemaker corosync fence-agents-all httpd设置hacluster密码并设置pcsd开机自启然后确认两台节点的主机名解析没问题ping -c 2 ha1 ping -c 2 ha2一切通顺后执行认证pcs host auth ha1 ha2 -u hacluster4.2 创建资源和约束在ha1上创建集群并启动pcs cluster setup webcluster ha1 ha2 pcs cluster start --all由于两台节点环境里没有真实的fencing设备我先临时关闭stonith同时设置仲裁策略pcs property set stonith-enabledfalse pcs property set no-quorum-policyignore接着创建VIP和Apache资源pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip192.168.1.100 cidr_netmask24 op monitor interval5s pcs resource create web_service apache \ configfile/etc/httpd/conf/httpd.conf \ op monitor timeout5s interval10s这里需要注意我用的Apache资源代理是apache如果你用的不是默认安装路径可以配合httpd参数指定可执行文件或配置路径。上面这样写完先不加约束手动触发一次两个资源的调度测试看看能否正常在不同节点上启动再配置约束pcs constraint order start virtual_ip then start web_service pcs constraint colocation add web_service with virtual_ip INFINITY配置完约束后用pcs status确认。正常情况下两个资源会同时运行在同一个节点上比如都在ha1上。pcs resource show能查看每个资源的当前节点和详细参数。4.3 验证故障切换高可用集群的核心价值就是在节点故障时让资源自动存活。我用pcs node standby ha1模拟一台节点被主动下线pcs node standby ha1执行后大概几秒钟内Pacemaker会检测到ha1不再适合承载资源自动在ha2上启动VIP和Apache服务。用下面的命令验证pcs status ip addr show如果VIP出现在ha2的网卡上而且pcs status里资源显示started on ha2就说明故障切换流程跑通了。之后恢复ha1pcs node unstandby ha1再观察一阵如果我没有配置位置约束Pacemaker不会因为ha1恢复了就立刻把资源切回去这是正常设计。想手动把资源切回ha1可以用pcs resource move web_service ha1。心得真实生产里我会故意拔一根网线或者systemctl stop corosync来测故障切换而不仅仅用standby。因为standby是“优雅下线”Pacemaker能提前收到信号而真实的故障是突然中断心跳这才会真正考验fencing和资源恢复逻辑。两者测试结果可能完全不同。5. 常见问题与排障经验5.1 集群起不来的排查路径集群和网络一样90%的问题出在细节上。先看一个典型场景执行pcs cluster start --all结果ha1提示成功ha2提示失败。这时候按顺序排查确认ha2上的pcsd.service是否在运行systemctl status pcsd确认ha1和ha2之间的集群通信端口是否通畅Corosync默认用UDP 5405要保证iptables/firewalld没有拦截查看/var/log/cluster/corosync.log和journalctl -u corosync -f我自己踩过最多次的坑是firewalld。很多发行版默认开firewalld而且没有放行5405端口集群创建一个小时都连不上最后在日志里看到一堆“corosync: Totem is unable to form a cluster”一查就是UDP包被防火墙丢了。解决办法firewall-cmd --permanent --add-port5405/udp firewall-cmd --permanent --add-port2224/tcp firewall-cmd --reload注意2224端口是pcsd做Web管理用的如果要远程用pcs命令这个端口也得放行。5.2 资源反复漂移或启动失败资源在两个节点之间来回切换多半是监控操作触发了失败。打开资源详情看看pcs resource debug-monitor virtual_ip pcs resource show web_service --full--full能看到完整的注册参数和操作定义。如果资源启动几秒后立刻失败重点看对应资源代理的日志输出比如Apache的/var/log/httpd/error_log。我见过一个比较典型的问题两台节点上的httpd都装好了但其中一台的ServerName没设置Apache启动时报错Pacemaker检查到失败后把资源切到另一台反复几次后failcount过高资源直接不启动了。遇到这种问题先pcs resource cleanup web_service清掉失败计数再定位启动失败的根本原因。不要光靠重启解决cleanup只是让Pacemaker重新尝试真正的问题还在。5.3 脑裂和fencing的取舍脑裂是所有集群最怕出现的情况。两台节点无法通信但都以为自己活着于是同时启动VIP、同时对外提供服务双写冲突直接数据损坏。Corosync的投票机制能避免一部分脑裂但在双节点环境下如果没有配置fencing出问题时会非常尴尬节点A觉得节点B死了节点B觉得节点A死了两边都持有资源谁也说服不了谁。所以在生产环境stonith-enabledtrue必须开并且要配置真实可用的fencing设备比如IPMI、iLO、iDRAC或者云平台的fence agent。配置示例pcs stonith create my_ipmi fence_ipmilan \ pcmk_host_listha1 ha2 \ ipaddr192.168.1.11 \ loginadmin \ passwd你的IPMI密码 \ lanplus1 \ op monitor interval300s如果确实没有fencing设备开发环境可以pcs property set stonith-enabledfalse但生产环境这么干等于裸奔。我见过一个案例两台节点因为网络抖动互相“打死”结果因为没配fencing最终两台节点同时抢负载均衡器后端导致数据库双写恢复花了两天。独家经验模拟脑裂最有效的方法不是关网卡而是用iptables -A INPUT -s 对方IP -j DROP这种单向丢包或者干脆断开集群通信网线。这样才能测试出Corosync隔离机制是否真的可靠同时也能验证fencing动作是否按预期触发。写在最后PCS命令这套工具链说难不难说简单也不简单。它的命令结构本身不复杂复杂的是底层原理和巡检思路。我自己早期用pcs时走过不少弯路最开始只会照着教程敲几行命令遇到问题就开始怀疑集群坏了后来才明白pcs只是把Corosync和Pacemaker的复杂配置翻译成了人类能看懂的命令它本身不解决业务问题真正解决问题要靠对集群机制的理解。给刚入门的朋友几个个人建议第一集群的所有节点系统时间一定要同步Corosync对时间偏差极敏感时间差太大会导致节点不断被踢出集群用chrony或者ntp做好时间同步是基础中的基础第二每次改动配置前用pcs config backup备份一下这是最省心的后悔药第三定期查看pcs status里的WARNINGS不要忽略它们很多隐患就是一开始不显眼后面变成大故障第四不要害怕在生产环境做故障演练模拟一次真实故障比看十遍教程都管用。PCS命令的完整能力远不止这篇文章里讲的这些比如资源组的批量管理、多资源克隆、对cib文件的离线编辑等都是很有用的进阶功能。等你把基础的集群管理玩熟了自然能慢慢摸到那些更细的门道。
PCS命令详解：从高可用集群原理到生产环境故障切换实践
在客户现场排查集群故障时我最常用的命令就是pcs status。很多人第一次听到PCS脑子里蹦出来的是储能逆变器但在Linux高可用集群这个圈子里PCS指的是Pacemaker/Corosync Configuration System也就是管理Pacemaker和Corosync集群的核心命令行工具。这篇文章就围绕Linux系统中PCS命令的使用展开从概念解析到环境准备再到资源管理、故障切换验证最后是排障经验把我在生产环境里真正用到的pcs命令讲透适合刚接触HA集群的运维新人也适合已经在用但想系统梳理一遍的同学。1. PCS命令到底在管什么1.1 先把概念理清楚先把这个名字拆开。PCS全称Pacemaker/Corosync Configuration System它是个命令行工具用来配置和管理由Pacemaker和Corosync组成的高可用集群。Corosync负责集群成员间的通信、心跳检测和投票机制Pacemaker则根据集群状态决定资源在哪台节点上运行。PCS把这两者的配置文件统一管理起来让你不用手动去改XML格式的CIBCluster Information Base文件。很多初学者会问既然Pacemaker和Corosync是核心为什么非要再用一个PCS早年管理Corosync集群确实没有统一工具要手动编辑/etc/corosync/corosync.conf然后用crm命令或直接操作cibadmin去改CIB。RHEL 7之后官方把pcs作为标准管理工具预装进来取代了早期版本里的ricci和luci组合。pcs命令的价值在于它把认证、配置文件生成、资源管理、约束配置、日志查看都收拢到一套命令族里极大降低了操作门槛。1.2 为什么实际工作中离不开pcs命令在RHEL 8/9、Rocky Linux、AlmaLinux以及一系列国产化Linux发行版里pcs都已经成为RHCSRed Hat Cluster Suite高可用组件的默认管理入口。生产环境里做数据库双机、Web服务主备、NFS故障切换底层跑的基本都是CorosyncPacemakerpcs这套组合。我在项目里最深的感受是pcs命令的设计思路非常贴近运维习惯。它把操作分成几个清晰的命令族pcs cluster管集群本身pcs resource管资源pcs constraint管约束pcs property管全局属性pcs node管节点状态pcs status看全貌。这种模块化的设计让排查问题时能很快定位到对应命令而不是在一大堆XML里翻找。注意RHEL 6时代的RHCS用的是rgmanagerCMAN管理命令是clustat和clusvcadm和现在的pcs完全是两套东西。如果你看的旧教程里全是clusvcadm那多半是过时内容要留意版本差异。2. 上手之前的准备2.1 环境规划与基础配置我在实际部署时最少会用两台节点搭一个集群来演示生产环境一般三台起步。节点的hostname必须唯一而且最好在/etc/hosts里把各节点的主机名和IP对应关系写清楚。这个细节经常坑人Corosync默认依赖主机名解析来识别节点如果主机名解析不到IP后端的服务就会报错集群状态也一直起不来。两个节点的操作系统我习惯统一避免因为系统库版本差异带来不必要的麻烦。所有节点都要能互相通过SSH访问后续pcs cluster auth认证过程要用到这个。如果有多块网卡建议指定独立的集群通信网段不要跟业务流量混在一起否则高负载时的网络抖动很可能触发节点被误判为故障生产环境里我吃过这个亏。2.2 安装与初始认证以Rocky Linux 9为例先在所有节点上安装软件包yum install -y pcs pacemaker corosync fence-agents-all这里fence-agents-all不一定要装全但建议至少装上跟你实际环境对应的fence agent后面配置stonithfencing会用到不然集群默认stonith-enabled没关资源切换可能会被卡住。安装完成后需要设置hacluster用户密码这个用户是pcs用来在各节点间通信的专用账号passwd hacluster然后启动pcsd服务并设为开机自启systemctl enable --now pcsd.service准备工作做完了接下来才是关键。先执行集群认证把当前节点和需要加入集群的节点互相“握手”pcs host auth node1.cloud.local node2.cloud.local -u hacluster -p 你的密码提示生产环境里不要把密码直接写在命令行里建议使用交互式输入。写本文是为了方便展示实际脚本里可以用--force配合密钥或使用pcs host auth的交互模式。3. 核心操作从创建集群到日常管理3.1 创建集群并启动认证完成后在其中一个节点上创建集群。这里要指定集群名称和参与集群的节点列表pcs cluster setup mycluster node1.cloud.local node2.cloud.local这个命令会自动生成/etc/corosync/corosync.conf并把配置同步到所有认证过的节点。生成完后启动集群pcs cluster start --all启动后第一件事就是用pcs status确认集群是否正常。一个健康的集群输出大概长这样Cluster name: mycluster WARNINGS: No stonith devices and stonith-enabled is true Cluster Summary: * Stack: corosync * Current DC: node1 * Last updated: ... * Last change: ... * 2 nodes configured * 0 resource instances configured PCSD Status: node1: Online node2: Online如果看到Current DC能选出来节点节点状态都是Online说明集群底层通信已经建立。这里经常有新手被WARNINGS吓到其实就是在提醒你还没配fencing设备先把stonith-enabled关了或者把fence配好就行后面会细说。3.2 资源管理的常用命令集群建好后用pcs resource系列命令来定义业务资源。先看两个基本操作# 创建一个IP地址资源 pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip192.168.1.100 cidr_netmask24 op monitor interval5s # 查看当前资源状态 pcs resource show这里有个概念要理解ocf:heartbeat:IPaddr2这一串是资源代理的类型。OCF是Open Cluster Framework标准heartbeat是代理集合名IPaddr2是具体代理脚本。pcs只是把这些信息组装成资源定义真正执行检测和控制的是对应脚本。资源常见的操作还有# 将资源迁移到指定节点一般会先standby目标节点 pcs resource move virtual_ip node2 # 清理资源的状态和failcount pcs resource cleanup virtual_ip # 禁用/启用资源 pcs resource disable virtual_ip pcs resource enable virtual_ipcleanup命令是我最常用的重置手段。资源一旦连续多次监控失败Pacemaker会记录failcount超过阈值后资源会停止迁移如果代码逻辑有问题或者网络抖动导致监控失败failcount一高资源就可能一直停在某个节点上不动。这时候pcs resource cleanup能清空失败计数让Pacemaker重新评估。3.3 约束与属性配置只创建资源还不够要让资源合理地运行在集群里还得配置约束。约束分三种顺序约束order、位置约束location、排列约束colocation。举一个典型的Web高可用场景虚拟IP要跟着Apache服务走Apache起来了VIP才能配置上去而且这两个资源最好调度到同一个节点。对应命令如下# 创建Apache资源 pcs resource create web_service systemd:httpd --no-default-ops # 设置顺序约束先启动virtual_ip再启动web_service pcs constraint order start virtual_ip then start web_service # 设置排列约束web_service和virtual_ip必须在同一节点 pcs constraint colocation add web_service with virtual_ip INFINITY # 设置位置约束让web_service尽量跑到node1 pcs constraint location web_service prefers node150顺序约束解决依赖问题排列约束解决“同一资源组必须在一起”的问题位置约束影响资源调度优先级。这三类约束都用pcs constraint管理用pcs constraint list可以查看当前所有约束。属性配置方面用得最多的是pcs property。比如no-quorum-policy、stonith-enabled、cluster-recheck-interval这些# 双节点集群没有冗余投票需要设置忽略仲裁 pcs property set no-quorum-policyignore # 没有fencing设备时先关闭stonith pcs property set stonith-enabledfalse注意no-quorum-policyignore只在双节点时是合理的因为两台节点挂一台就没了法定票数如果不开ignore另一台节点会主动释放资源业务直接中断。三台及以上节点强烈建议保留默认的stop策略并在仲裁上做合理规划。4. 一个完整示例用pcs部署Web高可用集群4.1 准备阶段这里我以两台Rocky Linux 9节点为例主机名分别是ha1和ha2业务IP规划如下节点管理IP集群通信IP备注ha1192.168.1.1110.10.10.11主节点ha2192.168.1.1210.10.10.12备节点虚拟IP192.168.1.100-对外提供服务先在每台节点上安装必要的软件包这里把httpd和之前提到的pcs/pacemaker/corosync一起装好dnf install -y pcs pacemaker corosync fence-agents-all httpd设置hacluster密码并设置pcsd开机自启然后确认两台节点的主机名解析没问题ping -c 2 ha1 ping -c 2 ha2一切通顺后执行认证pcs host auth ha1 ha2 -u hacluster4.2 创建资源和约束在ha1上创建集群并启动pcs cluster setup webcluster ha1 ha2 pcs cluster start --all由于两台节点环境里没有真实的fencing设备我先临时关闭stonith同时设置仲裁策略pcs property set stonith-enabledfalse pcs property set no-quorum-policyignore接着创建VIP和Apache资源pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip192.168.1.100 cidr_netmask24 op monitor interval5s pcs resource create web_service apache \ configfile/etc/httpd/conf/httpd.conf \ op monitor timeout5s interval10s这里需要注意我用的Apache资源代理是apache如果你用的不是默认安装路径可以配合httpd参数指定可执行文件或配置路径。上面这样写完先不加约束手动触发一次两个资源的调度测试看看能否正常在不同节点上启动再配置约束pcs constraint order start virtual_ip then start web_service pcs constraint colocation add web_service with virtual_ip INFINITY配置完约束后用pcs status确认。正常情况下两个资源会同时运行在同一个节点上比如都在ha1上。pcs resource show能查看每个资源的当前节点和详细参数。4.3 验证故障切换高可用集群的核心价值就是在节点故障时让资源自动存活。我用pcs node standby ha1模拟一台节点被主动下线pcs node standby ha1执行后大概几秒钟内Pacemaker会检测到ha1不再适合承载资源自动在ha2上启动VIP和Apache服务。用下面的命令验证pcs status ip addr show如果VIP出现在ha2的网卡上而且pcs status里资源显示started on ha2就说明故障切换流程跑通了。之后恢复ha1pcs node unstandby ha1再观察一阵如果我没有配置位置约束Pacemaker不会因为ha1恢复了就立刻把资源切回去这是正常设计。想手动把资源切回ha1可以用pcs resource move web_service ha1。心得真实生产里我会故意拔一根网线或者systemctl stop corosync来测故障切换而不仅仅用standby。因为standby是“优雅下线”Pacemaker能提前收到信号而真实的故障是突然中断心跳这才会真正考验fencing和资源恢复逻辑。两者测试结果可能完全不同。5. 常见问题与排障经验5.1 集群起不来的排查路径集群和网络一样90%的问题出在细节上。先看一个典型场景执行pcs cluster start --all结果ha1提示成功ha2提示失败。这时候按顺序排查确认ha2上的pcsd.service是否在运行systemctl status pcsd确认ha1和ha2之间的集群通信端口是否通畅Corosync默认用UDP 5405要保证iptables/firewalld没有拦截查看/var/log/cluster/corosync.log和journalctl -u corosync -f我自己踩过最多次的坑是firewalld。很多发行版默认开firewalld而且没有放行5405端口集群创建一个小时都连不上最后在日志里看到一堆“corosync: Totem is unable to form a cluster”一查就是UDP包被防火墙丢了。解决办法firewall-cmd --permanent --add-port5405/udp firewall-cmd --permanent --add-port2224/tcp firewall-cmd --reload注意2224端口是pcsd做Web管理用的如果要远程用pcs命令这个端口也得放行。5.2 资源反复漂移或启动失败资源在两个节点之间来回切换多半是监控操作触发了失败。打开资源详情看看pcs resource debug-monitor virtual_ip pcs resource show web_service --full--full能看到完整的注册参数和操作定义。如果资源启动几秒后立刻失败重点看对应资源代理的日志输出比如Apache的/var/log/httpd/error_log。我见过一个比较典型的问题两台节点上的httpd都装好了但其中一台的ServerName没设置Apache启动时报错Pacemaker检查到失败后把资源切到另一台反复几次后failcount过高资源直接不启动了。遇到这种问题先pcs resource cleanup web_service清掉失败计数再定位启动失败的根本原因。不要光靠重启解决cleanup只是让Pacemaker重新尝试真正的问题还在。5.3 脑裂和fencing的取舍脑裂是所有集群最怕出现的情况。两台节点无法通信但都以为自己活着于是同时启动VIP、同时对外提供服务双写冲突直接数据损坏。Corosync的投票机制能避免一部分脑裂但在双节点环境下如果没有配置fencing出问题时会非常尴尬节点A觉得节点B死了节点B觉得节点A死了两边都持有资源谁也说服不了谁。所以在生产环境stonith-enabledtrue必须开并且要配置真实可用的fencing设备比如IPMI、iLO、iDRAC或者云平台的fence agent。配置示例pcs stonith create my_ipmi fence_ipmilan \ pcmk_host_listha1 ha2 \ ipaddr192.168.1.11 \ loginadmin \ passwd你的IPMI密码 \ lanplus1 \ op monitor interval300s如果确实没有fencing设备开发环境可以pcs property set stonith-enabledfalse但生产环境这么干等于裸奔。我见过一个案例两台节点因为网络抖动互相“打死”结果因为没配fencing最终两台节点同时抢负载均衡器后端导致数据库双写恢复花了两天。独家经验模拟脑裂最有效的方法不是关网卡而是用iptables -A INPUT -s 对方IP -j DROP这种单向丢包或者干脆断开集群通信网线。这样才能测试出Corosync隔离机制是否真的可靠同时也能验证fencing动作是否按预期触发。写在最后PCS命令这套工具链说难不难说简单也不简单。它的命令结构本身不复杂复杂的是底层原理和巡检思路。我自己早期用pcs时走过不少弯路最开始只会照着教程敲几行命令遇到问题就开始怀疑集群坏了后来才明白pcs只是把Corosync和Pacemaker的复杂配置翻译成了人类能看懂的命令它本身不解决业务问题真正解决问题要靠对集群机制的理解。给刚入门的朋友几个个人建议第一集群的所有节点系统时间一定要同步Corosync对时间偏差极敏感时间差太大会导致节点不断被踢出集群用chrony或者ntp做好时间同步是基础中的基础第二每次改动配置前用pcs config backup备份一下这是最省心的后悔药第三定期查看pcs status里的WARNINGS不要忽略它们很多隐患就是一开始不显眼后面变成大故障第四不要害怕在生产环境做故障演练模拟一次真实故障比看十遍教程都管用。PCS命令的完整能力远不止这篇文章里讲的这些比如资源组的批量管理、多资源克隆、对cib文件的离线编辑等都是很有用的进阶功能。等你把基础的集群管理玩熟了自然能慢慢摸到那些更细的门道。
