ceph集群中各个节点时间,ceph官方文档

文章目录一、Ceph集群角色二、Ceph元数据存储方式2.1 xattrs (扩展属性) 2.2omap (对象映射)2.2.1 filestore和leveldb2.2.2 bluestore

一、Ceph集群的作用

的几个对象存储守护程序(Ceph OSD )至少需要一个ceph监视器(1，3，5，7 . )两个或多个cephmanager (mgr )，cephfilesystem 由多个主机存储服务组成的ceph群集。 对象存储区域(OSD )—由每个存储服务器的磁盘组成的存储空间。 mon(monitor ):ceph的监视器，维持OSD和PG的集群状态。 一个ceph集群至少需要一个mon，可以是奇数个，如一三五七。 管理器(mgr )跟踪运行时指标和Ceph群集的当前状态，包括存储利用率、当前性能指标和系统负载。Monitor(ceph-mon)：ceph 监视器 （简称：mon）

在主机上运行以维护“集群状态映射”(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的模块，用于基于Web的ceph仪表板和REST API 高可用性通常至少需要两个管理器。

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

提供存储数据。 磁盘是OSD。 因此，一台服务器的OSD不能超过磁盘总数。 OSD用于处理、恢复和重新平衡ceph群集的数据复制，并通过检查其他Ceph OSD守护进程的心跳为ceph监视器和管理器提供监视信息。 要实现冗馀和高可用性，通常至少需要三个Ceph OSD。相当于给每一个磁盘起一个OSD进程，如果磁盘坏了，OSD进程也就挂了。

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

ceph文件系统(NFS/CIFS )存储元数据(即ceph块设备和ceph对象存储)不使用MDS。 仅通过启用Ceph FS就需要启用的组件。

Ceph 的管理节点：

1.ceph的典型管理界面是一组命令行工具程序，如rados、ceph和rbd，ceph管理员可以从特定的ceph-mon节点执行管理操作

2 .建议使用专门部署的管理节点进行ceph的配置管理、升级和后期维护，方便后期权限管理，管理节点权限只对管理员开放，避免不必要的误操作发生。

二、Ceph元数据存储方式Ceph对象数据的元数据信息放在哪里？ 目标数据的元数据以key-value的形式存在，在RADOS中有xattrs和omap两种实现。

ceph选项的后端支持多种存储引擎，包括filestore、kvstore和memstore。 对象数据的元数据信息当前存储为kvstore。

2.1 xattrs (扩展属性)将元数据存储在与对象对应的文件的扩展属性中，并存储在系统磁盘上，支持对象存储的本地文件系统(通常为XFS )需要支持扩展属性

2.2对象映射(omap )是对象映射(omap )的简称，它通过将元数据存储在独立于本地文件系统的密钥值存储系统中来使用filestore 由于filestore存在功能问题、磁盘必须格式化为XFS格式、元数据可用性高等问题，ceph目前主要使用蓝牙。

2.2.1文件和l

eveldb

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

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

filestore 数据写入的过程

先把要写入的数据全部封装成一个事务，其整理作为一条日志，写入日志磁盘（一般把 日志放在 ssd 上提高性 能），这个过程叫日志的提交（journal submit）。把数据写入对象文件的磁盘中（也就是 OSD 的磁盘中），这个过程叫日志的应用(journal apply)。这个过程不一定写入磁盘，有可能缓存在本地文件系统的 page cache 中。 当系统在日志提交的过程中出错，系统重启后，直接丢弃不完整的日志条目，该条日志对应 的实际对象数据并没有修改，数据保证了一致性。当日志在应用过程中出错，由于日志已写 入到磁盘中，系统重启后，重放（replay）日志，这样保证新数据重新完整的写入，保证了 数据的一致性。

filestore 日志的三个阶段
日志的提交（journal submit）：日志写入日志磁盘。
日志的应用(journal apply)：日志对应的修改更新到对象的磁盘文件中。这个过程不一定写入 磁盘，有可能缓存在本地文件系统的 page cache 中。
日志的同步（journal sync 或者 journal commit）：确定日志对应的修改操作已经刷到磁盘 中。

2.2.2 bluestore 与 rocksdb

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

特点

对全 SSD 及全 NVMe SSD 闪存适配 绕过本地文件系统层，直接管理裸设备，缩短 IO 路径 严格分离元数据和数据，提高索引效率 使用 KV 索引，解决文件系统目录结构遍历效率低的问题 支持多种设备类型 解决日志“双写”问题 期望带来至少 2 倍的写性能提升和同等读性能 增加数据校验及数据压缩等功能

RocksDB 通过中间层 BlueRocksDB 访问文件系统的接口。这个文件系统与传统的 Linux 文件 系统（例如 Ext4 和 XFS）是不同的，它不是在 VFS 下面的通用文件系统，而是一个用户态的 逻辑。BlueFS 通过函数接口（API，非 POSIX）的方式为 BlueRocksDB 提供类似文件系统的能 力

RocksDB 通过中间层 BlueRocksDB 访问文件系统的接口。这个文件系统与传统的 Linux 文件 系统（例如 Ext4 和 XFS）是不同的，它不是在 VFS 下面的通用文件系统，而是一个用户态的逻辑。BlueFS 通过函数接口（API，非 POSIX）的方式为 BlueRocksDB 提供类似文件系统的能力。

BlueStore 的逻辑架构如上图所示，模块的划分都还比较清晰，我们来看下各模块的作用：
Allocator：负责裸设备的空间管理。
RocksDB：rocksdb 是 facebook 基于 leveldb 开发的一款 kv 数据库，BlueStore 将元数据全部 存放至 RocksDB 中，这些元数据包括存储预写式日志、数据对象元数据、Ceph 的 omap 数 据信息、以及分配器的元数据 。
BlueRocksEnv：这是 RocksDB 与 BlueFS 交互的接口；RocksDB 提供了文件操作的接口 EnvWrapper(Env 封装器)，可以通过继承实现该接口来自定义底层的读写操作，BlueRocksEnv 就是继承自 EnvWrapper 实现对 BlueFS 的读写。
BlueFS：BlueFS是BlueStore针对RocksDB开发的轻量级文件系统，用于存放RocksDB产生的.sst 和.log 等文件。
BlockDecive：BlueStore 抛弃了传统的 ext4、xfs 文件系统，使用直接管理裸盘的方式；BlueStore 支持同时使用多种不同类型的设备，在逻辑上 BlueStore 将存储空间划分为三层：慢速（Slow） 空间、高速（DB）空间、超高速（WAL）空间，不同的空间可以指定使用不同的设备类型， 当然也可使用同一块设备。

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

三、CRUSH 算法简介

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

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

如果是把对象直接映射到 OSD 之上会导致对象与 OSD 的对应关系过于紧密和耦合，当 OSD 由于故障发生变更时将会对整个 ceph 集群产生影响。于是 ceph 将一个对象映射到 RADOS 集群的时候分为两步走： 首先使用一致性 hash 算法将对象名称映射到 PG，然后将 PG ID 基于 CRUSH 算法映射到 OSD 即可查到对象以上两个过程都是以”实时计算”的方式完成，而没有使用传统的查询数据与块设备的对应 表的方式，这样有效避免了组件的”中心化”问题，也解决了查询性能和冗余问题。使得 ceph 集群扩展不再受查询的性能限制。这个实时计算操作使用的就是 CRUSH 算法 Controllers replication under scalable hashing #可控的、可复制的、可伸缩的数据一致性 hash 算法。CRUSH 是一种分布式算法，类似于一致性 hash 算法，用于为 RADOS 存储集群控制数据的 分配。

总结：一个pool，500G数据，pool里面有32个PG，如果一个OSD坏了，只需要复制十几G的数据即可。如果分的PG太少，就会导致复制的量太大。