CephFS MDS故障处理：failed/damaged/replay排查指南

说实话CephFS出故障的时候MDS的状态报错是让人最揪心的。你把集群辛辛苦苦跑起来某天早晨收到告警ceph mds stat 里躺着一个 failed客户端那边 ls、rm、mv 全部卡死业务方电话一个接一个。这类问题我在生产环境处理过很多次原因五花八门有内存被客户端缓存打爆的有OSD慢请求拖垮的也有MDS日志损坏直接被标记为damaged的。这篇文章就是把我的处理思路、踩过的坑和可复制的操作步骤整理出来希望对正在值班的你有点帮助。MDS元数据服务器负责CephFS的目录树、文件属性、锁等元数据管理。它的状态异常不像OSD那样“换个盘、重建PG”就能解决很多操作顺序错了反而会把问题扩大。我先从MDS状态机制讲起再讲failed和damaged两类报错的具体处理路径最后补充replay卡住的排查和调优建议。1. 先看明白MDS状态机从状态码就能判断问题严重程度搞清楚状态机至少能让你在告警电话面前不慌。很多人一看到ceph mds stat里的非up:active就紧张实际上有些状态是完全正常的有些则需要看上下文来判断。1.1 MDS的rank到底是什么CephFS不像传统文件系统只有一个元数据节点。在Ceph里每个激活的MDS实例负责一个或多个“段落”MDS使用rank来为这些段落编号。rank 0承载根目录和最基本的元数据其他rank承载子树分片。一个FS可以配置多个rank通过max_mds控制每个rank可以有一个主MDS和若干个用户自定义的standby。打个比方rank很像一条高速公路的车道编号。rank 0是主车道其余rank是扩展出去的匝道。车道出问题所有车都堵在入口所以rank 0的MDS状态异常影响最大。1.2 ceph mds stat输出里的状态分别代表什么我整理了一份常用状态对照表建议收藏状态含义是否需要人工干预up:active正常工作不需要up:standby冷备未接管rank不需要up:standby-replay热备定时重放主MDS日志不需要up:replay降级后正在重放日志恢复状态需观察长时间卡住要处理up:rejoin恢复后进行元数据合并一般自动完成up:resolve处理子目录map和锁状态一般自动完成up:reconnect等待客户端回连一般自动完成down进程停了需处理failed失败rank无法恢复必须处理damaged元数据损坏拒绝挂载必须处理stopped被强制停止需处理真正需要立刻处理的只有 failed、damaged、stopped以及长期卡在 replay/rejoin 的状态。其他都是MDS正常工作流程里的“临时状态”等一会儿就过去了。判断完状态下一步就是动手恢复。下面我按两类最常见的报错场景来拆解。2. MDS进入failed状态先判断根因再决定是踢是救failed 是生产环境里出现频率最高的状态。它通常表示MDS进程本身失去心跳或者mdsmap判定该rank无法继续提供服务。2.1 failed是怎么发生的MDS定期向Monitor上报心跳。当Monitor在一段时间内没收到心跳或者MDS自身遭遇不可恢复故障时Monitor会把该MDS标记为 failed。此时如果配置了standbyMonitor会拉起一个代替它如果没有standbyrank就空在那里客户端访问该rank对应的目录会直接卡住。常见的触发原因有三类资源耗尽内存不足到OOM或CPU被太高的日志级别拖垮。存储层面MDS写入元数据依赖的元数据pool所在的OSD出现慢请求、down、或者网络分区。客户端风暴大量客户端短时间内建立会话MDS的session table膨胀导致心跳超时。2.2 手动触发failover的正确姿势如果是MDS进程还在只是状态异常可以用ceph mds fail来让它优雅降级并切换ceph mds stat # cephfs:1 {0node-a:2500000up:active, 1node-b:2500001up:active} # 强制把rank 0切换出去 ceph mds fail cephfs:0执行之后如果配置了mds_standby_replay true热备节点几乎能秒级接管如果是冷备则需要一定时间重放日志。执行前建议先确认目标rank是确确实实卡死了否则手动fail一个正常的active MDS会造成短暂的服务中断。注意一个细节如果MDS所在进程已经挂了但Monitor还没检测出失败你执行ceph mds fail会强行把该rank的fail状态推给Monitor然后触发failover。这个过程不要连续执行至少间隔几秒钟否则Monitor可能还没来得及处理完新的mdsmap。2.3 failed之后没有standby接管怎么办没有standby的情况下你会看到cephfs:1 {0node-a:2500000up:failed, 1node-b:2500001up:active}rank 0已经failed了但没有MDS接管。这时不能直接重启node-a上的MDS进程因为旧状态还在mdsmap里。需要先清理failed标记再让MDS重新启动# 删除failed的rank标记版本不同命令有差异 ceph mds rmfailed 0在新版本中rmfailed可能已经被废弃需要直接重启对应的MDS服务让它进入up:replaysystemctl restart ceph-mdsnode-a这里最易踩坑的点在于如果你在rmfailed前启动了mds服务旧指代关系会使新进程也被fial掉。稳妥的操作顺序是先rmfailed或者等待Monitor确认清出rank再启动服务。如果你的版本比较新直接用ceph mds fail cephfs:0后重启MDS服务即可。3. MDS处于damaged状态这一步千万不要乱resetfailed处理不了时比如MDS日志损坏、本地可回放的元数据不完整MDS会在启动时自我标记为damaged。这个状态比failed更严重意味着MDS认为自己无法安全回放拒绝继续服务。3.1 damaged是怎么冒出来的damaged分两种来源。第一种是MDS本地数据损坏。MDS进程数据存放在它自己的本地盘上通常是/var/lib/ceph/mds/ceph-xxx目录。这些数据包括intent日志、session信息等。如果这个盘有问题MDS启动时解不开日志就会自报damaged。第二种是元数据pool中的数据不一致。比如通过rados直接修改了元数据对象或者OSD层的对象丢失导致MDS在加载元数据对象时校验失败。这种情况通常伴随OSD报错需要一同排查。3.2 先查OSD和后端pool再碰MDS我自己处理damaged的顺序是“先修底、再修顶”ceph -s ceph osd tree ceph health detail # 查看元数据pool的状态 ceph osd pool ls detail ceph fs status如果ceph -s里明确有active unclean或PG状态异常说明MDS的damaged很可能是后端数据不完整导致的。这时候先恢复OSD和PG后端稳定后再处理MDS否则reset多少次都会被重新标记。3.3 尝试“修复”MDS的damaged标记如果后端正常MDS状态如下cephfs:1 {0node-a:2500000failed:damaged, 1node-b:2500001up:active}这时可以尝试让MDS重新扫描元数据并清除受损标记让它尝试重放ceph mds repaired node-a这个命令的意思是“请求MDS认为该rank已经修复重新尝试启动”。注意它不是万能的。如果MDS进程启动后再次自检失败会立刻重新标记damaged。3.4 实在救不回来只能reset FS遇到元数据损坏面积大、MDS启动后反复damaged或者目录结构根本无法读取就只能做最后手段重置文件系统。# 注意这会清掉整个CephFS的元数据业务数据全会丢 ceph fs reset cephfs --yes-i-really-mean-it执行前必须确认能接受数据丢失最好先备份元数据cephfs-data-extract --pool cephfs_metadata /backup/mds_metadatareset之后CephFS会以空目录形式重新初始化。客户端全部需要重新挂载。这个操作在企业生产环境属于“核弹级”一定要在变更窗口、正式评审后再做。我见过有的团队把ceph fs reset当成普通重启来用结果整条业务线数据全没了这是绝对要避免的。4. MDS卡在up:replay和rejoin阶段的排查实录如果说failed和damaged是“大毛病”那卡在replay状态更像“慢性病”。MDS重启之后需要重放此前记录的journal以恢复内存状态。正常情况下几十秒能完成但某些环境下会卡几十分钟甚至几小时。4.1 现象与首查命令当你看到cephfs:1 {0node-aup:replay, 1node-bup:active}且持续十几分钟不变立刻采集信息ceph mds stat ceph mds tell cephfs:0 dump load ceph mds tell cephfs:0 status journalctl -u ceph-mdsnode-a -n 200 --no-pager重点看日志里有没有这些特征“journal replay is lagging”“replaying journal” 长时间不结束“cache is pinned” 或 “client session has too many caps”大量“trimming inode”消息4.2 replay慢的根因定位replay慢通常有三个根源。一是journal本身巨大。MDS的journal对应元数据pool中的某些对象你可以用cephfs-journal-tool查看cephfs-journal-tool --rank 0 journal inspect cephfs-journal-tool --rank 0 journal dump --output /tmp/journal.json如果journal里的事件数异常多说明MDS上次运行期间缓存没有及时刷strip异常退出时积压了大量条目。二是OSD性能瓶颈。replay是一个写密集过程每一条journal记录都要落盘到元数据pool。此时观察ceph osd perf ceph daemon osd.1 ops如果对应OSD的apply/commit时延飙高问题就不在MDS而是在存储层。优先处理OSD慢请求或进行数据迁移比在MDS端加参数更有效。三是客户端会话和缓存过多。大量客户端在MDS故障前仍然存活MDS在replay完成后还要重连这些会话。此时日志里会有大量“Evicting client”消息。可以主动清理# 查看客户端列表 ceph tell mds.0 client ls # 强制剔除卡死的客户端 ceph tell mds.0 client evict 12345.67894.3 rejoin阶段卡住的特殊处理如果状态卡在up:rejoin说明MDS已经在重建目录树和元数据缓存但某个目录或文件锁状态不收敛。常见原因是被剔除的客户端没有完全释放capability。此时需要对异常的客户端进行evict或者把rejoin失败的rank整个fail掉让standby重新接管ceph mds fail cephfs:0这里有个经验rejoin卡住时不要反复重启同一个MDS。因为每个进程都从同一个损坏的journal状态开始rejoin大概率会再次卡住。正确的顺序是剔除嫌疑客户端 - 手动fail该rank - 等新MDS接管。如果还卡再考虑修复journal。5. 调优是治本防止MDS反复出问题的关键参数报错解决了只是治病调优才是防止复发。MDS在重新稳定运行后我最先调整的一定是下面几个点。5.1 给MDS内存限制一个明确的上限MDS默认缓存上限是4GB很多业务一上来就是大规模目录扫描4GB瞬间被打爆。打爆后MDS会进入只读状态把所有inode刷下去这时用户体验就是“盘符能挂上但ls卡死”。推荐按节点实际内存来配置[mds] mds_cache_memory_limit 8589934592重点是还要给MDS一个mds_cache_reservation建议在10%~20%之间防止内存触顶后过度刷缓存。配置后重启MDS服务生效。5.2 日志级别别盲目开高很多人排障时喜欢把debug_mds调到20用完又不调回来。在MDS这种高频路径上调高debug级别会让性能骤降日志填满磁盘甚至导致心跳超时被误认为failed。排障完一定要恢复到[mds] debug_mds 1如果确实要长期跟踪某些元数据问题建议只开启对应子模块ceph tell mds.0 config set debug_mds 5用ceph tell临时设置排查完立即改回1。5.3 双活MDS的配置建议很多团队把max_mds调得很大觉得MDS越多越好。实际上每个rank都会占用内存和CPU且rank之间要做目录分片均衡配置不合理反而增加rejoin时的复杂度。我的建议是优先把mds_standby_replay打开让一个热备节点随时准备接管而不是盲目增加active rank。增减max_mds时必须关注元数据pool的数据分布ceph fs get cephfs # 查看max_mds和standby配置6. 常见故障速查表一键定位处理方向我在日常值班中常用下面这张速查表基本能覆盖90%的MDS状态报错。故障现象可能原因初步处理MDS: failed心跳超时、资源耗尽、进程崩溃确认资源后ceph mds fail触发切换MDS: damaged本地日志损坏、元数据对象损坏先修OSD/PG再ceph mds repairedMDS: up:replay 长时间不变journal过大、OSD慢、会话过多检查osd perfevict异常客户端MDS: up:rejoin 卡住客户端capability不释放手动fail rank剔除嫌疑客户端MDS: down进程手动停止或重启中断确认配置后重启服务MDS OOM反复重启mds_cache_memory_limit设置不当调高上限并设置cache reservation客户端挂载后ls卡死MDS长时间未恢复按上述状态归类处理这里要特别强调一个“回避操作”不要在MDS状态异常时盲目滚动重启所有MDS也不要同时执行多个ceph mds fail。MDS故障恢复本质是状态机迁移并发干预会把mdsmap搞乱轻则恢复时间加长重则触发分布锁系统异常。再补一条我自己的排障习惯。分析MDS问题前我一定会先做三件事拉ceph -s、拉mds日志、拉osd perf。三个数据一对照90%的异常状态都能定位到具体层面而不是对着MDS一顿乱敲命令。最后提醒一句MDS调优和配置变更最好先在测试环境模拟故障再在生产环境操作。因为每个CephFS的规模、客户端行为、底层硬件都不一样照抄参数不一定适用。