共计 4142 个字符，预计需要花费 11 分钟才能阅读完成。
这篇文章将为大家详细讲解有关为什么需要关注 Ceph，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
为什么需要关注 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 只是一个单纯的分布式存储机制，其上的接口看到的都是一层统一的存储池，接口实现互相分离而不影响。
关于“为什么需要关注 Ceph”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
