1.2.2 无中心架构
1. 计算模式
Ceph 是无中心分布式存储系统（计算模式）的典型代表。Ceph 架构与 HDFS 架构不同的地方在于该存储架构中没有中心节点（元数据不需要集中保存），客户端（Client）通过设备映射关系及预先定义算法，可直接本地计算出其写入数据的存储位置，这样客户端可以直接与存储节点（Storage Node）进行通信交互，避免元数据中心节点成为存储系统的性能瓶颈。Ceph 系统架构如图 1-8 所示。
图 1-8 Ceph 系统架构
图 1-9 展示了 Ceph 存储系统的核心组件。
图 1-9 Ceph 系统组件构成
（1）Mon 服务
Mon 为 Monitor 的缩写，Ceph 的 Monitor 服务维护存储集群状态的各种图表，包括：
◆ 监视器图（Monitor Map），记录所有 Monitor节点的信息，如集群 ID、主机名、IP 和端口等。
◆ OSD 图（OSD Map）， 记 录 Ceph Pool 的Pool ID、名称、类型、副本、PGP 配置，以及 OSD的数量、状态、最小清理间隔、OSD 所在主机信息等。
◆ 归置组图（PG Map），记录当前的 PG 版本、时间戳、空间使用比例以及每个 PG 的基本信息。
◆ CRUSH 图（CRUSH Map，CRUSH 为Controlled Replication Under Scalable Hashing 的 缩写），记录集群存储设备信息、故障层次结构以及存储数据时故障域规则信息。
这些图表（Map）保存着集群发生在 Monitor、OSD、PG 和 CRUSH 上的每一次状态变更，这些状态变更的历史信息版本称为 epoch，可以用于集群的数据定位以及集群的数据恢复。
Monitor1 通过集群部署的方式保证其自身服务的可用性，由于遵循 Pasox 协议来进行leader 选举，Monitor 集群通常为奇数个节点部署，且部署节点数量不小于 3 个。
（2）OSD 服务
OSD 为 Object Storage Device 的缩写，Ceph 的 OSD 服务功能是存储数据、管理磁盘，以实现真正的数据读写，OSD 服务处理数据的复制、恢复、回填、再均衡等任务，并通过检查其他 OSD 守护进程的心跳来向 Ceph Monitor 服务提供监控信息。
通常一个磁盘对应一个 OSD 服务，但使用高性能存储介质时，也可以将存储介质进行分区处理，启动多个 OSD 守护进程进行磁盘空间管理（每个 OSD 守护进程对应一个磁盘分区）。
（3）MDS 服务
MDS 为 Metadata Server 的缩写，Ceph 的 MDS 服务为 Ceph 文件系统存储元数据，即Ceph 的块设备场景和对象存储场景不使用 MDS 服务。Ceph 的 MDS 服务主要负责 Ceph FS 集群中文件和目录的管理，记录数据的属性，如文件存储位置、大小、存储时间等，同时负责文件查找、文件记录、存储位置记录、访问授权等，允许 Ceph 的 POSIX 文件系统用户可以在不对 Ceph 存储集群造成负担的前提下，执行诸如文件的 ls、find 等基本命令。
MDS 通过主备部署的方式保证其自身服务的可用性，进程可以被配置为活跃或者被动状态，活跃的 MDS 为主 MDS，其他的 MDS 处于备用状态，当主 MDS 节点故障时，备用MDS 节点会接管其工作并被提升为主节点。
（4）RADOS
RADOS 为 Reliable Autonomic Distributed Object Store 的缩写，意为可靠、自主的分布式对象存储，从组件构成图中可见，RADOS 由上述 3 种服务（Mon、OSD、MDS）构成，其本质为一套分布式数据存储系统，即 RADOS 本身也是一套分布式存储集群。在 Ceph存储中所有的数据都以对象形式存在，RADOS 负责保存这些对象，RADOS 层可以确保对象数据始终保持一致性。从这个意义上讲，Ceph 存储系统可以认为是在 RADOS 对象存储系统之上的二次封装。
1 Ceph 的 Luminous 版本推出了 MGR（Manager Daemon）组件，该组件的主要作用是分担和扩展 Monitor 服务的部分功能，减轻 Monitor 的负担，它从 Monitor 服务中拆解出了部分对外暴露的集群状态指标，对外提供集群状态的统一查询入口。
RADOS 依据 Ceph 的需求进行设计，能够在动态变化和异构存储设备之上提供一种稳定、可扩展、高性能的单一逻辑对象存储接口，并能够实现节点的自适应和自管理。
（5）librados
librados 库为 PHP、Ruby、Java、Python、C、C++ 等语言提供了便捷的访问 RADOS接口的方式，即 librados 允许用户不通过 RESTful API、block API 或者 POSIX 文件系统接口访问 Ceph 存储集群。
librados API 可以访问 Ceph 存储集群的 Mon、OSD 服务。
（6）RBD
RBD 是 RADOS Block Device 的缩写，Ceph 的 RBD 接口可提供可靠的分布式、高性能块存储逻辑卷（Volume）给客户端使用。RBD 块设备可以类似于本地磁盘一样被操作系统挂载，具备快照、克隆、动态扩容、多副本和一致性等特性，写入 RBD 设备的数据以条带化的方式存储在 Ceph 集群的多个 OSD 中。
（7）RGW
RGW 是 RADOS Gateway 的缩写，Ceph 的 RGW 接口提供对象存储服务，RGW 基于 librados 接口实现了 FastCGI 服务封装，它允许应用程序和 Ceph 对象存储建立连接，RGW 提供了与 Amazon S3 和 OpenStack Swift 兼容的 Restful API。对象存储适用于图片、音视频等文件的上传与下载，可以设置相应的文件访问权限以及数据生命周期。
（8）CephFS
CephFS 是 Ceph File System 的缩写，CephFS 接口可提供与 POSIX 兼容的文件系统，用户能够对 Ceph 存储集群上的文件进行访问。CephFS 是 Ceph 集群最早支持的客户端，但对比 RBD 和 RGW，它又是 Ceph 最晚满足 production ready 的一个功能。
回到 Ceph 组件示意图，客户端访问存储集群的流程可总结如下。
客户端在启动后首先通过 RBD/RGW/CephFS 接口进入（也可基于 librados 自行适配业务进行接口开发），从 Mon 服务拉取存储资源布局信息（集群运行图），然后根据该布局信息和写入数据的名称等信息计算出期望数据的存储位置（包含具体的物理服务器信息和磁盘信息），然后和该位置信息对应的 OSD 服务直接通信，进行数据的读取或写入。
Ceph 是目前应用最广泛的开源分布式存储系统，它已经成为 Linux 操作系统和OpenStack 开源云计算基础设施的“标配”，并得到了众多厂商的支持。Ceph 可以同时提供对象存储、块存储和文件系统存储 3 种不同类型的存储服务，是一套名副其实的统一分布式存储系统，总结其特点如下。
◆ 高性能
Ceph 存储系统摒弃了集中式存储元数据寻址的方案，转而采用私有的 CRUSH 算法，元数据分布更加均衡，系统 I/O 操作并行度更高。
◆ 高可用性
Ceph 存储系统考虑了容灾域的隔离，能够实现多种数据放置策略规则，例如数据副本跨机房、机架感知冗余等，提升了数据的安全性；同时，Ceph 存储系统中数据副本数可以灵活控制，坚持数据的强一致性原则，系统没有单点故障，存储集群可进行修复自愈、自动管理，存储服务可用性高。
◆ 高可扩展性
Ceph 存储系统采用对称结构、全分布式设计，集群无中心节点，扩展灵活，能够支持上千台存储节点的规模，支持 PB 级的数据存储需求；且随着服务器节点的不断加入，存储系统的容量和 I/O 处理能力可获得线性增长，拥有强大的 scale out 能力。
◆ 接口及特性丰富
Ceph 存储系统支持块存储、文件存储、对象存储 3 种访问类型，且 3 个方向均已生产就绪：对象存储方面，Ceph 支持 Swift 和 S3 的 API 接口；块存储方面，除私有协议挂载外，Ceph 社区也在积极推动 iSCSI 方案，RBD 设备支持精简配置、快照、克隆等特性；文件系统存储方面，Ceph 支持 POSIX 接口，支持快照特性。同时，Ceph 通过 librados 可实现访问接口自定义，支持多种语言进行驱动开发。
2. 一致性 Hash 模式
Swift 是无中心分布式存储系统（一致性 Hash）的典型代表。Swift 由 Rackspace 开发，用来为云计算提供高可扩展性的对象存储集群。与 Ceph 通过自定义算法获得数据分布位置的方式不同，Swift 通过一致性 Hash 的方式获得数据存储位置。一致性 Hash 的方式就是将设备在逻辑上构建成一个 Hash 环，然后根据数据名称计算出的 Hash 值映射到 Hash环的某个位置，从而实现数据的定位。
Swift 中存在两种映射关系，对于一个文件，通过 Hash 算法（MD5）找到对应的虚节点（一对一的映射关系），虚节点再通过映射关系（Hash 环文件中的二维数组）找到对应的设备（多对多的映射关系），这样就完成一个文件存储在设备上的映射。
图 1-10 展示了 Swift 分布式存储系统的架构。
图 1-10 Swift 分布式存储系统架构
Swift 主要面向的对象存储应用场景，和 Ceph 提供的对象存储服务类似，主要用于解决非结构化数据的存储问题。
Swift 存储系统和 Ceph 存储系统主要区别如下。
◆ Swift 仅提供对象存储服务能力，而 Ceph 在设计之初就比 Swift 开放，除支持对象存储场景外，还支持块存储、文件存储使用场景；
◆ 数据一致性方面，Swift 提供数据最终一致性，在处理海量数据的效率上更占优势，主要面向对数据一致性要求不高，但对数据处理效率要求比较高的对象存储业务，而 Ceph存储系统始终强调数据的强一致性，更适用于对数据存储安全性要求较高的场景；
◆ 二者在应用于对象存储多数据中心场景下时，Swift 集群支持跨地域部署，允许数据先在本地写入（数据本地写入完成后就返回写入成功），然后基于一致性设计在一段时间里复制到远程地域，而 Ceph 存储系统则通常需要通过 Master-Slave 模型部署两套集群，从Master 到 Slave 进行数据异步复制，所以在多于两个地域时，基础架构上的负载分布会很不均衡 1。
1 虽然也可以构建一套 Ceph 集群扩展到两个地域，但数据的强一致性策略无法保证存储系统的 I/O 写入时延，因此，Ceph 存储系统在应用于多数据中心场景时，仍是两集群部署，然后使用 MultiSite 特性进行数据同步。
