RADOS的组件有哪些？
OSD: 每一个disk、SSD或者RAID group或者其他一个物理存储设备都成为一个OSD，主要负责存储和查找对象，并且负责向该对象的复制节点分发和恢复。
Monitor: 维护集群的成员和状态，提供强一致性的决策(类似于Zookeeper的作用)
RADOS分发策略–CRUSH算法
图六
从上图的流程中作者尝试解读RADOS是如何将对象分发到不同的OSD上(OSD)，首先需要了解Ceph定义的几个存储区域概念。Pool是一个命名空间，客户端向RADOS上存储对象时需要指定一个Pool，Pool通过配置文件定义并可以指定Pool的存储OSD节点范围和PG数量。PG是Pool内部的概念，是对象和OSD的中间逻辑分层，对象首先会通过简单的Hash算法来得到其存储的PG，这个PG和对象是确定的。然后每一个PG都有一个primary OSD和几个Secondary OSD，对象会被分发都这些OSD上存储，而这个分发策略称为CRUSH—Ceph的数据均匀分布的核心。需要注意的是整个CRUSH以上的流程实现都是在客户端计算，因此客户端本身需要保存一份Cluster Map，而这是从Monitor处获得。从这里我们也可以了解到Monitor主要职责就是负责维护这份Cluster Map并保证强一致性。
CRUSH通过伪随机算法来确保均匀的数据分布，它的输入是PG,Cluster State和Policy，并且保证CRUSH的Object Name一样的情况下，即使后两者参数发生改变也会得到一致的读取(注意是读取)。并且这个CRUSH算法是可配置的，通过PG Number和Weight的指定可以得到不同的分布策略。这个可配置的分布策略让Ceph的能力得到极大加强。
图七
Ceph的使用场景
Librados
图八
首先回顾之前看到的整个架构图，在上述文中我们了解了RADOS的原理和作用，然后我们聚焦在Librados，Librados提供了对RADOS的直接访问。librados提供对C、C++、Java、Python、Ruby和PHP的支持。
图九
librados和之后提到的RADOSGW的不同在于它是直接访问RADOS，没有Http协议的负载。它支持单个单项的原子操作如同时更新数据和属性、CAS操作，同时有对象粒度的快照操作。它的实现是基于RADOS的插件API，因此，其实际上就是在Rados上运行的封装库。
RadosGW
图十
从上图可以看到RadosGW位于Librados之上，它主要提供RESTful接口并且兼容S3、Swfit的接口。同时RadosGW提供了Bucket的命名空间(类似于文件夹)和账户支持，并且具备使用记录用于账单目的。相对的，它增加了Http协议的负载。
RadosGW可以提供将Ceph Cluster作为分布式对象存储的能力，如Amazon的S3范围，Swift等。企业也可以直接使用其作为媒体数据存储，分发等。
RBD
块存储是Ceph的另一大支撑点，它目前可以为虚拟机和主机(Host)提供不同路径的块存储。
图十一
上图为Ceph Cluster为虚拟机提供块设备支持。LibRBD是基于Librados的块设备接口实现，主要将一个块设备映射为不同的对象来实现。通过LibRBD可以创建一个块设备(Container)，然后通过QEMU/KVM Attach到VM上。通过Container和VM的解耦使得块设备可以被绑定到不同的VM上。
图十二
上图为Ceph Cluster为主机提供块设备支持，通过RBD Kernel Module(rbd.ko)为主机提供块设备。这里有一个与上述不同之处在于Librados是内核模块而模块名称为(libceph)。这是因为RBD内核模块需要利用同样位于内核空间的Librados。从这里我们可以了解到，实际上Ceph维护了数量非常多的Library，而实际上质量是层次不齐的，这需要了解Ceph的人去合理使用。正是因为如何多样的Library也使得Ceph的存储接口得到多样化，而不是让不同的存储接口勉强实现。不同的存储接口具有完全不同的路径。