华为云Stack故障排查实战：存储与网络域问题定位与OpenStack命令精解

1. 项目概述：云平台故障处理的实战视角

在云数据中心运维的日常里，故障处理从来都不是一个简单的“重启试试”就能解决的问题，尤其对于像华为云Stack这样集成了计算、存储、网络、管理服务的复杂平台。标题中提到的“存储域故障”、“网络域故障”，以及“OpenStack故障排查常用命令”，恰恰点中了云平台运维工程师最核心、也最头疼的几块内容。这不仅仅是命令的堆砌，更是一套从现象定位到根因分析，再到快速恢复的完整逻辑体系。我经历过无数次深夜告警，从存储池突然降级到虚拟网络大面积不通，每一次排查都是一次对平台架构理解深度和应急反应速度的考验。这篇文章，我就结合多年的实战经验，拆解华为云Stack中这些典型故障场景的处理思路、核心命令背后的原理，以及那些在官方文档里不会明说，却能帮你省下大量排查时间的“野路子”和避坑指南。无论你是正在备考HCIE-Cloud认证，还是已经奋战在一线的云运维工程师，希望这些凝结了实际教训的经验，能成为你工具箱里趁手的“瑞士军刀”。

2. 华为云Stack故障处理的核心逻辑与准备

2.1 故障处理的“黄金法则”：定界与定位

处理华为云Stack故障，切忌一上来就埋头敲命令。一个清晰的排查逻辑比掌握一百条命令更重要。我的习惯是遵循“先定界，后定位”的黄金法则。

定界 ，就是快速确定故障的影响范围和层次。当监控告警响起或用户报障时，首先需要判断：这是单个虚拟机（VM）的问题，还是某个主机（Host）的问题？是某个集群（Cluster）或可用区（AZ）的问题，还是整个资源池或某个服务域（如存储域、网络域）的全局性问题？通过管理平台（ManageOne或FusionSphere OpenStack OM）快速查看相关资源的整体状态，是绿色、黄色还是红色，能帮你迅速圈定排查范围。例如，如果只是一个VM无法访问，那么问题可能局限在该VM本身、其所在的宿主机或关联的网络端口；如果整个集群的VM都出现存储访问异常，那么怀疑的矛头就应该直指后端共享存储。

定位 ，是在定界的基础上，逐层深入，找到具体的故障根因。这需要你对华为云Stack的架构有清晰的认识。一个简单的用户访问故障，其路径可能涉及：用户终端 -> 外部网络 -> 负载均衡器 -> 虚拟路由器 -> 安全组 -> 虚拟交换机 -> 虚拟机网卡 -> 虚拟机内部。定位就是沿着这条路径，像“剥洋葱”一样，逐段验证其健康状况。华为云Stack的故障处理，很大程度上就是对其底层OpenStack各组件（Nova, Cinder, Neutron等）及其依赖服务（如数据库Galera，消息队列RabbitMQ）的状态诊断。

2.2 运维工具箱的准备：不仅仅是命令

工欲善其事，必先利其器。除了标题中会提到的OpenStack常用命令，一个成熟的运维工程师还会准备更多：

1. 统一的跳板机与权限管理 ：确保有一台可以通管理网络，并能通过SSH免密登录到所有控制节点、计算节点、存储节点和网络节点的跳板机。权限上，通常需要 root 或 nova 、 cinder 等服务的执行用户权限。
2. 日志收集与查看习惯 ：故障排查，十之八九要看日志。你必须知道关键日志的位置：
   • OpenStack组件日志：通常在 /var/log/<component>/ 下，如 /var/log/nova/ , /var/log/cinder/ , /var/log/neutron/ 。
   • 华为云Stack增强组件日志：可能在 /var/log/fusionsphere/ 相关目录。
   • 系统日志： /var/log/messages 或 journalctl -u <service-name> 。 我习惯在排查开始时，就使用 tail -f 或 less +F 实时跟踪相关日志，同时用 grep -E “ERROR|WARNING|Traceback” 快速过滤错误信息。
3. 监控与告警系统的深度使用 ：不要只把监控系统当成告警接收器。华为云Stack集成的监控能力（如Ceilometer采集，Grafana展示）能提供历史性能曲线，这对判断故障是突发还是渐进式恶化至关重要。例如，在排查存储性能问题时，查看存储池的IOPS、带宽、延迟历史图表，往往能先于用户感知到问题。

3. 存储域故障场景深度拆解与处置

存储是虚拟化平台的基石，存储域故障通常影响面广，业务恢复压力大。下面拆解几个典型场景。

3.1 场景一：虚拟机磁盘访问异常或IO挂起

现象 ：用户报告虚拟机内部磁盘操作极其缓慢，或直接卡死， dmesg 中可能出现 I/O error 或 target failure 的报错。在管理平台上，该虚拟机可能显示为“暂停”状态或任务持续进行中。

定界与定位思路 ：

1. 确定影响范围 ：在管理平台查看，是单个VM异常，还是同一主机、同一数据存储上的多个VM均异常？如果是后者，问题很可能出在共享存储链路或存储设备本身。
2. 检查虚拟机状态 ：在控制节点，使用 nova show <vm-uuid> 查看虚拟机详情，关注 OS-EXT-STS:vm_state 和 task_state 字段。如果 vm_state 是 error ，通常意味着底层创建或操作失败。
3. 追踪虚拟磁盘链路 ：这是关键步骤。通过 nova show <vm-uuid> 找到虚拟机的 hypervisor_hostname （所在计算节点）和挂载的卷ID。然后登录到该计算节点。
   • 使用 virsh domblklist <vm-instance-name> 列出虚拟机块设备，找到虚拟磁盘（vda, vdb等）对应的后端文件或设备，例如可能是 /var/lib/nova/instances/<instance-uuid>/disk （本地盘）或一个rbd设备路径（如 rbd:volumes/volume-xxx ）。
   • 如果后端是Ceph RBD，使用 rbd status <pool>/<image-name>@<snap-name> 查看镜像状态和客户端连接信息。使用 ceph health detail 和 ceph osd tree 检查Ceph集群健康状态和OSD分布。
4. 检查计算节点存储连接 ：在计算节点上，检查多路径状态 multipath -ll ，查看到存储的链路是否都正常（ active / undef 状态）。检查SCSI设备状态 lsblk 和 dmesg | grep -i scsi 查看是否有错误。

实操命令与示例 ：

# 1. 查看虚拟机详情，获取所在主机和卷信息
source /root/keystonerc_admin # 加载管理员环境变量
nova show c6b8a4b5-1a2b-3c4d-5e6f-123456789abc

# 输出中关注：
# | OS-EXT-SRV-ATTR:host | compute-node-01 |
# | volumes_attached     | [{"id": "volume-uuid-xxxx"}] |

# 2. 登录到计算节点 compute-node-01
ssh compute-node-01

# 3. 找到虚拟机实例名（通常与nova show中的OS-EXT-SRV-ATTR:instance_name一致）
virsh list --all | grep <partial-vm-uuid>

# 4. 列出该虚拟机的块设备
virsh domblklist <instance-name>
# 输出示例：
# Target     Source
# ------------------------------------------------
# vda        /var/lib/nova/instances/<instance-uuid>/disk
# vdb        rbd:volumes/volume-xxxx:id=admin:key=AQB...==:mon_host=192.168.1.10,192.168.1.11

# 5. 如果后端是RBD，检查该RBD镜像状态（需要ceph-common工具）
rbd -p volumes status volume-xxxx
# 检查Ceph整体健康
ceph health detail
ceph osd tree

常见根因与处置