深度解析，RHEL 7 集群节点反复重启的排查与解决指南

在高可用性（HA）架构中，RHEL 7 集群的核心价值在于确保业务连续性，当集群中的某个节点出现反复重启的现象时，不仅会导致业务中断，还可能引发脑裂、数据不一致等严重后果，作为系统管理员，快速定位并解决这一问题至关重要。

本文将深入探讨 RHEL 7 集群节点反复重启的常见原因，并提供一套系统的排查与解决思路。

现象确认与日志分析

当节点出现反复重启时，首先不要急于重装系统，因为硬件故障或内核崩溃可能会在重装后再次发生，请按照以下步骤进行日志分析：

查看系统日志： RHEL 7 使用 journalctl 管理日志，首先检查内核日志和系统日志，寻找“Kernel panic”或“Out of memory”等关键信息。
```
journalctl -k -b 0  # 查看本次启动的内核日志
journalctl -xe      # 查看详细的系统事件日志
```
检查 /var/log/messages： 传统的系统日志文件中往往包含硬件驱动程序的错误信息或特定的服务崩溃记录。
```
grep -i "panic\|out of memory\|error" /var/log/messages
```

通过日志分析,我们可以将反复重启的原因归纳为以下四大类：

这是最常见的原因之一,当集群节点运行的服务过多，或某个进程内存泄漏，导致物理内存耗尽，Linux 内核会触发 OOM Killer，强制终止进程甚至重启系统。

排查方法： 检查日志中是否有 Out of memory: Kill process 字样。
解决方案：
- 优化应用程序的内存使用。
- 调整 /etc/sysctl.conf 中的 vm.overcommit_memory 参数。
- 增加节点的物理内存。

集群节点之间依赖 Corosync 和 Pacemaker 进行心跳通信，如果网络配置错误、交换机故障或 IP 地址冲突，会导致节点间无法通信，为了保护资源，集群服务可能会尝试重启节点，或者节点因为网络丢包率过高而触发 panic。

排查方法： 检查 corosync 的日志，确认 totem 协议的心跳是否丢失。
解决方案：
- 检查网卡配置,确保心跳网段（通常使用独立网卡）的带宽和稳定性。
- 检查防火墙（Firewalld）和 SELinux 是否阻止了 Corosync 端口（通常是 5405, 5404 等）。

如果日志中包含硬件层面的错误,如 RAID 控制器警告、磁盘 I/O 错误或电源供应不稳定，系统为了防止数据损坏，可能会选择重启。

排查方法：
- 使用 dmesg | grep -i error 查看硬件相关错误。
- 检查 smartctl 状态。
- 查看服务器硬件管理面板（如 IPMI/iLO/DRAC）记录的硬件告警。
解决方案：
- 更换故障的硬盘或 RAID 卡。
- 检查电源模块和散热系统。

在 RHEL 7 中，错误的资源约束配置可能导致资源无法启动，进而引发连锁反应，同一资源被错误地约束