前言

我们知道 ，FileStore是目前Ceph版本的默认存储方式 (后续社区采用BlueStore ) 。    RDB是我们虚拟机使用Ceph的常用方式 ，Ceph是一个基于对象存储的分布式文件系统 ，在 Ceph中 ，所有的文件都是对象 ，本文探讨在Ceph中的RDB在Ceph的实现原理和映射方式。 了解了RBD的映射原理以后 ，对我们运维管理 ，数据恢复会有很大的帮助。

操作过程

创建pool

创建好test pool后 ，通过rados查看pool中的对象 ，因为没有存储任何东西 ，所以没发现对象。

创建image

在test pool中，创建了rbd的test image，此时通过rados查看，发现了两个对象：rbd_directory和test.rbd

Object2PG

在Ceph中，每一个对象（Object）都会首先映射到一个pg上，然后pg再映射到一组osd上。

通过ceph osd map [pool] [object_name] 直接可以查看到object到pg的映射关系，本例中rbd_directory 映射到了pg=5.1c.前面的5是pool_id，30a98c1c这串数值其实就是通过Ceph的Hash函数将rbd_directory映射的结果，我们把他成为object_id，因为本例的pool中pg_num=64,映射过来的pg_id=0x30a98c1c%64=0x1c, 从上面可以看出，Ceph的object_id到pg的映射就是简单的取模处理。一旦Ceph的pg数据发生变化，pg的映射也会发生变化，从原理上来看，当一个Ceph的生产集群，最后不要调整pg数。

PG2OSD

每个pg都会通过Crush算法，映射到一组osd上，Crush算法是Ceph数据高可用性的保障。Crush算法其实一个能够根据服务器部署情况而产生不同映射结果的一致性哈希算法。

本例中有4个osd, 通过ceph pg map 可以找到对应的object映射到了那个osd,本例中映射到了2和3，2是主osd(本例配置的副本数为2)。

文件落地

从上面寻找的过程中，通过osd的目录，进入到pg所在的目录，因为一个osd会承载多个pg，同时一个pg会映射到至少一个以上的osd上。本例中顺藤摸瓜，进入osd/ceph-2/current,由于pg是5.1c,进入5.1c的目录，找到了文件rbd\udirectory__head_30A98C1C__5，命名规则也很简单{object_name}head{object_id}_{pool_Id}，通过hexdump发现，里面存储了test，猜想他应该是保存了image的名字。

再查看另外一个文件test.rbd，如下，通过hexdump查看，发现里面存储了一些RBD的描述信息

通过rbd info 查看rbd的信息，发现果然有几分似曾相识，比如rb.0.16d0.6b8b4567，从这里我们可以发现，rbd info 其实就是读取了test.rbd中的数据，也就是说rbd的描述信息存放在test.rbd中。

RBD文件组织

map到dev

格式化文件系统

挂载文件系统

创建文件（128M）

查看文件

在格式化了文件系统，同时创建了128M的文件以后，通过rados查看，出现了很多以rb.0.16d0.6b8b4567的文件，同时出现了连续的文件命令，从rb.0.16d0.6b8b4567.000000000020到rb.0.16d0.6b8b4567.000000000041，共32个，加上ceph的对象大小为4M，共128M，和测试文件大小吻合。其他的一些文件这是ext4文件系统的一些描述信息。因此，我们可以推测，rbd文件组织是一个{image_name}.rdb + 若干rbd_prefix.{num}，每个块大小为4M，整个rbd的文件数=size/4M+1。

总结

Ceph是一个非常优秀的分布式文件系统，对象首先通过object_name计算出object_id，然后取模，映射到pg上，然后pg通过crush算法映射到一组osd上，其中一个为主osd。rbd则是ceph的一种访问方式，在rados的基础上的另外一层封装，实现简单，仅添加了一个描述文件，其他的文件通过顺序方式组织起来，通过librbd提供给其他应用访问。