简介《FusionCloud运维故障处理指南》是一份面向数据中心运维人员与云计算管理员的技术文档围绕FusionCloud物理分散、逻辑统一、业务驱动、云管协同的架构特点系统梳理故障排查路径。内容覆盖FusionCloud故障分类、FusionSphere OpenStack日志目录与查看方法如nova、cinder、neutron各组件的操作日志与运行日志路径并逐一展开虚拟机、存储、网络、主机及主机组、OpenStack服务以及ManageOne ServiceCenter节点等关键组件的故障处理同时结合典型案例分析、常见服务异常处理思路与高危操作注意事项帮助读者按图索骥快速定位问题。资源为单个PDF文件大小3.35MB目录结构清晰、内容紧凑适合作为运维团队的实战参考手册。已有110人学习下载适合正在使用或计划部署FusionCloud的运维工程师系统提升故障响应与处置能力。1. FusionCloud运维故障处理指南把它当成应急手册看比当成文档看有用凌晨两点被P2告警叫醒是云运维的常态。打开这份《FusionCloud运维故障处理指南》之前我习惯先把故障扔回框架里是管理面出了问题还是业务面在报警是云主机假死、存储性能劣化还是网络链路丢包这份PDF的价值不在于罗列多少命令而在于把FusionCloud里最常见的故障特征、定位命令和处置动作按层收敛成一条能照着走的路。适合正在做FusionCloud日常运维和故障处理的工程师也适合刚接手云平台、手头没有完整故障知识体系的新人。关键是先知道查哪一层、动哪个命令、什么情况下绝对不能乱动。2. 先懂框架再动手把故障分层定位才不用全链路瞎猜FusionCloud是基于OpenStack演进出来的云平台从下到上大致是物理设备层服务器、存储、交换机、虚拟化资源池计算节点、分布式存储、云服务层ECS、VPC、EVS、IMS以及最上层的管理面CPS、ManageOne、告警中心。运维里最忌讳一上来就抓着某个命令反复跑分不清故障属于哪一层。我的习惯是先问三个问题虚机动不动网络通不通管理面还能不能登录把这三个问题答完排查范围至少缩小一半。分层的第二个原因是处置原则不同。业务面故障优先恢复业务管理面故障优先保证不扩大影响面。很多刚入行的运维在管理节点上报错时第一反应是重启管理节点结果把正在运行的云主机心跳一起搞断了。所以接下来先把管理面和业务面的判别方法说清楚。2.1 分清管理面和业务面故障定位的第一步管理面故障的典型特征是ManageOne页面打不开、CPS任务卡住、API网关返回超时但云主机上的业务流量基本正常。业务面故障则相反虚机内部丢包、IO卡死、网络时延飙升管理面反而能看到一堆ERROR状态。判断方法不复杂先做一次轻量探测再决定操作路径。#!/bin/bash # 快速区分管理面/业务面的可用性检查脚本 CPS_IP10.10.10.11 API_URLhttp://$CPS_IP:31943/healthcheck # 检查管理面健康检查接口是否返回 200 curl -s -o /dev/null -w manage_api_http_code:%{http_code}\n --connect-timeout 5 $API_URL # 检查计算节点上的 nova-compute 服务是否存活 systemctl status nova-compute --no-pager | grep -E Active: || echo nova-compute down # 查看是否有 ERROR 状态的云主机注意加 --all-projects source /etc/nova/adminrc 2/dev/null openstack server list --status ERROR --all-projects -c ID -c Name -f value 2/dev/null这段脚本的逻辑是先探管理面健康接口再查计算节点核心服务最后看租户侧有没有ERROR状态的虚机。参数说明CPS_IP按各环境管理节点地址修改31943是常见健康检查端口不同版本可能有差异执行前先确认--all-projects很关键不加它只会看当前项目租户一多就漏掉其他项目的故障虚机。如果管理面接口返回非200优先处理管理面如果管理面正常但云主机大范围ERROR把精力放到业务面。这里有一条实操准则管理面故障时先看CPS的组件状态别急着重启任何服务业务面故障时先确认虚机、网络、存储的实际表现再决定在哪个层动手。判断完这一层后面所有操作才谈得上顺序。2.2 巡检脚本与健康检查把指标变成可执行动作故障处理不能等告警响了才开始。日常巡检里把指标盯住很多事故可以在P2告警之前就被拦下来。我这里整理了一张巡检表基本把FusionCloud日常最关键的检查对象都覆盖了。检查对象重点指标阈值参考风险提示计算节点CPU使用率、load average持续15分钟高于85%关注CPU抢占会导致云主机内时钟漂移计算节点内存available、swapswap使用量持续增长要查内存超卖会触发内核hung task管理节点系统盘/data盘inode使用率超80%提前清理小文件日志最容易先爆inode分布式存储时延、重建状态时延持续高于25ms要介入重建状态未结束前不宜做主备切换网络节点OVS流表数量、连接跟踪流表数超阈值要检查连接跟踪满会导致新建连接失败证书体系服务证书有效期剩余不足30天安排轮转证书过期表现为服务间互信失败时间同步NTP/chrony偏移量偏移超过1秒要纠正时间漂移会让token校验直接失败巡检脚本不用写得多花哨能把状态捞出来、能对比趋势就够了。下面这段是我常用的磁盘检查脚本重点就是查inode。#!/bin/bash # 巡检脚本片段重点检查 /var/log 和 /opt 分区的容量与 inode for mount_point in /var/log /opt; do echo $mount_point df -h $mount_point | tail -1 df -i $mount_point | tail -1 done # 检查内核日志是否有 hung_task 或长时间阻塞的痕迹 journalctl -k -p err --since 24 hours ago | grep -iE hung_task|blocked for more than | tail -10逻辑说明df -h看容量df -i看inode两行输出放在一起才能反映真实可用性。很多人只看容量不看inode日志盘满了以后文件写不进去但df -h显示还有几个GB容易误判。参数说明/var/log和/opt是云平台日志与软件包最常见的存放路径按实际环境调整journalctl的-p err过滤出错误级别内核日志--since时间窗口按巡检频率来定日检就用24 hours。巡检频率我的建议是每日自动跑一轮基础健康检查每周做一次深度巡检每次变更后追加一轮专项检查。巡检的价值不在“跑一遍”而在对比前两天数据看趋势。绝对值高但稳定通常比绝对值低但突然飙升更安全。2.3 日志抓取命令与参数动手前先留证据故障定位到一半最容易犯的错误是还没留证据就开始操作。等操作完才发现需要对比故障时的状态现场已经被破坏了。所以我在FusionCloud环境里动手前的第一步永远是抓日志抓取工具的常见名字是collectDiagnostic不同版本可能叫fma或fscm collect log直接执行--help就能看到当前版本的参数。# 抓取 nova 模块最近 2 小时的日志输出到指定目录 collectDiagnostic -m nova -t 2025-01-01_000000_2025-01-01_020000 -l 10 -o /home/admin/log # 抓取当前运行状态快照作为后续操作的基线 fscm dump --status /home/admin/fscm_status_$(date %Y%m%d%H%M).txt逻辑说明先抓故障时间窗口内的模块日志再抓一整个状态的快照这样后面无论是重启服务还是调整配置都有前后对比的依据。-m指定模块-t指定起止时间-l指定日志级别-o指定输出目录。不同版本的工具对这几个参数的定义略有差别执行之前先跑一次collectDiagnostic --help确认。日志路径也有规律可循nova相关日志在/var/log/novacinder相关在/var/log/cinderCPS自身的任务日志一般在/opt/cps/log下数据库日志则要看管理面数据库的配置。抓日志时建议先抓一个小时间窗口确认内容格式再扩大范围避免一次采集时间过长把本就不富裕的日志盘写满。给现场留证据这件事花五分钟后面省五小时。3. 高频故障的定位与恢复虚拟机、存储与网络三块硬骨头真正运行一段时间之后你会发现故障工单里占大头的永远是三件事云主机假死、存储性能劣化、网络链路异常。这三类问题有个共同特点表象都是“节点好像挂了”但根因分布在不同层。这一章把每条链路的关键动作拆开讲。3.1 云主机假死与HA反复重启别急着踢节点现象很典型云主机状态还是active但业务连不上VNC黑屏或卡死平台侧HA在反复尝试重启这台虚机。不少人第一反应是直接reboot计算节点这几乎是最坏的选择同一物理机上还跑着其他租户的虚机重启等于连坐。正确路径是先确认是计算节点问题还是这台虚机自己的问题。下面这段命令组合能快速缩小范围。# 登录计算节点先看虚机管理状态和资源统计 virsh list --all | grep instance-xxx virsh domstats instance-xxx --state --vcpu --balloon # 看存储层面的 IO 水线判断是否卡在磁盘读写 iostat -x 1 5 # 查内核是否有 hung task 记录 dmesg -T | grep -iE hung_task|blocked for more than # 确认计算节点内存超卖情况 free -g逻辑说明第一行确认虚机在libvirt层的状态state、vcpu、balloon三个参数分别对应运行状态、每路vCPU的统计和内存气球第二行iostat -x每秒采样一次共5次重点看%util和await如果await很高但%util不高大概率是设备端排队第三行dmesg查hung task内核里“blocked for more than 120 seconds”出现就说明有进程长时间处于不可调度状态。参数说明instance-xxx替换成实际虚机UUIDfree -g以GB为单位看内存余量对比该节点上所有虚机的内存配额就能算出超卖比例。处理上我一般遵循先在平台内对故障虚机做一次重启或热迁移把业务挪到健康节点如果虚机连迁移都做不了再考虑排查计算节点本身。节点层面确认是内存超卖就调整超卖比别靠重启解决。HA反复重启的真正含义是“底层没恢复”而不是“重启次数不够”。3.2 存储bitmap与性能劣化先确认重建条件再切主备分布式存储的bitmap机制本质是一种位图标记用来记录异常掉电或链路闪断后哪些数据块需要重建。FusionCloud的存储池在异常中断后会进入重建或重同步状态这个阶段业务IO性能会有明显劣化。很多运维一看到时延高就急着切主备结果主备切换会触发新的重建过程性能反而雪上加霜。正确做法是先确认重建状态和进度再判断要不要介入。存储运维工具在不同产品版本里名字不一样常见的有storadm或统一存储面板核心看几个字段。# 查看存储集群健康状态工具名以当前环境为准 storadm cluster status storadm pool status --detail # 对比重建期间和重建结束后的盘级时延 iostat -d 1 5 -x | grep -E Device|sdb # 确认存储节点间网络是否有丢包这是重建卡住最常见的原因 ping -c 100 -i 0.2 storage_node_ip | tail -3逻辑说明先看集群和存储池状态确认是否处于rebuild或resync再看盘级时延判断瓶颈在业务负载还是重建任务最后用ping验证存储节点间网络。参数说明iostat里的Device列显示具体盘符sdb按实际情况替换ping -c 100指定100个包-i 0.2表示每0.2秒一个丢包率超过0.1%就要警惕。这里有个常见误用提醒重建百分比长时间停在某个数值不动大多数原因是节点间网络丢包而非存储节点故障。此时优先排查交换机端口、光模块、网卡协商速率不要重启存储节点。重启一次重建从头再来业务侧的时延会进一步拉高。如果把重建状态和业务时延按时间轴画成曲线你会发现两者几乎正相关与其反复切主备不如让它安静重建完。3.3 网络链路与南北向流量在虚拟化层找到丢包点网络问题的定位顺序应该自下而上物理网卡有没有丢包OVS网桥有没有异常安全组和连接跟踪有没有触发限流最后才是网关设备。跳过物理层直接查业务层是运维里最常见的弯路。云平台里看OVS是基本功下面这组命令能快速判断虚拟网络层的基本状态。# 查看 OVS 网桥和端口状态 ovs-vsctl show # 统计流表项数量判断是否接近流表上限 ovs-ofctl dump-flows br-int | wc -l # 查看连接跟踪和 NAT 相关流表命中情况 ovs-appctl dpctl/dump-flows br-int 2/dev/null | grep -E nat|ct_zone | head -20 # 查看物理网卡软中断分布 cat /proc/interrupts | grep -i eth0逻辑说明ovs-vsctl show看网桥是否完整、端口有没有异常Down流表数量直接反映转发规则规模流表溢出时新连接会被丢弃dpctl/dump-flows里的nat和ct_zone字段对应NAT和连接跟踪区域命中异常说明安全组或SNAT/DNAT配置有问题。参数说明br-int是集成网桥是云平台虚拟网络流量的必经之路软中断集中在单个CPU上时考虑调整RPS或队列数来做负载均衡。安全组和连接跟踪是另外两个常见坑安全组规则过多会拖慢每个包的处理速度连接跟踪表满会导致新建连接直接失败。排查时如果看到netfilter的conntrack表满的报错优先扩容连接跟踪参数而不是去业务侧找原因。记住网络排查的节奏从物理链路往虚拟交换机再往安全策略走每一步都有明确的通过/不通过标准。4. 避坑清单FusionCloud运维现场经常翻车的几个点这一章不做原理展开专门记录我见过的真实翻车现场每条按现象、原因、解决来写都是能让运维少熬一晚上夜的经验。4.1 磁盘容量看错单位导致误判现象平台告警磁盘空间不足但df -h一看还有好几个GB可用于是认为告警误报隔了几小时服务真的写不进日志了。原因只看df -h忽略了inode。日志目录里大量小文件先把inode耗尽磁盘容量明明还有余量但新文件无法创建。云平台的系统日志、容器日志都容易产生海量小文件。解决巡检时把df -h和df -i放在一起看这两个命令的输出要成对检查。我当时补上inode检查后立刻发现/var/log下inode使用率已经98%清理了一批历史日志文件inode掉下来告警自动消除。从那以后巡检脚本里这两条命令永远写在一起。4.2 直接在数据库里改配置造成不可逆故障现象管理面上改参数不生效有工程师直接连数据库update了一张配置表改完服务重启直接失败整个组件都拉不起来。原因绕过官方工具直接操作底层库表等于跳过了参数的合法性校验。这些字段可能是密文存储可能带版本号删改之后无法通过工具回退连官方支持都不认这种操作。解决数据库可以连但只做只读查询。gsql或mysql客户端用来查状态、确认数据不要用来改。任何配置变更必须走平台提供的命令、API或变更工单流程改动前记录原值改动后做完整性校验。我带团队的时候明确要求数据库写操作一律要有审批记录这个习惯救过我好几次。4.3 集群时间不同步引发token校验失败现象API调用报401日志里提示token校验失败查密码正确、权限正常问题定位卡了很久。原因管理节点和业务节点之间的时间漂移超过允许范围token签发时间与校验时间对不上服务间互信直接被判定失败。很多服务间的握手失败根子都在时间上。解决先用chronyc tracking或ntpq -p检查各节点时间偏移量重点看管理节点和计算节点是否都指向同一个时间源。时间恢复同步后再检查一遍证书有效期这两个问题经常一起出现。现在我做变更前检查时间同步是必查项优先级跟磁盘空间一样高。4.4 重启顺序不对导致集群脑裂现象多台控制节点一起重启后CPS集群状态异常仲裁丢失部分管理功能不可用。原因多节点同时重启或没有等第一台节点完全恢复就对第二台下手导致quorum节点数量不足集群进入异常态。集群不比单机启动顺序本身就是配置的一部分。解决无论升级还是维护控制节点一次只动一台等它的集群状态恢复为up再操作下一台。停止服务的顺序是先停业务面再停管理面启动则完全反过来。这条原则在所有集群类组件上都适用CPS如此数据库集群也是如此。4.5 变更窗口不做业务依赖确认现象打了一个补丁后部分租户网络不通管理面上该网络的资源状态还是正常的。原因变更前没有确认目标节点上承载了哪些实例和网络网元。补丁发布后还需要重启相关服务但当时没有意识到这台节点同时承载了多个租户的路由器网关重启服务导致网络中断。解决变更前一定要导出该节点上的实例分布、路由器、负载均衡等资源的清单确认业务影响边界。变更单里必须写明回退条件和回退动作每执行一步记录前后状态。没有回退方案的变更本质上是一次赌博。5. 把PDF变成你自己的工具箱告警阈值、复盘模板与判定边界PDF再厚也是别人的经验真正让它变成自己的东西需要做两件事一是把经验量化成阈值二是把处置过程固化成模板。5.1 先给“故障”定个可量化的边界没有阈值的经验无法被团队执行。我习惯把PDF里提到的故障特征转成一张基线表放进监控系统。指标建议阈值观察时长处置动作管理节点CPU使用率持续85%以上15分钟检查是否有异常任务堆积内存可用量小于20%持续10分钟排查超卖与内存泄漏分布式存储时延持续25ms以上10分钟确认是否在重建联系存储侧节点间网络丢包率超过0.1%5分钟检查物理链路与光模块证书有效期小于30天每日检查排期轮转阈值定的不是越灵敏越好太灵敏会把运维注意力消耗在误报上。按这个表跑两周根据实际告警量再调一次才算贴合当前环境。5.2 故障复盘单把PDF沉淀成团队流程处理完一次故障我要求按固定结构写复盘发生时间、影响范围、定位路径、根因、处置动作、回退条件、后续改进。每一项都要写具体例如“定位路径”写成“先查管理面健康接口确认管理面正常再查nova-compute状态最后通过iostat确认存储IO卡死”而不是写“排查了资源和性能”。复盘单填得越细下一次遇到同类问题就能直接套用。这份PDF里的内容最终会被这些复盘单替换掉那时候它就真正成了你自己团队的运维手册。从那以后我每次接到故障工单都强制走一遍先分层再取证后操作留回退现在带新人也是按这个顺序读这份指南。希望帮到你。本文还有配套的精品资源点击获取