ceph心跳丢失问题分析.pptxVIP

ceph心跳丢失问题分析 谷忠言 Agenda 现象/问题 Ceph 心跳原理 Filestore 线程模型 ceph集群bjtp-ssd实例分析 总结 现象/问题 Test case: 800 or 1200 vms run fio, 64k 顺序写 现象: Monitor收到报告，有osd failed. osd.707 10.205.194.53:6801/96651 failed (3 reports from 3 peers after 20.000106 = grace 20.000000) 但osd.707 还在up and running 的状态 此时集群有部分object处于degraded状态 保持压力，持续degraded，停止压力，自行恢复 问题: 为什么osd.707还活着，但别的osd报告它failed. 可能的原因 Osd.A ----ping--- osd.B: Osd.A ----reply--- osd.B: A 自己有问题，没有发包 网络连通问题 B 有问题，收到了包，但是由于某种原因没回应 Ceph 心跳原理 心跳发送: 每个OSD有专门的thread发ping包：heartbeat_thread 发包规则： 间隔6秒以内 发送对象是有peer关系的osd 通过front 和back 端口同时发送 心跳接收： 每个OSD有两个messenger接收peer OSD的ping包 通过DispatchQueue 内部线程调用注册的Dispatch 类的处理函数来处理相应的消息 No block in the path, small message Ceph 心跳原理 心跳接收处理逻辑： OSD是否健康，bool HeartbeatMap::is_healthy() 如果不健康，不会回应心跳 如何检查健康 轮询检查所有的关键干活的线程的timeout值，超过阈值，说明关键线程有长时间没有更新timeout，判定不健康。如果超过suicide timeout, OSD daemon core. Heartbeat要检查的关键线程 FileStore::op_tp OSD::osd_tp OSD::osd_op_tp OSD::recovery_tp OSD::command_tp OSD::disk_tp Filestore线程模型 关键线程被block的case 汇总 OSD::osd_op_tp Filestore 限流 Filejournal::writeq Journal FULL aio 限流 FileStore::op_tp op_tp互相的锁竞争 被sync_thread pause 以上线程处理的队列为空，睡眠 Filestore:sync_thread 无法立即puase op_tp Bjtp集群实例分析：case1 Monintor记录osd failed: 2016-05-10 16:13:28.747140 mon.0 [INF] osd.707 10.205.194.53:6803/4291 failed (94 reports from 50 peers after 27.197497 = grace 27.061426) Osd.707 log: Mon记录osd fail的27s前，heartbeat 开始检测到不健康 2016-05-10 16:13:01.106131 7fbb9cff7700 1 heartbeat_map is_healthy OSD::osd_op_tp thread 0x7fbb547ff700 had timed out after 15 原因是osd_op_tp线程有timeout Bjtp集群实例分析：case1 Osd_op_tp线程的工作内容 把op从op_shardedwq取出包装成transaction送到journal writeq Osd_op_tp timeout 原因: Heartbeat检测到osd_op_tp timeout前15s,Osd_op_tp更新timeout:2016-05-10 16:12:45.982813 7fbb547ff700 20 heartbeat_map clear_timeout OSD::osd_op_tp thread 0x7fbb547ff700‘ 然后Osd_op_tp 把transaction 送至 journal writeq时撞到了filestore限流：2016-05-10 16:12:45.983176 7fbb547ff700 7 filestore(/home/ceph/software/ceph/var/lib/ceph/osd/ceph-707)