前言
Ceph作为开源存储中的明星产品,得到了广泛应用。当前,Ceph在网易也得到了广泛使用,网易云轻舟容器云平台以及OpenStack云平台底层存储分别使用了CephFS以及RBD,这两个平台服务于众多内部以及外部客户。
Ceph产品从2015年开始在网易云上线,最大集群规模达到了4000+个osd,在使用过程中也遇到了一系列的问题。本文梳理了最近遇到的一个问题的来龙去脉。
问题背景
一个新部署好的ceph集群,在集群没有任何io 流量的情况下,通过iostat查看osd对应的后端磁盘,发现一直有少量的写流量(每秒的时间间隔),如下图所示(sdu是osd对应的一个后端磁盘):
username@hostname:~$ sudo iostat -xm 1 | grep sdu
sdu 0.00 0.00 0.00 4.00 0.00 0.01 8.00 0.00 0.00 0.00 0.00 0.00 0.00
sdu 0.00 0.00 0.00 4.00 0.00 0.01 8.00 0.00 0.00 0.00 0.00 0.00 0.00
sdu 0.00 0.00 0.00 4.00 0.00 0.01 8.00 0.00 0.00 0.00 0.00 0.00 0.00
sdu 0.00 0.00 0.00 4.00 0.00 0.01 8.00 0.00 0.00 0.00 0.00 0.00 0.00
sdu 0.00 0.00 0.00 4.00 0.00 0.01 8.00 0.00 0.00 0.00 0.00 0.00 0.00
初步分析
io溯源
磁盘有io写入,由于该写入必然会经过内核驱动层,所以可以考虑使用perf或者systemtap等内核分析工具对该io进行溯源,分析获取该io整个调用栈。
在这里我使用的是perf,perf号称linux问题分析的瑞士军刀。内核代码中使用了tracepoint,tracepoint是内核源代码中的一些hook,一旦使能,它们便可以在特定的代码被运行到时被触发,perf便是利用了该机制,进而可以跟踪从kernerl到user space层的事件,包括块设备、网络、CPU、文件系统、内存以及系统调用等。通过perf list
命令可以列出perf支持的所有事件。
由于我们是分析io,所以可以看看块设备block层提供的所有 tracepoints。这些 tracepoints可以通过如下命令查看,
username@hostname:~$ sudo perf list block:*
List of pre-defined events (to be used in -e):
block:block_bio_backmerge [Tracepoint event]
block:block_bio_bounce [Tracepoint event]
block:block_bio_complete [Tracepoint event]
block:block_bio_frontmerge [Tracepoint event]
block:block_bio_queue [Tracepoint event]
block:block_bio_remap [Tracepoint event]
block:block_dirty_buffer [Tracepoint event]
block:block_getrq [Tracepoint event]
block:block_plug [Tracepoint event]
block:block_rq_abort [Tracepoint event]
block:block_rq_complete [Tracepoint event]
block:block_rq_insert [Tracepoint event]