不做第二个别人，永远做第一个自己。
分类： 服务器与存储
2014-04-10 11:11:58
在目前开源世界里多样的存储项目中，不同的项目都有侧重点，而它们最终都是要为企业的IT基础设施服务。那么企业IT基础设施经理们到底需要怎么样的存储，它们的需求得到满足了吗？作者尝试根据对企业级存储产品的调研归纳出如下图。
图一
从上图我们可以了解到存储接口需求、扩展、运维和成本构成了企业级存储产品的四大中心。几乎所有的存储产品包括硬件(存储一体机，SAN)和软件都致力于在这个方面强调自己的优势，它们或者考虑成本，或者强调扩展性。那么我们来看Ceph它是如何定位自己的。
图二
Ceph通过其三大存储接口满足了企业的多样需求，通过其建立之初就”大肆宣扬”的扩展性，通过其分布式架构和致力于PB级规模存储目标的容错性建立了自己的需求矩阵。
图四
上图也是Ceph可以带来的企业IT架构方案的变革，在了解到Ceph提供的特性后，如何达到并实现是每个不熟悉Ceph的人迫切需要了解的。
还是下图这张经典的Ceph模块架构图。
图五
底层是Rados，也是Ceph实现分布式存储的根本，所有存储接口都是基于Rados实现的。Rados本身就是一个对象存储接口，它自身维护了一个集群状态和实现了数据分发的要求，我们通常也讲Rados称为Ceph Cluster，因为其上的存储接口如CephFS都是基于其上的接口实现而已。
与使用固定块大小存储比较，名字可以在一个扁平的命名空间里，可以采用可变的大小并且简单的API就有丰富的语义。 与使用文件存储比较，不需要难以分布的树形层次，上传语义不能跨越对象，不能并行化。
OSD: 每一个disk、SSD或者RAID group或者其他一个物理存储设备都成为一个OSD，主要负责存储和查找对象，并且负责向该对象的复制节点分发和恢复。
Monitor: 维护集群的成员和状态，提供强一致性的决策(类似于Zookeeper的作用)
图六
从上图的流程中作者尝试解读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的能力得到极大加强。
图七
图八
首先回顾之前看到的整个架构图，在上述文中我们了解了RADOS的原理和作用，然后我们聚焦在Librados，Librados提供了对RADOS的直接访问。librados提供对C、C++、Java、Python、Ruby和PHP的支持。
图九
librados和之后提到的RADOSGW的不同在于它是直接访问RADOS，没有Http协议的负载。它支持单个单项的原子操作如同时更新数据和属性、CAS操作，同时有对象粒度的快照操作。它的实现是基于RADOS的插件API，因此，其实际上就是在Rados上运行的封装库。
图十
从上图可以看到RadosGW位于Librados之上，它主要提供RESTful接口并且兼容S3、Swfit的接口。同时RadosGW提供了Bucket的命名空间(类似于文件夹)和账户支持，并且具备使用记录用于账单目的。相对的，它增加了Http协议的负载。
RadosGW可以提供将Ceph Cluster作为分布式对象存储的能力，如Amazon的S3范围，Swift等。企业也可以直接使用其作为媒体数据存储，分发等。
块存储是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的存储接口得到多样化，而不是让不同的存储接口勉强实现。不同的存储接口具有完全不同的路径。
以上两种方式都是将一个虚拟的块设备分片存储在RADOS(Ceph Cluster)中，都会利用利用数据条带化提高数据并行传输，都支持块设备的快照，COW(Copy-On-Write)克隆。最重要的是RBD还支持Live migration。目前的OpenStack，CloudStack都采用第一种方式为虚拟机提供块设备。
图十三
图十四
上述图示也表明了在大量VM的情况下如何使得存储容量利用的最小化和高效性。当大量VM基于同一个Snapshot建立Volume时，所有容量不会立即得到占用，而都是COW。这个特征也是目前众多存储厂商在VDI解决方案一直强调的。在VDI解决方案中，存储成本是最重要的一环，利用Ceph通过Thin provisioning和数据并行化可以大大提高VDI方案的吸引力。
目前Ceph的块存储是大力推荐并且高速开发的模块，因为它提供的接口对于用户更加熟悉，并且在目前流行的OpenStack和CloudStack中可以得到广泛接受和支持。Ceph块存储的计算和存储解耦、Live migration特性、高效的快照和克隆/恢复都是引入注目的特性。
CephFS是基于Rados实现的PB级分布式文件系统，这里会引入一个新的组件MDS(Meta Data Server)，它主要为兼容POSIX文件系统提供元数据，如目录和文件元数据。同时，MDS会将元数据也存在RADOS(Ceph Cluster)中。元数据存储在RADOS中后，元数据本身也达到了并行化，大大加强了文件操作的速度。需要注意的是MDS并不会直接为Client提供文件数据，而只是为Client提供元数据的操作。
图十五
从上图可以看到，Client当Open一个文件时，会查询并更新MDS相应的元数据如文件包括的对象信息，然后再根据提供的对象信息直接从RADOS(Ceph Cluster)中直接得到文件数据。
图十六
CephFS既然是分布式文件系统，当面对不同的文件热点和大小时，它需要提供数据负载均衡来避免MDS的热点。通过上图我们可以看到五个MDS管理着不同“面积”的目录树，因为不同文件的访问热点和大小的原因来进行动态调整。
这里还需要介绍引入MDS带来的好处有目录列表操作的加快，如目录下文件大小、数量和时间等。同时，支持对文件的快照。
目前CephFS有多种使用方式: 1. Linux Kernel client: 使用”mount -t ceph 8.8.8.8:/ /mnt”可以直接挂载到本地并访问。 2. ceph-fuse: 通过ceph-fuse可以从用户态空间挂载CephFS如”ceph-fuse -m 192.168.0.1:6789 /home/username/cephfs” 3. libcephfs.so: 通过libcephfs可以替代HDFS来支持不同Hadoop乃至HBase。
QoS机制: Ceph Cluster支持多种QoS配置，如集群重平衡，数据恢复的优先级配置，避免影响正常的数据通信。
Geo-replication: 基于地理位置的对象存储
OpenStack: Ceph目前在大力融合入OpenStack，OpenStack的所有存储(除数据库外)都可以将Ceph作为存储后端。如KeyStone和Swfit可以利用RadosGW，Cinder、Glance和Nova利用RBD作为块存储。甚至所有VM的Image都存储在CephFS上。
目前Ceph的优化点也非常多，目前Rados IO路径过于复杂，线程管理得不到有限控制，如果在Rados上优化Small IO的性能，Ceph Cluster的集群性能会得到极大提高。很多人也会担心Ceph实现了如此多样的存储接口会不会一定降低每一个接口的性能要求。但从架构上来说，Ceph的RADOS只是一个单纯的分布式存储机制，其上的接口看到的都是一层统一的存储池，接口实现互相分离而不影响。
