简介作为华为FusionCloud数据中心解决方案的配套运维指南《FusionCloud运维故障处理指南》面向云计算平台管理员与故障响应工程师系统讲解物理分散、逻辑统一架构下的故障处理方法包括故障类型划分、日志定位、典型案例与高危操作规避。资源为单个PDF文档压缩包大小3.35MB内容便于离线翻阅。文档重点覆盖FusionSphere OpenStack的日志目录汇总如nova、cinder、neutron各组件操作日志、运行日志及组件启停日志的具体存放路径并针对虚拟机故障、存储故障、网络故障、主机及主机组故障、OpenStack服务故障、ManageOne ServiceCenter节点故障给出排错思路和操作建议。同时指南还总结了常见服务异常处理步骤与高危操作注意事项帮助运维人员在变更和应急时降低操作风险。截至目前已有111人学习适合负责FusionCloud环境日常运维、故障抢修和系统保障的技术人员深入参考。1. FusionCloud 运维故障处理为什么说“按手册干活”也会翻车FusionCloud 运维故障处理指南乍看是一本排障手册真正碰过私有云的人却清楚手册给的是标准答案现场永远考附加题。FusionCloud 管理面组件多、依赖深一个页面打不开的背后可能是中间件、数据库、网络链路任意一环出问题按图索骥反而白耗半天。这份指南真正的价值是把故障处理从碰运气变成有套路先收现场、再定位、再复位、最后闭环。适合刚接手 FusionCloud 的运维新人、维护多云环境的服务器运维工程师以及准备运维面试想攒实战案例的候选人——把下面这套流程吃透手册才能真正变成生产力。2. 排障前的准备把账号、日志、命令工具收拾利索再动手FusionCloud 故障处理最常见的翻车不是定位不出问题而是人已经在现场手里没工具账号密码找不到、日志时间窗拉错、命令环境没加载。所以正式排障前先把三样东西备齐可用的账号、准确的时间窗、趁手的命令工具。这三样每一样都耽误过不少人时间准备好了再动手排障效率能差出一倍。2.1 先把运维账号与权限边界盘清楚少一个密码就断一条路FusionCloud 的账号体系是分层的。拿到一套环境后第一件事就是把账号分类盘出来管理面界面账号用来做日常操作节点层的技术运维账号用来 SSH 登录服务器底层组件账号只有在极端场景才动用。常见做法是管理面用 fsp 这类账号登录运维界面节点排查时切到 sopuser 或 ossuser 这类角色数据库、中间件账号原则上不直接碰没有授权就动底层组件出了事很难说清楚操作痕迹。每次故障处理前我习惯先确认三件事管理面还能不能登录、节点 SSH 通不通、底层账号是否可用。如果管理面已经挂了界面账号等于没有只能走节点 SSH如果节点 SSH 也不通问题已经从应用层下沉到网络或物理层排查路径完全不同。平时把这些账号的用途和风险边界记清楚能走管理面的绝不动节点能走节点的绝不碰数据库越级操作是事故的第二现场。管理面登录不了时先用一条命令探测节点还活着没有再决定下一步往哪查# 探活管理节点网络与 SSH 服务超时设短一点避免命令卡住 ping -c 4 管理面浮动IP ssh -o ConnectTimeout5 管理面浮动IP # 确认能登录后逐台检查管理节点关键进程存活状态 ps -ef | grep -E tomcat|nginx|java|postgres-o ConnectTimeout5是 SSH 的连接超时参数环境越大越需要这个参数防止终端一直挂着。进程检查里的四个关键字对应管理面最常见的四类服务Web 容器、反向代理、Java 应用、数据库。哪一类缺了后面的排查重点就往哪边偏。2.2 现场信息收集的标准动作日志时间窗比命令本身更关键排障的第一步永远是“冻结现场”而不是马上重启。故障发生时的告警 ID、时间段、有没有变更窗口、报错截图这四样是后面所有分析的锚点。常见做法是用平台自带的日志收集工具或者登录对应节点手工抓取但无论用哪种都要先把故障时间窗记准确。很多运维故障案例复盘到最后发现日志里根本没有故障发生那一刻的记录原因就是收集窗口不对。Linux 常用命令在这一步是最趁手的工具用df -h看磁盘是不是写满了、用free -m看内存余量、用top看进程负载再用grep从日志里按时间段过滤。这些命令看起来基础但正是它们能在五分钟内排除掉一半以上的“假故障”。收集到什么程度算够至少包含故障前后半小时的系统日志、应用日志以及关键进程的存活记录。宁可多拉不要少拉后面要补一份日志来回审批走流程才是真的浪费时间。这里我放一个信息收集清单动手前对着打勾清单项要收的内容收不到时的后果告警信息告警 ID、级别、发生与恢复时间无法定位触发源时间窗口故障前后 30 分钟的日志切片日志被覆盖后找回成本极高变更记录近期升级、扩容、配置调整变更引入的故障无法识别进程快照关键进程状态与资源占用分不清是活着假死还是真死了2.3 把故障处理指南当“字典”用先分类、再索引、后复盘FusionCloud 运维故障处理指南这种文档通读一遍记不住是正常的我也不建议从头到尾读。正确用法是先看目录结构把故障分类记住管理面类、计算类、存储类、网络类、数据库类然后按告警现象去索引对应章节。到了现场你需要的不是整本书而是那两三页与当前现象强相关的步骤。其他内容留到故障结束再补现场只看关键页。另一个实用习惯是给指南做“二次加工”。每次处理完一个故障把现象、根因、命令、避坑点压缩成几行笔记贴到对应章节旁边可以是给 PDF 做批注也可以单独维护一个 Markdown 文件。因为你会很快发现标准指南只能覆盖七成常见场景剩下三成是环境特有的本地知识比如某台主机历史上有过时钟跳变、某个存储池余量长期偏低。这些信息不在 PDF 里只在现场。花时间把它们沉淀下来指南才真正属于你的团队。3. 四类典型故障的排查思路管理面、计算、存储、网络FusionCloud 的排障基本可以按资源类型切四条线管理面、计算、存储、网络。大部分告警都能归到其中一类先分类再动手能少走很多弯路。下面按我自己的排查习惯展开每一步都是先排除低成本原因再往深处走。3.1 管理面故障入口断了先查进程与磁盘再碰数据库管理面故障的表现很直接Portal 打不开、登录一直转圈、接口超时。但“打不开”的根因可能是 Web 服务挂了、中间件响应慢、数据库连接池耗尽、磁盘写满原因跨度很大。我的排查顺序固定成一条线先看节点能不能 SSH再看磁盘与内存然后看进程最后才看数据库日志。这条顺序的理由很简单磁盘满是最常见的静默杀手df -h一条命令十秒钟就能排除进程是否存在决定后面日志往哪翻数据库永远放最后因为它依赖前两层一上来就查数据库很容易被“数据库连接失败”的表象带进坑里。# 第一步快速排除资源类问题磁盘满和内存耗尽是最常见假故障 df -h free -m # 第二步看管理节点关键服务监听状态判断进程是真活着还是端口失效 ss -lntp | grep -E 8080|8443|5432 # 第三步重点看最近 30 分钟的错误日志先过滤 ERROR 和 Exception grep -E ERROR|Exception /var/log/应用日志目录 --exclude*.gz这里 8080、8443 是常见的管理面服务端口5432 是常见数据库端口具体以你环境里节点实际监听为准别拿着端口硬套。日志目录路径不同版本差异较大先ls /var/log看结构再指定目录。如果错误日志集中在数据库侧再去翻数据库日志而不是一上来就动数据。3.2 计算资源故障虚拟机起不来先看约束再看迁移计算资源是 FusionCloud 排障里最考验全局观的部分。虚拟机创建失败的报错通常是资源不足但这个“不足”可以拆成三种CPU 或内存真的不够、存储卷没有空间、主机约束不满足比如锁页配置冲突或 CPU 亲和性冲突。我一般按这条线往下排除先看集群资源剩余再看存储卷可用空间最后看目标主机有没有特殊约束。三层都过了还失败才考虑查调度日志多数是调度器对某条约束判断过严。另一种高频场景是虚拟机迁移失败。迁移任务卡住不报错或报主机不可达优先对比源主机和目标主机的存储链路与网络归属。两边挂的存储池不一致迁移一定失败目标主机上的网络策略与源主机不一致迁移也会被静默中断。这类问题在界面里往往只有一个笼统错误真正原因要到两台主机的日志里按时间戳比对才能找到。迁移失败很多时候不是“资源不够”而是“两边环境不对称”别盯着资源数字加班。3.3 存储与网络故障慢、断、闪断按链路逐段打点存储故障在故障处理指南里往往占最大篇幅因为它最容易产生玄学问题明明所有组件都正常业务就是慢。排查思路是逐段打点先看物理磁盘状态与 RAID 卡状态再看存储池容量与数据分布策略最后看主机到存储的心跳链路。分布式存储里有一个高频坑是“假离线”物理盘明明健康却被标记故障多数是网络抖动导致心跳超时这种场景千万不要急着换盘先看链路再动硬件。网络故障以闪断和延迟为主。VLAN 配错、安全组放通策略不对、负载均衡后端健康检查失败都会表现为业务间歇性中断。排查时从叶子节点往上游逐层看虚拟机网卡、虚拟交换机、物理交换机每层的丢包率和错误计数是关键依据。物理交换机端口的 CRC 错误或超时错误能帮你快速定位是不是物理链路质量问题。# 登录物理交换机或用 SSH 跳板查看端口错误计数 show interface counters | grep -E Ethernet|CRC|Error # 排查虚拟机网络闪断时先看虚拟交换机端口统计 ss -s这些命令的用途是先把“物理问题”和“虚拟问题”切开。端口错误计数在涨说明链路物理层有问题业务侧怎么调都白搭计数不涨问题大概率在虚拟交换机或安全策略上这才值得继续往上层查。4. 故障恢复操作复位顺序、依赖确认与关键参数设置定位问题只是前半程真正让人手心出汗的是故障恢复。FusionCloud 这类平台恢复动作一旦做错轻则二次报障重则把一次小故障演变成事故。这一章把恢复操作里的关键点讲透尤其是顺序、边界和参数全是血泪经验换来的。4.1 重启不是点按钮先看依赖关系再定恢复顺序私有云管理面是一个典型的分层依赖结构数据库在最底层中间件基于数据库运行上层应用依赖中间件。恢复时要按“数据库、中间件、应用服务”的顺序逐层拉起反过来操作会让上层应用反复报连接失败。每拉起一层要等这一层状态稳定了再动下一层不能一口气把所有服务全部启动这是恢复操作里最重要的一条原则。很多新手翻车就翻在这里页面打不开直接重启全部服务结果数据库还在初始化、中间件已经开始注册整个过程直接崩掉。恢复操作的黄金法则是每步确认、逐层推进宁可慢十分钟也不要冒二次故障的险。什么时候算“状态稳定”进程起来了不算至少要看到日志输出趋于平缓、端口正常监听、健康检查通过才算稳。提示恢复操作前如果管理面界面还残存可用的入口先把当前告警确认或屏蔽掉再动手。恢复过程中的告警风暴会掩盖真实问题事后复盘时光清理误报就要消耗半天。4.2 平台自带恢复能力与手工介入的边界FusionCloud 管理面提供健康检查和告警恢复能力但“平台自带”不等于“无脑执行”。我的经验是单组件异常优先用平台能力恢复涉及数据库或跨节点问题时手工介入前先做备份再确认操作影响面。恢复脚本能解决大部分服务异常但对底层磁盘损坏、网络分区这类结构性故障无能为力。能不能识别“该手工介入了”是运维成熟度的分水岭。有一个实用的判断标准同一节点的同一组件反复异常三次以内按平台恢复流程处理超过三次还复现说明存在结构性故障比如磁盘故障、内存条问题或网络链路不稳。这时候别再用重启硬扛硬扛出来的服务是“薛定谔的服务”——监控看着是活的一访问就出事。这种情况的正确动作是介入排查硬件或链路同时准备好节点迁移和业务切换方案。4.3 填好关键超时参数避免恢复过程二次超时恢复过程中的超时参数是容易被忽略的细节。平台在批量恢复、数据库切换、存储重连等场景都有自己的超时阈值而恢复操作本身就是高负载场景默认阈值按日常负载标定的在恢复期就可能偏紧。常见做法是先确认管理面的健康检查周期与超时阈值是否匹配当前环境规模再动手。比如节点数量多的环境健康检查周期太短恢复时反而会放大告警。我一般会把大批量操作的管理面并发数压到默认值的 50% 左右宁可慢不能让管理节点资源打满。数据库连接超时按最慢业务放宽一点避免恢复过程中业务侧先把超时报了造成“恢复失败”的误判。下面是几个我常用的调整项供你根据自己的环境微调参数/调整项常见做法说明健康检查周期与告警轮询错开避免恢复过程触发误告警批量并发数压到默认值的 50%降低管理节点瞬时压力数据库连接超时按最慢业务放宽 1.5 倍恢复期负载高窄超时易误判日志保留周期不少于 7 天保证故障复盘有据可查5. 避坑记录FusionCloud 故障处理里最容易翻车的 5 个场景指南覆盖了大部分流程但现场的环境差异会把标准动作变成翻车现场。下面这 5 个场景是我在服务器运维和多云环境里反复看到的按现象、原因、解决三段写方便对号入座。5.1 页面打不开就重启全部服务结果黑匣子更黑了现象管理面 Portal 无响应值班同事一口气把全部服务重启重启后页面白屏报错内容还换了。 原因服务启动顺序错乱导致依赖关系断裂。数据库还没就绪时中间件已经开始注册应用层拿到的连接池全是坏连接故障从单点变成多点。 解决遵循数据库、中间件、应用的顺序逐层恢复每层确认稳定再继续。白屏之后先看数据库进程状态再清掉中间件残留进程最后重新拉起应用层。别在没确认底层时就反复重启上层。5.2 迁移卡在 99% 不报错哑巴故障先比两端配置现象虚拟机迁移任务停在 99%界面没有红色告警任务也不失败就一直挂着。 原因源主机与目标主机的存储链路不一致或者网络策略不通迁移进程在等待资源超时界面不主动报错属于典型的哑巴故障。 解决先对比两端主机挂载的存储池和虚拟交换机端口组再检查目标主机资源余量最后看两端主机日志里同一时间戳的迁移记录。绝大多数迁移卡住问题都出在“两边不对称”而不是迁移功能本身。5.3 拉日志没拉准时间窗交给厂商的日志等于白交现象故障升级给厂商支持对方要求提供日志结果拉出来的日志里根本没有报错记录。 原因日志收集工具默认按当前时间往前回溯一段故障发生在两小时前窗口没覆盖到真正有用的日志没被收进去。 解决启动日志收集前先把故障时间窗换算成具体时间段填进收集参数不确定就按故障前后各一小时拉取。这个细节在运维故障案例复盘里反复出现几乎成了低级但高频的消耗点每次都要有人提醒“时间对一下”。5.4 存储盘“假离线”心跳抖动让好盘背了黑锅现象分布式存储告警某块盘故障状态离线但硬件厂商检测显示盘片健康没有任何坏道。 原因存储网络发生瞬时拥塞心跳超时导致该盘被误判离线。部分场景下平台会自动触发数据重建重建过程反而拖垮存储性能。 解决先查存储网络的心跳链路和交换机端口错误计数确认链路无误再走换盘流程。换盘前多看一层能帮你避开一次本可避免的长时间数据重建。看着像硬件的故障最后查到网络身上的情况很常见。5.5 命令执行找不到路径版本差异是第一嫌疑人现象照着指南里的命令敲进去提示 command not found或者目录不存在整个人愣在终端前面。 原因不同小版本的 FusionCloud 对工具目录、脚本路径做过调整指南里写的路径和当前环境不一致版本差异是第一嫌疑人。 解决先确认当前环境的具体版本号再用find或locate搜索脚本实际路径确认后再执行。任何来自指南的命令都不要直接复制进生产环境先看路径、再看参数、最后敲回车。6. 验证与闭环把一次故障处理攒成团队复用资产故障恢复完不算完验证和闭环才是这次操作值回票价的部分。我的习惯是验证三件事业务恢复关键服务从外部能正常访问而不是“进程活着但接口僵死”数据一致涉及数据库切换或存储重建时对比两端数据和校验值确认没有静默丢数据冗余在线主备、双活、多副本等冗余状态回到设计值否则下一次故障就是真事故。这三点都过了才算处理完。验证项方法满足标准业务访问外部探测或拨测脚本成功率回到故障前基线数据一致校验和对比、表记录计数差值归零冗余恢复平台健康检查或冗余状态视图无降级告警副本数达标之后把处理过程回填到指南里现象、根因、命令、避坑点按前面说的字典批注方式沉淀。这份活版指南比原始 PDF 更值钱因为它长在你自己的环境里。运维自动化工具和智能运维帮我们省了不少人肉盯屏的功夫但故障处理最后的判断仍然依赖经验库的积累指南是起点不是终点。我自己吃过一次亏一次存储节点故障换盘后没确认重建完成就下班第二天数据重建风暴把业务打垮。从那以后闭环验证永远排在“看起来好了”的前面。希望这篇笔记能帮你在 FusionCloud 运维故障处理这条路上少翻几次车多沉淀几份真正能复用的现场经验。本文还有配套的精品资源点击获取