王豪迈
作者王豪迈2017-01-20 10:24
CTO, 星辰天合(XSKY)

Why Ceph and how to use Ceph?

字数 3993阅读 3012评论 0赞 0

为什么需要关注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的接口。同时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的存储接口得到多样化,而不是让不同的存储接口勉强实现。不同的存储接口具有完全不同的路径。

以上两种方式都是将一个虚拟的块设备分片存储在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

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。

Ceph的其他

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只是一个单纯的分布式存储机制,其上的接口看到的都是一层统一的存储池,接口实现互相分离而不影响。

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广