目录

Ceph 简介

ceph的构成

        ceph 集群基础：

                 Monitor(ceph-mon)：ceph 监视器

                 Managers(ceph-mgr)的功能：

                Ceph OSDs(对象存储守护程序 ceph-osd)：

                 MDS(ceph 元数据服务器，ceph-mds)：

                Ceph 的管理节点：

 元数据的保存方式

                xattr 扩展属性

                omap(object map 对象映射):

                filestore与leveldb

                bluestore 与 rocksdb

CRUSH 算法简介

Ceph 简介

        Ceph 是一个开源的分布式存储系统，包括对象存储、块设备、文件系统

        ceph 是一个对象(object)式存储系统，它把每一个待管理的数据流(文件等数据)切分为一到多个固定大小(默认 4 兆)的对象数据，并以其为原子单元(原子是构成元素的最小单元)完成数据的读写。

        对象数据的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为

RADOS(reliable automatic distributed object store)存储集群，即可靠的、自动化的、分布式的

对象存储系统。

ceph的构成

• Pool：存储池、分区，存储池的大小取决于底层的存储空间。

• PG(placement group)：一个 pool 内部可以有多个 PG 存在，pool 和 PG 都是抽象的逻辑概念，一个 pool 中有多少个 PG 可以通过公式计算。

• OSD(Object Storage Daemon):每一块磁盘叫做 osd，多个 osd 组成一个主机

• librados 是 RADOS 存储集群的 API，支持 C/C++/JAVA/python/ruby/php 等编程语言客户端调用。

        存储池要先创建才能往 ceph 保存数据，文件在向 ceph 保存之前要先进行一致性 hash 计算，计算后会把文件保存在某个对应的 PG 的，某个文件一定属于某个 pool 的 PG，在通过 PG保存在 OSD 上。数据对象在写到主 OSD 之后再同步到从 OSD 以实现数据的高可用。

监视器 mon 维护 OSD 和 PG 的集群状态，

        ceph 集群基础：

一个 ceph 集群的组成部分：

        1、若干的 Ceph OSD（对象存储守护程序） 实际的服务器

        2、两个或以上的 Ceph 管理器 managers，运行 Ceph 文件系统客户端时，还需要高可用的 Ceph Metadata Server(文件系统元数据服务器)。负责跟踪运行时指标和 Ceph 集群的当前状态，包括存储利用率，当前性能 指标和系统负载等。 可以兼容普罗米修斯

        3、RADOS cluster:由多台 host 存储服务器组成的 ceph 集群。 RADOS (Reliable, Autonomic Distributed Object Store) 是Ceph的核心之一，作为Ceph分布式文件系统的一个子项目，特别为Ceph的需求设计，能够在动态变化和异质结构的存储设备机群之上提供一种稳定、可扩展、高性能的单一逻辑对象(Object)存储接口和能够实现节点的自适应和自管理的存储系统

        4、OSD(Object Storage Daemon)：每台存储服务器的磁盘组成的存储空间

        5、Mon(Monitor)：ceph 的监视器,维护 OSD 和 PG 的集群状态，一个 ceph 集群至少要有一个mon，可以是一三五七等等这样的奇数个。

                 Monitor(ceph-mon)：ceph 监视器

        在一个主机上运行的一个守护进程，用于维护集群状态映射(maintains maps of the cluster state)，比如 ceph 集群中有多少存储池、每个存储池有多少 PG 以及存储池和 PG 的映 射关系等， monitor map, manager map, the OSD map, the MDS map, and the CRUSH map，这 些映射是 Ceph 守护程序相互协调所需的关键群集状态，此外监视器还负责管理守护程序和 客户端之间的身份验证(认证使用 cephX 协议)。通常至少需要三个监视器才能实现冗余和高 可用性

                 Managers(ceph-mgr)的功能：

        在一个主机上运行的一个守护进程，Ceph Manager 守护程序（ceph-mgr）负责跟踪运 行时指标和 Ceph 集群的当前状态，包括存储利用率，当前性能指标和系统负载。Ceph Manager 守护程序还托管基于python 的模块来管理和公开 Ceph 集群信息，包括基于 Web 的 Ceph 仪表板和 REST API。高可用性通常至少需要两个管理器。

                Ceph OSDs(对象存储守护程序 ceph-osd)：

        提供存储数据，一个磁盘就是一个 OSD，因此一个服务器的 OSD 不能超过磁盘的总数， OSD 用于处理 ceph 集群数据复制，恢复，重新平衡，并通过检查其他 Ceph OSD 守护程序的 心跳来向 Ceph 监视器和管理器提供一些监视信息。通常至少需要 3 个 Ceph OSD 才能实现 冗余和高可用性。

                 MDS(ceph 元数据服务器，ceph-mds)：

        代表 ceph文件系统(NFS/CIFS)存储元数据，(即 Ceph块设备和 Ceph对象存储不使用 MDS)

                Ceph 的管理节点：

        1、ceph 的常用管理接口是一组命令行工具程序，例如 rados、ceph、rbd 等命令，ceph 管理员可以从某个特定的 ceph-mon 节点执行管理操作

        2、推荐使用部署专用的管理节点对 ceph 进行配置管理、升级与后期维护，方便后期权限管理，管理节点的权限只对管理人员开放，可以避免一些不必要的误操作的发生。

 元数据的保存方式

        Ceph 对象数据的元数据信息放在哪里呢? 对象数据的元数据以 key-value 的形式存在， 在RADOS 中有两种实现：xattrs 和 omap：

        ceph 可选后端支持多种存储引擎，比如 filestore，kvstore，memstore，目前是以 kvstore 的 形式存储对象数据的元数据信息。

                xattr 扩展属性

        是将元数据保存在对象对应文件数据中并保存到系统磁盘上，这要求支持对象存储的 本地文件系统（一般是 XFS）支持扩展属性。元数据和数据放一起

                omap(object map 对象映射):

        omap：是 object map 的简称，是将元数据保存在本地文件系统之外的独立 key-value 存储 系统中，在使用 filestore 时是 leveldb，在使用 bluestore 时是 rocksdb，由于 filestore 存 在功能问题(需要将磁盘格式化为 XFS 格式)及元数据高可用问题等问题，因此在目前 ceph 主要使用 bluestore。

                filestore与leveldb

        ceph 早期基于 filestore 使用 google 的 levelDB 保存对象的元数据，LevelDb 是一个持久化存 储的 KV 系统，和 Redis 这种内存型的 KV 系统不同，LevelDb 不会像 Redis 一样将数据放在内存从而占用大量的内存空间，而是将大部分数据存储到磁盘上，但是需要把磁盘上的 levelDB 空间格式化为文件系统(XFS).

        FileStore 将数据保存到与 Posix 兼容的文件系统(例如 Btrfs、XFS、Ext4)。在 Ceph 后端使用传 统的 Linux 文件系统尽管提供了一些好处，但也有代价，如性能、 对象属性与磁盘本地文 件系统属性匹配存在限制等

filestore 数据写入的过程

filestore 日志的三个阶段

                bluestore 与 rocksdb

        由于 levelDB 依然需要需要磁盘文件系统的支持，后期 facebok 对 levelDB 进行改进为 RocksDB，RocksDB 将对象数据的元数据保存在 RocksDB，但是 RocksDB 的数据又放在哪里呢？放在内存怕丢失，放在本地磁盘但是解决不了高可用，ceph 对象数据放在了每个 OSD 中，那么就在在当前 OSD 中划分出一部分空间，格式化为 BlueFS 文件系统用于保存 RocksDB 中的元数据信息(称为 BlueStore)，并实现元数据的高可用， BlueStore 最大的特点是构建在裸磁盘设备之上，并且对诸如 SSD 等新的存储设备做了很多 优化工作。

        BlueStore 的设计考虑了 FileStore 中存在的一些硬伤，抛弃了传统的文件系统直接管理裸设 备，缩短了 IO 路径，同时采用 ROW 的方式，避免了日志双写的问题，在写入性能上有了极大的提高。

CRUSH 算法简介

        Controllers replication under scalable hashing #可控的、可复制的、可伸缩的一致性 hash 算法

        Ceph 使用 CURSH 算法来存放和管理数据，它是 Ceph 的智能数据分发机制。Ceph 使用 CRUSH 算法来准确计算数据应该被保存到哪里，以及应该从哪里读取,和保存元数据不同,是CRUSH 按需计算出元数据，因此它就消除了对中心式的服务器／网关的需求,它使得 Ceph 客户端能够计算出元数据，该过程也称为CRUSH 查找，然后和 OSD 直接通信。

本文链接：https://my.lmcjl.com/post/8413.html