Ceph 对象存储设备

Ceph 的OSD 是Ceph 存储集群中最重要的一个基础组件，它负责将实际的数据以对象的形式存储在每一个集群节点的物理磁盘驱动器中。Ceph 集群中的大部分工作是由OSD 守护进程完成的。存储用户数据是真正最耗时的部分。

Ceph OSD 以对象的形式存储所有客户端数据，并在客户端发起数据请求时提供相同的数据。Ceph 集群包含多个OSD 。对于任何读或写操作，客户端首先向monitor 请求集群的map ，然后，它们就可以无须monitor 的干预直接与OSD 进行I／O操作也正是因为产生数据的客户端能够直接写入存储数据的OSD 而没有任何额外的数据处理层，才使得数据事务处理速度如此之快。与其他存储解决方案相比，这种类型的数据存储和取回机制是Ceph 所独有的。

Ceph 的核心特性（比如可靠性、自平衡、自恢复和一致性）都始于OSD 。根据配置的副本数， Ceph通过跨集群节点复制每个对象多次来提供可靠性，同时使其具有高可用性容错性。OSD 上的每个对象都有一个主副本和几个辅副本，辅副本分散在其他OSD 上。由于Ceph 是一个分布式系统且对象分布在多个OSD 上，因此每一个OSD 对于一些对象而言是主副本。但同时对于其他对象而言就是辅副本，存放辅副本的OSD 受主副本OSD 控制；然而，它们也可能又成为主副本OSD 。

Ceph的OSD由一个已经存在Linux 文件系统的物理磁盘驱动器和10SD 服务组成。

Linux文件系统对于OSD 守护进程而言是相当重要的，因为它决定了支持哪些扩展属性（ XATTR） 。这些文件系统扩展属性能够为OSD 守护进程提供内部对象的状态、快照、元数据和ACL 等信息．这有助于数据管理。

OSD在拥有有效Linux 分区的物理磁盘驱动器上进行操作。Linux 分区可以是Btrfs （B树文件系统）、XFS 或ext4。Ceph 集群的性能基准测试的主要标准之一就是文件系统的选择。

Btrfs

与使用XFS 和ext4 文件系统的OSD 相比，使用Btrfs 文件系统的OSD 能够提供更佳的性能。使用Btrfs 最主要的一个优点是支持写时复制和可写的快照，这对于虑拟机的部署和克隆非常有用。在文件系统中它还支持透明的压缩、普遍的校验和多设备的统一管理。还支持高效的XATTR 、对于小文件的合井，还有SSD上所熟知的集成卷管理，并支持在线fsck 的特性。然而，尽管有如此多的新特性，Btrfs 目前还不具备应用于生产系统的条件，但对于测试而言它是一个很好的选择。

XFS

这是一个可靠、成熟且非常稳定的文件系统，因此，我们推荐在生产环境的Ceph 集群中使用它。XFS 是Ceph存储中最常用的文件系统．也是推荐OSD 使用的文件系统。然而，从另一个方面来看，XFS 又不如Btrfs。XFS 在元数据扩展性上存在性能问题，XFS 也是一种日志文件系统， 也就是说．每次客户端发送数据以写入Ceph 集群时，肯先需要写人口志空间，然后再写入XFS 文件系统这样的两次写入操作增加了开销从而使得XFS 的性能不如Btrfs，Btrfs 没有使用日志。

Ext4

ext4 文件系统也是一种日志文件系统，是一个远合生产环境下Ceph OSD 使用的文件系统；然而，它的受欢迎程度不如XFS 。从性能的角度来看，ext4 文件系统也不如Btrfs。

Ceph OSD 使用诸如Btrfs 和XFS 的日志文件系统。在将数据提交到备用存储之前，Ceph 首先将数据写入一个称为日志（ journal） 的独立存储区域，日志是相同的机械磁盘（如OSD） 或不同的SSD 磁盘或分区上一小块缓冲区大小的分区，甚至也可以是文件系统上的一个文件。在这种机制中，Ceph 的所有写都是先到日志，然后再到备用存储，如下图所示。

Ceph Monitor

顾名思义，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 算法为集群提供了分布式决策机制。集群中monitor 数目应该是奇数，最低要求是一个monitor 节点，推荐的数是3 。自monitor开始仲裁操作，至少需要保证一半以上的monitor 始终处于可用状态，这样才可以防止其他系统可以看到的脑裂问题。

这就是为什么推荐使用奇数个monitor。在所有的集群monitor 巾，其中有一个是领导者（ leader ） 。如果领导者monitor不可用其他monitor 节点也有权成为领导者。生产环境下的集群必须至少有三个monitor节点来提供高可用性。

对于企业级生产环境，建议使用专门的monitor 节点。这样， 一旦你的OSD 节点发生

故障，只要你有足够的monitor 运行在独立的机器上，你仍然可以连接到你的Ceph 集群。在存储的规划阶段，也应该考虑物理机架的布局。你应该将monitor节点分散到所有的故障域中，例如，不同的开关、电源和物理机架。如果你有多个数据中心连接在同一个高速网络，monitor 节点应该放到不同的数据中心。