如何使用ceph詳解.docVIP

Why Ceph and how to use Ceph? 在 2013 年 07 月 15 日 上公布 作者为 麦子迈 文章分类 Ceph Contents [hide] 为什么需要关注Ceph Ceph的架构 为什么底层是对象存储模型? RADOS的组件有哪些？ RADOS分发策略–CRUSH算法 Ceph的使用场景 Librados RadosGW RBD CephFS Ceph的其他 参考资料 为什么需要关注Ceph 在目前开源世界里多样的存储项目中，不同的项目都有侧重点，而它们最终都是要为企业的IT基础设施服务。那么企业IT基础设施经理们到底需要怎么样的存储，它们的需求得到满足了吗？作者尝试根据对企业级存储产品的调研归纳出如下图。 图一 从上图我们可以了解到存储接口需求、扩展、运维和成本构成了企业级存储产品的四大中心。几乎所有的存储产品包括硬件(存储一体机，SAN)和软件都致力于在这个方面强调自己的优势，它们或者考虑成本，或者强调扩展性。那么我们来看Ceph它是如何定位自己的。 图二 Ceph通过其三大存储接口满足了企业的多样需求，通过其建立之初就”大肆宣扬”的扩展性，通过其分布式架构和致力于PB级规模存储目标的容错性建立了自己的需求矩阵。 图四 上图也是Ceph可以带来的企业IT架构方案的变革，在了解到Ceph提供的特性后，如何达到并实现是每个不熟悉Ceph的人迫切需要了解的。 Ceph的架构 还是下图这张经典的Ceph模块架构图。 图五 底层是Rados，也是Ceph实现分布式存储的根本，所有存储接口都是基于Rados实现的。Rados本身就是一个对象存储接口，它自身维护了一个集群状态和实现了数据分发的要求，我们通常也讲Rados称为Ceph Cluster，因为其上的存储接口如CephFS都是基于其上的接口实现而已。 为什么底层是对象存储模型? 与使用固定块大小存储比较，名字可以在一个扁平的命名空间里，可以采用可变的大小并且简单的API就有丰富的语义。与使用文件存储比较，不需要难以分布的树形层次，上传语义不能跨越对象，不能并行化。 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的接口。同时Rados