简介Parastor问题定位手册是一份面向存储运维工程师与技术支持人员的故障排查指南聚焦Parastor存储系统日常运维中常见的IO卡住、断流、数据降级、网络异常等问题帮助读者建立从现象到根因的定位思路。手册按场景篇、修复篇、选盘篇三大模块组织场景篇覆盖IO卡住与断流的基本排查方法及典型问题场景修复篇针对坏对象报单导致数据降级、坏段导致数据失效、坏对象不修复、逻辑盘任务卡主、vset无法展平导致数据降级等给出处理步骤选盘篇则涉及磁盘类型选择、容量规划与磁盘分配。此外还整理了系统日志、磁盘日志、网络日志及磁盘、网络、系统检查命令并附有从V1.0到V1.4的版本修改记录便于对照版本变化。资源包为1个docx文档压缩包约48.02MB已有1575人学习下载适合需要快速查阅排错路径、补充日志与命令细节的存储运维人员参考。1. 消息超时(-110)反复出现先别急着重启这套排查顺序能省半天凌晨两点被叫起来处理集群告警打开终端一看满屏的-110错误码客户端请求全部卡死。这种场景做存储运维的多少都遇到过——消息超时-110是分布式存储里最典型的“玄学故障”看起来是网络问题实际上可能是磁盘、元数据服务、甚至某个节点的负载飙高导致的连锁反应。很多人第一反应是重启服务结果重启完半小时又复现根因根本没找到。这份《Parastor问题定位手册》把这类故障拆成了场景篇、命令篇、日志篇三块从 IO 卡住、断流、修复选盘到网络错误码基本覆盖了日常运维中能碰到的绝大多数异常。如果你正在被-110、-10700002这类报错卡住或者磁盘频繁上下线、数据降级不知道怎么下手下面这套排查路径可以直接抄作业。2. IO 卡住与断流从现象到根因的完整排查链2.1 IO 卡住时先确认是“真卡”还是“慢”IO 卡住和 IO 慢是两回事但现象很像都是客户端请求迟迟不返回。手册里把 IO 卡住问题放在场景篇第一位说明这是最高频的故障类型。基本排查方法的核心思路是先看客户端侧的系统调用是否阻塞再看服务端的数据请求是否堆积最后定位到具体的磁盘或节点。我一般会按这个顺序走# 1. 查看客户端阻塞的系统调用 cat /proc/$(pidof client_process)/stack # 2. 查看阻塞的 dataio 请求 # 通过管理工具查看 dataio 队列深度和等待时间 # 3. 查看文件 layout 信息确认数据分布 # 使用手册中提供的 layout 查询命令第一步看系统调用栈能快速判断是卡在哪个环节——是网络收发、锁等待还是磁盘 IO。第二步看 dataio 请求队列如果队列深度持续很高但处理速率很低说明后端存储节点有问题。第三步查 layout 是为了确认数据落在哪些节点上缩小排查范围。这里有个容易翻车的地方很多人看到 IO 卡住就直接去查磁盘但实际上如果是元数据服务oPara阻塞数据面根本不会收到请求。手册里专门有一节“查看阻塞的 oPara 请求”就是针对这种情况。判断方法很简单——如果 dataio 队列是空的但客户端还在等那问题大概率在元数据侧。2.2 断流问题的三种典型场景断流比 IO 卡住更隐蔽因为连接可能已经断了但客户端还在傻等。手册里断流问题单独成章基本排查方法包括检查网络连接状态、磁盘状态和系统日志。常见问题场景我归纳了三类第一类是网络抖动导致的假断流。TCP 连接因为超时被内核回收但应用层还没感知到。这种情况在日志里会看到大量的-10700002无连接错误。排查方法是查看网络线程是否阻塞以及断链接记录。第二类是磁盘故障导致的真断流。某块盘响应超时DS数据服务进程被拖死上层感知为断流。手册里“磁盘常见问题”那一章专门讲了 DS 启动慢和磁盘报孤立的排查方法。第三类是单点故障引发的连锁断流。某个节点假死但心跳还没超时导致部分请求被路由到该节点后无响应。手册里“单点故障”章节提供了查看假死节点的命令。# 查看单点异常节点 # 使用管理工具查询节点心跳状态 # 查看网络线程阻塞情况 # 通过系统工具分析线程栈 # 查看断链接记录 # 日志中搜索断链接相关关键字这三类场景的区分关键在于网络抖动通常是偶发的、自恢复的磁盘故障会伴随磁盘状态异常单点故障则表现为特定节点上的请求全部超时。定位到具体类别后解决路径就清晰了。2.3 修复和选盘坏对象、坏段、vset 展平数据修复是存储系统绕不开的话题。手册里“修复、选盘问题”章节列了五个典型场景坏对象报单导致数据降级、坏段导致数据失效、坏对象不修复、逻辑盘任务卡主、vset 无法展平导致数据降级。坏对象报单导致数据降级是最常见的。现象是系统告警显示数据降级但磁盘状态正常。根因是某个对象的多副本中有一个副本所在磁盘响应超时被判定为坏对象触发降级。排查方法是查看系统内坏对象列表确认坏对象分布。# 查看系统内坏对象 # 使用修复模块提供的查询命令 # 查看系统内坏段 # 检查坏段状态和分布 # 查看超冗余的坏 vset # 确认 vset 冗余度是否异常坏段导致数据失效比坏对象更严重因为段是数据恢复的最小单位。如果坏段数量超过冗余度数据就真的丢了。手册里强调要定期检查坏段列表发现坏段及时修复。vset 无法展平是个容易被忽视的问题。vset 是虚拟存储单元展平操作是把冗余数据重新分布。如果展平任务卡住会导致数据长期处于降级状态。排查方法是查看需要展平的 vset 列表和正在进行的展平任务。逻辑盘任务卡主则通常和底层磁盘性能有关。如果某块盘 IO 延迟极高逻辑盘任务会一直等待导致整个修复流程停滞。这时候需要结合慢盘故障的排查方法先解决磁盘性能问题。3. 网络错误码大全-10700002、-98、10700016 逐个拆解3.1 消息超时(-110)的完整定位路径-110是 ETIMEDOUT表示操作超时。在 Parastor 里这个错误码可能出现在客户端、元数据服务、数据服务任何一个环节。手册里“网络问题”章节把-110单独列出来说明它的排查有固定套路。第一步确认超时发生在哪个阶段。查看发送端网络消息错误日志如果发送端有记录说明请求发出去了但没收到应答如果发送端没记录说明请求根本没发出去。第二步查看应答端网络消息超时日志。如果应答端有超时记录说明请求到了但处理超时如果没有说明请求在传输过程中丢了。第三步查看网络配置信息确认 MTU、缓冲区大小等参数是否合理。不合理的网络配置会导致大包分片或缓冲区溢出进而引发超时。# 查看发送端网络消息错误 # 日志中搜索 send error 相关关键字 # 查看应答端网络消息超时 # 日志中搜索 response timeout 相关关键字 # 查看网络配置信息 # 检查 MTU、缓冲区等参数我遇到过一种情况-110只在特定客户端出现其他客户端正常。最后查出来是那台客户端的网卡驱动有 bug导致大包发送异常。所以排查时不要只盯着服务端客户端侧的网络配置也要看。3.2 无连接(-10700002)和 10700001/10700004 的区别-10700002表示无连接通常是 TCP 连接已经断开但应用层还在尝试发送。这个错误码和-110的区别在于-110是连接还在但超时-10700002是连接已经没了。手册里还列了10700001、10700004、10700007、10700013(-98)、10700016这几个错误码。它们的含义分别是错误码含义典型场景10700001连接被拒绝服务端未启动或端口未监听10700004连接被重置服务端主动断开或中间设备拦截10700007连接已关闭正常关闭后的残留请求10700013(-98)地址已在使用端口冲突10700016网络不可达路由问题或网卡 down-98EADDRINUSE这个错误码比较特殊它通常出现在服务启动阶段表示端口被占用。排查方法是查看端口监听状态确认是否有残留进程。# 查看端口占用情况 netstat -tlnp | grep 端口号 # 查看网络线程阻塞 # 通过系统工具分析线程状态 # 查看 ping 记录 # 确认节点间网络连通性10700016网络不可达则通常是路由问题。如果某个节点突然报这个错误先检查网卡状态和路由表。手册里“ko 加载问题”也放在网络章节说明内核模块加载失败也会导致网络异常。3.3 网络线程阻塞和断链接记录怎么查网络线程阻塞是很多网络问题的根因。线程阻塞后请求堆积在队列里表现为超时或断流。手册里提供了查看网络线程阻塞的方法核心是分析线程栈。# 查看网络线程阻塞 # 通过系统工具 dump 线程栈 # 查看线程阻塞断链接记录 # 日志中搜索线程阻塞相关关键字线程阻塞的常见原因有三个一是锁竞争多个线程抢同一把锁二是 IO 等待线程在等磁盘或网络 IO三是内存分配失败线程卡在内存申请上。断链接记录则能告诉你连接是什么时候断的、为什么断的。如果断链接集中在某个时间段说明那个时间段有异常事件如果断链接分散可能是网络质量本身有问题。手册里还提到“查看 ping 记录”这是最基础的连通性检查。但要注意ping 通不代表服务正常ping 不通也不代表服务一定有问题——有些环境禁 ping。所以 ping 记录只能作为参考不能作为唯一依据。4. 磁盘故障避坑DS 启动慢、报孤立、批量掉盘的常见误判4.1 DS 启动慢先查磁盘加载别急着换盘DS数据服务启动慢是很常见的故障但很多人第一反应是磁盘坏了直接换盘。实际上手册里明确说了DS 启动慢可以考虑跟磁盘加载有关。磁盘加载慢的原因可能是盘本身性能差也可能是 RAID 卡缓存策略问题还可能是文件系统元数据太多。我一般会先看磁盘的 SMART 信息确认盘本身有没有硬件告警。如果没有硬件问题再看加载时的 IO 延迟。如果延迟高但盘没坏可能是 RAID 卡的问题。# 查看磁盘 SMART 信息 smartctl -a /dev/sdX # 查看磁盘 IO 延迟 iostat -x 1 5 # 查看 DS 启动日志 # 日志中搜索磁盘加载相关关键字这里有个避坑点不要只看单块盘的延迟要看整组盘的延迟。如果一组盘里有一块特别慢会拖累整个 RAID 组导致 DS 启动慢。这时候换掉最慢的那块盘就能解决不需要全换。4.2 磁盘报孤立上报流程走一遍再下结论磁盘报孤立是指磁盘和 DS 之间的心跳断了DS 认为磁盘不在位。手册里详细写了上报流程ostor - mgc - mgcd - ojmgs。这个流程走完需要时间如果中间某个环节卡住磁盘就会一直处于孤立状态。排查方法是沿着上报流程逐级检查。先看 ostor 有没有上报再看 mgc 有没有收到然后看 mgcd 有没有处理最后看 ojmgs 有没有记录。# 查看 ostor 上报记录 # 日志中搜索磁盘上报相关关键字 # 查看 mgc 接收记录 # 确认消息是否到达 # 查看 mgcd 处理记录 # 确认消息是否被处理 # 查看 ojmgs 记录 # 确认最终状态常见误判是磁盘报孤立后直接重启 DS 进程。但如果上报流程本身卡住了重启 DS 也没用因为消息还是传不上去。正确的做法是先确认流程卡在哪一级解决那一级的问题。4.3 批量掉盘先看是不是共享缓存盘被置坏批量掉盘是最吓人的故障一下子几十块盘离线看起来像硬件大面积故障。但手册里提到一种特殊情况元数据盘频繁上下线可能是共享缓存盘被置坏导致的。共享缓存盘是多个节点共用的缓存设备如果它被置坏所有依赖它的节点都会报磁盘异常。排查方法是查看共享缓存盘的状态确认是否被置坏。# 查看共享缓存盘状态 # 使用管理工具查询缓存盘信息 # 查看磁盘卸载卡主情况 # 确认是否有卸载操作卡住 # 查看磁盘报坏原因 # 日志中搜索磁盘置坏相关关键字还有一种批量掉盘是磁盘卸载卡主导致的。卸载操作卡住后磁盘状态一直不变看起来像掉盘。这时候需要查看卸载任务的执行情况确认是否卡在某个环节。4.4 磁盘报坏后回刷慢别让 oStor 服务异常背锅磁盘报坏或离线后系统会触发坏对象回刷把坏盘上的数据恢复到其他盘。但如果回刷很慢会导致 oStor 服务异常告警。很多人看到 oStor 异常就以为是 oStor 本身有问题实际上是回刷任务太重导致的。排查方法是查看回刷任务的进度和速率。如果回刷速率很低说明后端存储压力大需要先解决存储性能问题。# 查看坏对象回刷进度 # 使用修复模块查询回刷任务 # 查看 oStor 服务状态 # 确认是否真的异常 # 查看磁盘 IO 负载 iostat -x 1 5这里有个经验回刷慢不一定是坏事如果回刷太快反而会影响正常业务 IO。所以看到回刷慢先确认业务是否受影响如果业务正常可以适当限速回刷任务。4.5 避坑清单这五个坑我踩过三次以上坑一IO 卡住就重启服务。现象是重启后短暂恢复半小时后又卡。原因是根因没找到重启只是暂时清空了队列。解决方法是按排查链走一遍确认是网络、磁盘还是元数据问题。坑二磁盘报孤立就换盘。现象是换盘后新盘也报孤立。原因是上报流程卡住换盘没用。解决方法是先查上报流程确认消息能正常传递。坑三看到 -110 就调大超时时间。现象是超时时间调大后故障频率降低但没消失。原因是超时只是表象根因可能是磁盘慢或网络丢包。解决方法是查发送端和应答端日志定位超时发生在哪个环节。坑四vset 展平卡住就手动触发。现象是手动触发后展平任务更多了系统更卡。原因是展平任务需要资源手动触发会加剧资源竞争。解决方法是先查展平任务卡住的原因解决后再触发。坑五批量掉盘就全量重启。现象是重启后部分盘恢复部分盘还是离线。原因是共享缓存盘被置坏重启解决不了。解决方法是先查共享缓存盘状态确认是否需要更换。5. 快速定位技巧从报错到根因的十分钟排查法5.1 先看日志再敲命令顺序反了会多花三倍时间我见过很多新手一上来就敲命令敲了十几条还没定位到问题。正确的顺序是先看日志确认报错的关键字和时间点再根据关键字去查对应的命令。手册里“日志篇”按客户端、元数据、数据、修复、网络分了五类每类都有具体的日志查看方法。比如看到-110先去网络日志里搜发送端错误和应答端超时确认超时发生在哪个环节。如果发送端有记录、应答端没记录说明请求在传输中丢了如果两端都有记录说明处理超时。这个判断只需要看两条日志比敲十条命令都快。# 查看执行时间长的系统调用 # 日志中搜索 long syscall 相关关键字 # 查看执行时间长的 dataio 请求 # 日志中搜索 slow dataio 相关关键字 # 查看元数据请求异常时的 mos 信息 # 日志中搜索 mos error 相关关键字5.2 用错误码反查章节手册的目录就是排查地图这份手册的目录结构本身就是排查地图。场景篇按故障类型分命令篇按模块分日志篇按数据流分。遇到报错时先用错误码在目录里找对应章节再按章节里的步骤走。比如-10700002在“网络问题”章节的 4.2 节直接翻过去看排查方法。10700013(-98)在 4.6 节10700016在 4.7 节。这种按错误码索引的方式比从头读一遍快得多。报错关键字对应章节核心排查动作-1104.1 消息超时查发送端和应答端日志-107000024.2 无连接查网络线程阻塞和断链接记录107000014.3查服务端端口监听107000044.4查连接重置原因107000074.5查连接关闭记录10700013(-98)4.6查端口占用107000164.7查路由和网卡状态DS 启动慢7.1查磁盘加载和 SMART磁盘报孤立7.2查上报流程 ostor-mgc-mgcd-ojmgs批量掉盘7.3查共享缓存盘状态磁盘卸载卡主7.4查卸载任务执行情况磁盘报坏7.5查置坏原因和回刷进度5.3 三个必查项时间、节点、频率不管什么故障先确认三个信息发生时间、涉及节点、发生频率。时间能帮你关联其他事件比如是不是在业务高峰期、是不是在某个运维操作之后。节点能帮你判断是单点问题还是全局问题。频率能帮你判断是偶发还是必现。我一般会在排查前先问三个问题什么时候开始的哪些节点受影响每次都一样吗这三个问题的答案能排除掉大部分可能性。比如如果只有某个节点报错那问题大概率在该节点上如果所有节点都报错那问题可能在共享组件或网络上。5.4 从那以后我每次排查都强制走一遍这个流程踩了足够多的坑之后我养成了一个习惯不管故障看起来多简单都强制走一遍“日志 - 错误码 - 章节 - 命令”的流程。看起来多花了几分钟但实际上避免了反复重启、盲目换盘这些更耗时的操作。这份手册最值钱的地方不是某个具体命令而是它把故障场景、排查方法、日志位置、命令用法串成了一条线。遇到问题不用从头想按图索骥就行。如果你也在维护类似的存储集群建议把这份手册放在手边遇到报错先翻目录比搜索引擎靠谱得多。希望帮到你。本文还有配套的精品资源点击获取