ceph kernel rbd （一）: 简介

kernel rbd是ceph 的块存储当中的linux-kernel client。在整个ceph当中的位置如图所示:

其中kernel module就是本文提到的kernel rbd 模块。

 

ceph 作为一个统一存储的分布式存储系统，提供了对象，文件和块存储三种存储接口。其中块存储又提供了两种client接口用于块存储的不同场景使用。

（1）librbd：这是ceph 块存储目前使用最多的一个场景，也就是云计算场景对接openstack或者其他平台。这也是ceph出现十几年，但是前几年才大火的一个原因，搭上云计算的顺风车。这个场景不是这个系列的重点，就不做详细分析了。

（2）krbd（kernel rbd）：这是ceph 块设备直接对接到linux 系统的场景。也就是说，在linux kernel当中提供了一个块设备的driver，直接对ceph server端进行数据IO。这个场景主要用于不能直接利用librbd 进行业务改造的场景。比如 container 场景（实际上对于container，最适合的应该是文件存储，但是ceph的文件存储cephfs，并不是很稳定，所以暂时使用krbd来使用）。另外相比于librbd，krbd 还有最大的优势在于，其可以充分利用linux block layer的众多特性，比如pagecache，bcache，md，multiqueue等等。

 

在了解了krbd的存在价值和使用场景之后，我们简单的介绍一下krbd的现状。

由于众多原因，现在的krbd 对比librbd来看，开发进度稍微落后一些，能比较明显看到的原因有这个几

（1）librbd 在云计算大火的今天，实在是大明星，所以参与者众多。

（2）krbd 由于代码在linux kernel，bug影响范围都会大很多，大部分厂商望而却步。

（3）krbd 的开发难度和维护难度相比于librbd会更大。

其中，最重要的一点就是第一点，现在的krbd 还没有找到他最适合的应用场景。不过这也与其成熟度不够有密不可分的关系，正如cgroup，当年都要被踢出kernel的一个项目，TJ 接手之后，稳定性和成熟度提升上来，现在红得发紫。所以我认为krbd 本身有着价值，但需要找到最合适的场景发挥出来。

 

上面只是说了krbd 现在开发相对librbd 比较落后，那我们现在更进一步看看落后在哪些方面：

（1）krbd driver 对于rbd 的feature 支持：还没有支持所有的rbd feature（5.3-rc1已经merge了fast-diff和object-map，所以现在还剩下journaling）

（2）kernel libceph 使用场景不如librbd 多，所以有时候会出现和osd 配合不当的场景，比如osd 抛弃了一个op，认为client需要resend，但是libceph不能判断出这种场景需要resend。出现client 端IO hang。

其中1 是关于功能完备性，其2 是关于稳定性。现在krbd的目标就是向着这两个方向去努力，至于使用场景，等待更多的聪明人去发掘吧。