第249集：集群故障排查

教学目标

1. 了解集群故障的常见类型和特征
2. 掌握集群故障排查的基本方法论和流程
3. 熟悉集群故障诊断工具和技术
4. 能够独立完成常见集群故障的分析和解决
5. 建立集群故障预防和监控机制

核心知识点讲解

1. 集群故障概述

1.1 集群故障的定义和影响

集群故障是指集群系统在运行过程中出现的异常状态，导致集群服务不可用或性能下降。集群故障的影响范围通常比单机故障更大，可能导致：

• 业务中断
• 数据丢失
• 系统性能严重下降
• 集群资源浪费

1.2 集群故障的分类

2. 集群故障排查方法论

2.1 故障排查的基本流程

1. 故障识别：确认故障发生，收集故障现象和影响范围
2. 故障分析：分析故障原因，定位故障点
3. 故障解决：实施解决方案，恢复集群正常运行
4. 故障验证：验证故障是否彻底解决
5. 故障总结：记录故障原因和解决方案，优化集群配置

2.2 故障排查的关键原则

• 系统性：从整体到局部，逐步缩小故障范围
• 逻辑性：基于事实和数据进行分析，避免盲目猜测
• 时效性：快速响应，减少故障影响
• 完整性：全面检查相关组件，确保故障彻底解决
• 预防性：分析故障根因，采取预防措施

3. 集群故障诊断工具

3.1 系统级诊断工具

3.2 集群专用诊断工具

4. 常见集群故障分析与解决

4.1 网络故障

症状：

• 集群节点间通信中断
• 集群分裂（脑裂）
• 资源无法正常迁移

常见原因：

• 网络电缆松动或损坏
• 网络交换机故障
• 防火墙规则配置错误
• 网络分区（网络分区导致集群节点无法相互通信）

解决方案：

1. 检查网络连接和物理设备
2. 验证网络配置和防火墙规则
3. 使用网络诊断工具测试连通性
4. 配置网络冗余和故障转移
5. 调整集群心跳超时设置

4.2 资源故障

症状：

• 资源启动失败
• 资源状态异常
• 资源无法迁移

常见原因：

• 资源配置错误
• 资源依赖关系问题
• 资源冲突
• 资源所需服务未运行

解决方案：

1. 检查资源配置文件
2. 验证资源依赖关系
3. 查看资源启动日志
4. 手动测试资源启动
5. 调整资源约束和优先级

4.3 节点故障

症状：

• 节点离线
• 节点无法加入集群
• 节点资源无法访问

常见原因：

• 服务器硬件故障
• 操作系统崩溃
• 集群服务未启动
• 网络连接中断

解决方案：

1. 检查节点硬件状态
2. 验证节点网络连接
3. 启动集群服务
4. 重新引导节点
5. 替换故障硬件

4.4 脑裂故障

症状：

• 集群分裂为多个子集群
• 多个节点同时成为主节点
• 数据不一致

常见原因：

• 网络分区
• 心跳超时设置不当
• 节点时钟不同步

解决方案：

1. 配置仲裁机制（quorum）
2. 调整心跳超时设置
3. 实现STONITH（Shoot The Other Node In The Head）
4. 配置网络冗余
5. 同步节点时钟

4.5 存储故障

症状：

• 存储卷挂载失败
• 数据读写错误
• 存储服务不可用

常见原因：

• 磁盘故障
• 文件系统损坏
• 存储网络故障
• 存储配额超限

解决方案：

1. 检查存储硬件状态
2. 验证存储网络连接
3. 修复文件系统错误
4. 扩展存储容量
5. 配置存储冗余

5. 集群故障预防策略

5.1 监控与预警

• 部署全面的集群监控系统
• 设置合理的监控指标和告警阈值
• 实施多维度监控（系统、网络、存储、应用）
• 建立24/7告警响应机制

5.2 配置管理与版本控制

• 使用配置管理工具（Ansible、Puppet）
• 实施配置版本控制
• 建立配置变更审核机制
• 定期备份集群配置

5.3 定期维护与测试

• 制定集群维护计划
• 定期进行集群健康检查
• 实施故障演练和恢复测试
• 定期更新集群软件和补丁

5.4 文档与知识管理

• 建立集群架构和配置文档
• 记录故障处理过程和解决方案
• 建立集群故障知识库
• 定期培训和知识分享

实用案例分析

案例1：Pacemaker集群脑裂故障排查

故障现象：

• 集群分裂为两个子集群
• 两个节点都认为自己是主节点
• 资源在两个节点上同时运行

故障分析：

1. 检查网络连接：发现节点间网络中断
2. 查看集群状态：pcs status 显示两个独立的集群
3. 分析日志：journalctl -u pacemaker 显示心跳超时

解决方案：

# 1. 停止其中一个节点的集群服务
pcs cluster stop node2

# 2. 检查网络连接并修复
ping node1
# 修复网络故障（如重启网络服务、更换网线等）

# 3. 清理节点2的集群状态
pcs cluster clean node2

# 4. 重新启动节点2的集群服务
pcs cluster start node2

# 5. 验证集群状态
pcs status

预防措施：

• 配置STONITH设备
• 调整心跳超时设置（pcs property set stonith-timeout=60s）
• 实现网络冗余

案例2：Kubernetes集群节点不可用故障

故障现象：

• kubectl get nodes 显示节点状态为 NotReady
• 节点上的Pod无法访问
• 新Pod无法调度到该节点

故障分析：

1. 检查节点状态：kubectl describe node <node-name>
2. 查看kubelet服务状态：systemctl status kubelet
3. 分析kubelet日志：journalctl -u kubelet
4. 检查节点资源使用情况：top、df -h

解决方案：

# 1. 检查kubelet服务
systemctl status kubelet

# 2. 如果kubelet未运行，启动服务
systemctl start kubelet

# 3. 检查节点内存和磁盘使用情况
df -h
free -m

# 4. 如果磁盘空间不足，清理空间
docker system prune -f

# 5. 重启kubelet服务
systemctl restart kubelet

# 6. 验证节点状态
kubectl get nodes

预防措施：

• 设置节点资源预留
• 配置Pod优先级和驱逐策略
• 实施节点自动扩缩容

案例3：Ceph存储集群OSD故障

故障现象：

• ceph status 显示集群状态为 HEALTH_WARN 或 HEALTH_ERR
• OSD状态为 down 或 out
• 存储性能下降

故障分析：

1. 查看OSD状态：ceph osd tree
2. 检查OSD日志：journalctl -u ceph-osd@<osd-id>
3. 验证存储设备状态：lsblk、smartctl -a /dev/sdX

解决方案：

# 1. 检查OSD状态
ceph osd tree

# 2. 检查OSD所在节点的存储设备
lsblk

# 3. 如果是临时故障，尝试重启OSD
systemctl restart ceph-osd@<osd-id>

# 4. 等待OSD重新加入集群
ceph osd tree

# 5. 如果OSD无法恢复，替换故障磁盘并重建OSD
# 标记OSD为out
ceph osd out <osd-id>
# 停止OSD
systemctl stop ceph-osd@<osd-id>
# 从集群中移除OSD
ceph osd purge <osd-id> --yes-i-really-mean-it
# 替换故障磁盘后，创建新OSD
ceph-volume lvm create --data /dev/sdX

预防措施：

• 配置OSD自动故障检测和处理
• 实施存储设备健康监控
• 定期检查存储设备状态

课后练习

1. 基础练习

   • 使用 pcs status 命令检查Pacemaker集群状态，分析输出信息
   • 使用 kubectl get events 命令查看Kubernetes集群事件，识别潜在故障
   • 使用 ceph health detail 命令分析Ceph集群健康状态

2. 进阶练习

   • 模拟网络分区故障，观察集群行为并记录解决方案
   • 模拟Kubernetes节点资源耗尽故障，实施故障恢复
   • 分析Ceph集群OSD故障日志，制定故障处理方案

3. 综合练习

   • 设计一个集群故障排查流程文档，包括常见故障类型、分析步骤和解决方案
   • 配置集群监控系统，设置关键指标告警
   • 实施集群故障演练，测试故障检测和恢复机制

总结

集群故障排查是系统管理员的核心技能之一，需要掌握系统化的方法和丰富的实践经验。通过本教程的学习，我们了解了集群故障的类型和特征，掌握了故障排查的基本流程和工具，学会了分析和解决常见集群故障的方法。

在实际工作中，集群故障排查需要结合具体的集群类型和环境，灵活运用各种诊断工具和技术。同时，建立完善的监控和预防机制，定期进行维护和测试，是减少集群故障发生的关键措施。

通过不断积累故障处理经验，建立故障知识库，系统管理员可以逐步提高集群故障排查的效率和准确性，确保集群系统的稳定运行。