精读笔记（RHCA 英文教材）· RH436 Chapter 5 Troubleshooting High Availability Clusters
精读笔记（RHCA 英文教材）· RH436 Chapter 5 Troubleshooting High Availability Clusters
教材原文：RHCA 官方英文教材（PDF 第 161~200 页）（OCR 整书版已从本站移除，本页为章节精读） 关联知识：Ch2（quorum 观察）、Ch4（资源/组/约束）；本章=日志（corosync/pacemaker）、通知（MailTo/alert agent）、资源故障排障（failcount/debug-start/cleanup）、网络排障。 结构：4 个 Section（各带 Guided Exercise）+ 章末 Lab（lab: troubleshooting-review）。
Chapter Goal / Objectives（原文+译）
- GOAL: Identify, diagnose, and fix cluster problems（识别、诊断、修复集群问题）.
- OBJECTIVES: ① 检查并配置集群日志；② 配置集群事件通知；③ 用常规步骤诊断资源故障；④ 诊断集群网络通信问题。
5.1 Configuring Cluster Logging
corosync 日志
- corosync 写
/var/log/cluster/corosync.log+ syslog（journalctl、/var/log/messages 都可看）。 - 控制：
/etc/corosync/corosync.conf的logging { }块：to_logfile: yes+logfile:、to_stderr: yes（systemd 会转 journald）、syslog_priority等控制级别。 - 生效：改完在某节点执行
pcs cluster sync（同步全部节点）→ 各节点pcs cluster reload corosync；全集群重启则pcs cluster stop --all/start --all。 - 日志解读示例（节点 down 时）：
[KNET] link: host:1 link:0 is down、[KNET] host has no active links、[TOTEM] Token has not been received in 1237 ms等。
pacemaker 日志
- 默认跟 corosync 走 syslog；可用
/etc/sysconfig/pacemaker覆盖：PCMK_logfile（改文件）、PCMK_logfacility（syslog facility）、PCMK_logpriority（默认 info）、PCMK_debug=yes（全量 debug）。 - 改完
systemctl restart pacemaker（先pcs node standby本机再重启可不影响业务）；或整群重启。 - 关键检索串（实验验证）：
grep te_fence_node /var/log/pacemaker/pacemaker.log（请求 fencing 记录）、grep tengine_stonith_notify（fencing 成功通知：Peer … was terminated (reboot) by …）。 journalctl -l -u pacemaker.service -u corosync.service一站式查看。
5.1 GE（lab: troubleshooting-logs）
断网触发 fence → 在现 DC 上 grep 上述两串确认“请求隔离+隔离成功” → Ansible 改 /etc/sysconfig/pacemaker 开 debug → tail -f 看 debug: 行。
5.2 Configuring Cluster Notifications
pcs alert（通用告警框架）
- alert agent=外部脚本，集群事件时调用并把信息经环境变量传给脚本；agent 必须装在每个节点同一路径。
- 命令：
pcs alert create path=<agent> id=<name> [options k=v]、pcs alert update <id> …、pcs alert recipient add <id> value=<收件方> [options…]（邮件地址/文件路径按 agent 类型）、pcs alert show|config、pcs alert recipient update|delete|remove、pcs alert remove|delete。 - 官方示例 agent：
/usr/share/pacemaker/alerts/sample_alert.sh、alert_smtp.sh.sample（拷到 /var/lib/pacemaker 后 chown hacluster:haclient chmod 0755）。
MailTo 资源（最简单邮件通知）
- 往资源组里加一个 MailTo 资源，组启动/停止/迁移时就发邮件：
pcs resource create webmail MailTo email=student@workstation.lab.example.com subject="CLUSTER-NOTIFICATION" --group=firstweb。 - 前置：节点装
postfix mailx并启服务；收件工作站装postfix mutt、postconf -e 'inet_interfaces = all'、firewall 开 smtp、mkdir -m 0700 ~/Mail。测试通过再上线（不要“假装配好了”）。
5.2 GE（lab: troubleshooting-notification）
workstation 跑 prepare-workstation.yml（装 postfix/mutt、开 smtp、inet_interfaces=all）→ 节点跑 prepare-nodes.yml（postfix+mailx）→ 建 MailTo 资源 webmail（subject CLUSTER-NOTIFICATION）→ mutt 收信 → 再装 alert_smtp agent 到 /var/lib/pacemaker → pcs alert create id=mailme path=/var/lib/pacemaker/alert_smtp.sh options email_sender=donotreply@example.com + pcs alert recipient add mailme value=student@… → move 组/断网触发 → mutt 看 “cluster1: Resource operation” 主题邮件。
5.3 Troubleshooting Resource Failures
failcount 机制
- 资源失败→集群累加 failcount：
pcs resource failcount show <res>。 - start 失败 → failcount=INFINITY，资源被迫迁到其它节点；stop 失败同样 INFINITY 且会 fence 该节点（好让别处能启动）。
- 用 meta migration-threshold=N：N 次失败后才迁移（建时
pcs resource create … meta migration-threshold=5或 update 加）。 - 查失败详情：
pcs status的Failed Resource Actions（call=… status='Timed Out'/exitreason=…）、pcs resource config <res>（参数错没错）。
修复手段
- 改配置：
pcs resource update <res> <attr>=（空值=恢复默认）；更新资源定义会自动清零 failcount。 - 资源自身配置文件错（如 httpd 的 conf）→ 用其自带校验（
apachectl configtest）。 pcs resource debug-start <res> [--full]：failcount 全 INFINITY 无法自动启动时的强制前台启动，立即看成败与调试输出（可能卡住，Ctrl+C）。- 若问题在集群配置外修（如改了服务配置）：failcount 仍残留，需手动清：
pcs resource cleanup <res>（清理 failed operations）或pcs resource refresh <res>（移除整个操作历史）；--full作用于全部资源。
5.3 GE（lab: troubleshooting-resource）
firstwebserver 启动失败（pcs status 的 Failed Actions 见 'not installed' (5) environment is invalid）→ failcount show 三节点全 INFINITY → pcs resource debug-start firstwebserver --full 分析 → pcs resource config 发现 configfile=/etc/htttpd/conf/httpd.conf（拼写错）→ pcs resource update firstwebserver configfile= 清空回默认 → failcount 自动清零、组恢复服务。
5.4 Troubleshooting Cluster Networking
常见网络问题清单
- 防火墙：节点间被防火墙挡（尤其只挡集群服务不挡 ping/ssh）；public 侧也要放行业务端口。
- split network（断网成两半）：跨交换机/级联断→split-brain→丢节点；用冗余网络与多条互联减轻。
- 丢包/拥塞：链路饱和→偶发集群故障；私网（corosync）与公网/存储流量分网。
- 参考文档还给出互联网卡（KB 3068841）与延迟（KB 2823721）支持策略；多链路配置见“Creating a high availability cluster with multiple links”。
5.4 GE（lab: troubleshooting-issue）
症状：nodec 离线、其余两节点 quorum 仍在但任何再故障就全停。排查：a/b 上 ping nodec 各网卡全通（排除网络本身）→ nodec 上 pcs status 只见自己 Online（集群服务在跑但通信被挡）→ firewall-cmd --list-all 看似正常 → firewall-cmd --direct --get-all-rules 发现 ipv4 filter OUTPUT 2 -p udp --dport=5405 -j DROP（封了 corosync UDP 5405）→ 移除 rich rule + direct rule → 三节点 Online 恢复。
Lab 概要（lab: troubleshooting-review）
四节点群两个资源组都“消费者访问不到”：troubledb（MariaDB，172.25.250.81）与 troubleweb（http，172.25.250.80）——排查顺序：① pcs status 看 Failed Resource Actions；② MariaDB：资源全 Started 但客户端连不上→firewall-cmd --list-all 缺 mysql 服务→Ansible 开 mysql 端口；③ troubleweb：webserver Stopped、日志 grep webserver.*ERROR 见 /etc/httpd/conf.d/oops.conf 语法错→删坏配置→pcs resource cleanup→curl 验证→grade。
命令速查表
| 用途 | 命令 |
|---|---|
| corosync 日志配置 | 改 /etc/corosync/corosync.conf logging{} → pcs cluster sync + pcs cluster reload corosync |
| pacemaker 日志配置 | 改 /etc/sysconfig/pacemaker（PCMK_logfile/facility/priority/debug）→ restart pacemaker |
| 一站式看日志 | journalctl -l -u pacemaker.service -u corosync.service |
| 日志检索 | grep te_fence_node /var/log/pacemaker/pacemaker.log；grep tengine_stonith_notify … |
| 建 alert | pcs alert create id=<n> path=<agent> [options k=v] |
| alert 收件人 | pcs alert recipient add <id> value=<v>；pcs alert show |
| MailTo 资源 | pcs resource create <n> MailTo email=<addr> subject=<主题> --group=<g> |
| 看 failcount | pcs resource failcount show <res> |
| 强制前台启动 | pcs resource debug-start <res> [--full] |
| 清 failcount | pcs resource cleanup <res> [--full]；pcs resource refresh <res> [--full] |
| 迁移阈值 | 建/改资源加 meta migration-threshold=N |
| 查防火墙直通规则 | firewall-cmd --direct --get-all-rules；删除 firewall-cmd --direct --remove-rule … |
| 实验/评分 | lab start troubleshooting-logs/notification/resource/issue；lab grade troubleshooting-review |
词汇表
| 英文 | 中文 | 速记 |
|---|---|---|
| to_logfile / to_stderr | corosync 日志去向 | conf 的 logging{}；stderr→journald |
| PCMK_logfile / PCMK_debug | pacemaker 日志开关 | /etc/sysconfig/pacemaker |
| te_fence_node | 请求隔离事件 | 日志 grep 关键字 |
| tengine_stonith_notify | 隔离完成通知 | “Peer … was terminated (reboot) by …” |
| alert agent / recipient | 告警代理/接收方 | 每节点同路径；收件人按 agent 类型 |
| MailTo | 邮件资源 | 组启停/迁移即发信 |
| failcount | 失败计数 | start/stop 失败→INFINITY |
| migration-threshold | 迁移阈值 | N 次失败才迁 |
| debug-start | 前台调试启动 | 全 INFINITY 时强启看输出 |
| cleanup / refresh | 清失败/清历史 | 前者清 failed ops，后者删整个历史 |
| Failed Resource Actions | 失败操作列表 | pcs status 中定位故障 |
| split network / split-brain | 断网成两半/脑裂 | 冗余网络减轻 |
| direct rule | firewalld 直通规则 | --direct --get-all-rules 抓“暗雷” |
自测 10 题
- corosync 与 pacemaker 日志配置文件各是？（/etc/corosync/corosync.conf 与 /etc/sysconfig/pacemaker）
- 改 corosync 日志后怎么生效？（pcs cluster sync → 各节点 pcs cluster reload corosync）
- 怎么在日志里确认一次成功 fence？（grep tengine_stonith_notify：Peer was terminated）
- alert agent 要装在哪？（每个节点同一路径）
- MailTo 与 pcs alert 有什么区别？（MailTo=资源组里的资源，组启停触发；alert=全局框架，任何集群事件触发）
- start 失败与 stop 失败的 failcount 各什么后果？（都 INFINITY；stop 失败还会 fence 节点）
- 何时需要 cleanup 而不是 update？（问题修在集群配置外时 failcount 残留，cleanup/refresh 手动清零）
- debug-start 在什么场景用？（资源在所有节点 failcount=INFINITY 无法自动启动）
- 网络排障抓到 UDP 5405 DROP 说明什么？（firewalld 挡了 corosync 单播流量）
- migration-threshold=5 含义？（5 次失败后资源才迁到别的节点）