ceph架构

一、架构图

二、相关名词解释

1、RADOS
Reliable Autonomic Distributed Object Store（可靠的，自主的，分布式的对象存储）。在 ceph 中这个名词经常出现，有时会以 R 表示 RADOS。实际上这个词仅仅是对 ceph 的一个修饰词，并不代表 ceph 的组件什么的。粗暴的认为， RADOS = ceph 对象存储集群 即可。

RADOS 是Ceph 存储系统的核心，也称为Ceph 存储集群。Ceph 的所有优秀特性都是由RADOS 提供的，包括分布式对象存储、高可用性、高可靠性、没有单点故障、向我修复以及自我管理等。RADOS 层在Ceph 存储架构中扮演着举足轻重的角色。Ceph 的数据访问方法(如RBD 、CephFS 、RADOS GW 和librados ) 的所有操作都是在RADOS 层之上构建的。

当Ceph 集群接收到来向客户端的写请求时，CRUSH 算法首先计算出存储位置，以此决定应该将数据写入什么地方。然后这些信息传递到RADOS 层进行进一步处理。基于CRUSH 规则集，RADOS 以小对象的形式将数据分发到集群内的所有节点。最后，将这些对象存储在OSD 中

当配置的复制数大于1时，RADOS 负责数据的可靠性。同时，它复制对象，创建副本，并将它们存储在不同的故障区域中，换言之，同一个对象的副本不会存放在同一个故障区域中。然而，如果有更多个性化需求和更高的可靠性，就需要根据实际需求和基础架构来优化CRUSH 规则集。RADOS 能够保证在一个RADOS 集群中的对象副本总是不少于一个，只要你有足够的设备。

除了跨集群存储和复制对象之外，RADOS 也确保对象状态的一致性。在对象不一致的情况下，将会利用剩下的副本执行恢复操作。这个操作自动执行，对于用户而言是透明的，从而为Ceph 提供了自我管理和自我修复的能力。如果仔细分析Ceph 的架构图，你会发现它有两部分: RADOS 在最下部，它完全处于Ceph集群的内部，没有提供给客户端直接接口;另一部分就是在RADOS 之上的面向所有客户端的接口

2、Libradios
Librados是Rados提供库，因为RADOS是协议很难直接访问，因此上层的RBD、RGW和CephFS都是通过librados访问的，目前提供PHP、Ruby、Java、Python、C和C++支持。
这一层的功能是对RADOS进行抽象和封装，并向上层提供API，以便直接基于RADOS（而不是ceph）进行应用开发。物理上libradios和基于其上开发的应用位于同一台机器，因此也被成为本地API。应用调用本机上的libradios API，再由后者通过socket与RADIOS集群中的节点通信完成各种操作。

3、 RBD
RBD全称RADOS block device，是Ceph对外提供的块设备服务。
块存储是企业环境中最常见的一种数据存储格式。Ceph 块设备也称为RADOS 块设备(RBD) ;它为物理层的虚拟机监控程序以及虚拟机提供块存储解决方案。Ceph 的RBD 驱动程序已经被集成到Linux 内核( 2.6.39 或更高版本)中，而且已经被QEMU/KVM 支持，它们能无缝地访问Ceph 块设备。
Linux主机能全力支持内核RBD (KRB D ) 并通过librados 映射Ceph 块设备。然后RADOS将Ceph 块设备的对象以分布式模式存储在集群中。一旦Ceph 块设备映射到Linux主机，它也可以当作裸分区或标记为文件系统，然后进行挂载。
4、RGW
RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。
Ceph 对象网关，也称做RADOS 网关，它是一个代理，可以将HTTP 请求转换为RADOS ，同时也可以把RADOS 请求转换为HTTP 请求，从而提供RESTful 对象存储，这兼容S3 和Swift。Ceph 对象存储使用Ceph 对象网关守护进程( radosgw) 与librgw 、librados (Ceph 集群)交互。这是使用libfcgi 作为FastCGI的一个模块来实现的，并且可以被任何支持FastCGl的Web 服务器使用。

5、CephFS
CephFS全称Ceph File System，是Ceph对外提供的文件系统服务。
CephFS 在RADOS 层之上提供了一个兼容POSIX 的文件系统。它使用MDS 作为守护进程，负责管理其元数据并将它和其他数据分开，这有助于降低复杂性并提高可靠性。CephFS 继承了RADOS 的特性并为数据提供了动态再平衡。

6、CRUSH
CRUSH是Ceph使用的数据分布算法，类似一致性哈希，让数据分配到预期的地方。
7、Monitor
一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据。

顾名思义，Ceph monitor 负责监控整个集群的健康状况。它们以守护进程的形式存在，这些守护进程通过存储集群的关键信息来维护集群成员状态、对等节点状态，以及集群配置信息。Ceph monitor 通过维护整个集群状态的主副本来完成它的任务。集群map 包括monitor 、OSD 、PG 、CRUSH 和MDS map o 所有这些map 统称为集群map 。让我们简单地浏览一下每个map 的功能。

monitor map
它维护着monitor 节点间端到端的信息，其中包括Ceph 集群ID 、monitor 主机名、IP 地址及端口号。它还存储着当前map 的创建版本和最后一次修改的信息。可以通过下面的命令检查集群的monitor map:
ceph mon dump

OSD map :
它存储着一些常见的信息，如集群ID、OSD map 创建版本和最后一次修改信息，以及与池相关的信息(如池名字、池ID 、类型、副本数和归置组) 。它还存储着OSD 的一些信息，如数目、状态、权重、最近处于clean 状态的间隔以及OSD 主机等信息。可以通过执行以下命令获取集群的OSD map
ceph osd dump

PG map :
它存储着归置组的版本、时间戳、最新的OSD map 版本、容量充满的比例以及容量接近充满的比例等信息。它同时也跟踪每个归置组的ID 、对象数、状态状态时间戳、OSD 的叩集合、OSD 的acting 集合，最后还有清洗等信息。要检查集群的PG map ，执行:
ceph pg dump

CRUSH map:
它存储着集群的存储设备信息、故障域层次结构以及在故障域中定义如何存储数据的规则。要查看集群的CRUSH map ，执行:
ceph osd crush dump

MDS map:
它存储着当前MDS map 的版本，map 的创建和修改时间，数据和元数据池的ID ，集群中MDS 的数目以及MDS 的状态。要查看集群MDS map ，执行:
ceph mds dump

一个典型的Ceph 集群通常包含多个monitor 节点。多monitor 的Ceph 架构使用了仲裁( quorum ) ，使用Paxos 算法为集群提供了分