二、Ceph基础

本章概述

• Ceph发展史
• Ceph的设计思想
• Ceph的版本历史
• 集群角色定义
• 逻辑组织架构
• ceph元数据保存方式
• Ceph CRUSH算法简介

前言
  Ceph 是一个开源的分布式存储系统，同时支持对象存储、块设备、文件系统。
  ceph支持EB(1EB=1,000,000,000GB)级别的数据存储，ceph把每一个待管理的数据流(文件等数据)切分为一到多个固定大小(默认4兆)的对象数据，并以其为原子单元(原子是构成元素的最小单元)完成数据的读写。
  ceph 的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为RADOS(reliable automatic distributed object store)存储集群，即可靠的、自动化的、分布式的对象存储系统。
  librados 是 RADOS 存储集群的 API，支持 C/C++/JAVA/python/ruby/php/go等编程语言客户端。

2.1 Ceph发展史

  Ceph 项目起源于 于 2003 年在加州大学圣克鲁兹分校攻读博士期间的研究课题（Lustre 环境中的可扩展问题）。
  Lustre 是一种平行分布式文件系统,早在 1999 年，由皮特·布拉姆(Peter Braam)创建的集群文件系统公司(Cluster File Systems Inc)开始研发,并于 2003 年发布 Lustre 1.0 版本。
  2007 年 Sage Weil(塞奇·威尔)毕业后，Sage Weil 继续全职从事 Ceph 工作，2010年3月19日，Linus Torvalds 将 Ceph 客户端合并到 2010 年5月16日发布的 Linux 内核版本2.6.34,2012 年 Sage Weil 创建了 Inktank Storage 用于为 Ceph 提供专业服务和支持,2014年 4 月 Redhat 以 1.75 亿美元收购 inktank 公司并开源。

2.2 Ceph的设计思想

Ceph 的设计旨在实现以下目标：
  每一组件皆可扩展
  无单点故障
  基于软件(而非专用设备)并且开源(无供应商锁定)
  在现有的廉价硬件上运行
  尽可能自动管理，减少用户干预

2.3 Ceph的版本历史

  Ceph 的第一个版本是 0.1,发布日期为 2008年1月,多年来 ceph 的版本号一直采用递归更新的方式没变,直到 2015年4月0.94.1(Hammer 的第一个修正版)发布后,为了避免0.99(以及 0.100 或 1.00),后期的命名方式发生了改变:
  x.0.z - 开发版（给早期测试者和勇士们）
  x.1.z - 候选版（用于测试集群、高手们）
  x.2.z - 稳定、修正版（给用户们）
  x 将从 9 算起，它代表 Infernalis(首字母 I 是英文单词中的第九个字母),这样我们第九个发布周期的第一个开发版就是 9.0.0,后续的开发版依次是 9.0.0->9.0.1->9.0.2 等,测试版本就是9.1.0->9.1.1->9.1.2,稳定版本就是 9.2.0->9.2.1->9.2.2。

  到 2017 年底，Ceph项目都采取每年发布两个稳定版本的做法,从Jewel版到Nautilus之前，Ceph经历过一段时间的每间隔 9个月发布一个新版本,Nautilus 版本开始改为每年春季3月份发布一个稳定版本,并提供长达26个月左右的后期版本更新。

2.4 集群角色定义

Ceph集群角色定义可查看以下链接：
https://docs.ceph.com/en/latest/start/intro/
http://docs.ceph.org.cn/start/intro/

一个ceph集群的组成部分：
  若干的 Ceph OSD（对象存储守护程序）
  至少需要一个Ceph Monitors监视器（1,3,5,7...）
  两个或以上的Ceph管理器 managers，运行Ceph文件系统客户端时，还需要高可用的Ceph Metadata Server(文件系统元数据服务器)。
  RADOS cluster:由多台 host 存储服务器组成的 ceph 集群

组件介绍：
  OSD(Object Storage Daemon)：每台存储服务器的磁盘组成的存储空间
  Mon(Monitor)：ceph的监视器,维护OSD和PG的集群状态，一个ceph集群至少要有一个mon，可以是一三五七等等这样的奇数个。
  Mgr(Manager)：负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载等。

2.4.1 Monitor（ceph-mon）ceph监视器

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

2.4.2 Managers(ceph-mgr)的功能

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

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

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

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

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

2.4.5 Ceph的管理节点：

  1.ceph的常用管理接口是一组命令行工具程序，例如rados、ceph、rbd等命令，ceph管理员可以从某个特定的ceph-mon节点执行管理操作
  2.推荐使用部署专用的管理节点对ceph进行配置管理、升级与后期维护，方便后期权限管理，管理节点的权限只对管理人员开放，可以避免一些不必要的误操作的发生。

2.4.6 ceph术语

http://docs.ceph.org.cn/glossary/

2.5 逻辑组织架构

  Pool：存储池、分区，存储池的大小取决于底层的存储空间。
  PG(placement group)：一个 pool 内部可以有多个 PG 存在，pool 和 PG 都是抽象的逻辑概念，一个 pool 中有多少个 PG 可以通过公式计算。
  OSD(Object Storage Daemon,对象存储设备):每一块磁盘都是一个 osd，一个主机由一个或多个 osd 组成.

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

存储文件过程：
第一步: 计算文件到对象的映射:
  计算文件到对象的映射,假如 file 为客户端要读写的文件,得到 oid(object id) = ino + ono
  ino:inode number (INO)，File 的元数据序列号，File 的唯一 id。
  ono:object number (ONO)，File 切分产生的某个 object 的序号，默认以 4M 切分一个块大
第二步：通过 hash 算法计算出文件对应的 pool 中的 PG:
  通过一致性 HASH 计算 Object 到 PG， Object -> PG 映射 hash(oid) & mask-> pgid
第三步: 通过 CRUSH 把对象映射到 PG 中的 OSD
  通过 CRUSH 算法计算 PG 到 OSD，PG -> OSD 映射：[CRUSH(pgid)->(osd1,osd2,osd3)]
  在线进制转换：https://tool.oschina.net/hexconvert

假设有64个pg，即0~63，则63的二进制为0111111
假设hash值为100，100转换为二进制为1100100
把63的二进制与100的二进制进行与运算（两者都为1才为1，两者不为1均为0）
则二进制运算结果为0100100，转换为10进制为36，那么pgid将会写入第36个pg

注意：同一个文件在ceph集群中每台主机的运算结果均相同，存入的pg也相同，这样文件寻址才可以找到该文件（如果每台主机上存入的pg不同，查找文件时将会无法找到该文件 ）
第四步：PG 中的主 OSD 将对象写入到硬盘
第五步: 主 OSD 将数据同步给备份 OSD，并等待备份 OSD 返回确认
第六步: 主 OSD 将写入完成返回给客户端
注意：如果主OSD所在节点宕机，ceph集群会将备OSD中数据较新OSD所在节点作为主，然后新增一台节点作为备，然后把差异的数据同步给另外一台备节点，把所有数据全量同步给新增的主机（即支持全量同步和增量同步）

2.6 ceph元数据保存方式

  Ceph 对象数据的元数据信息放在哪里呢? 对象数据的元数据以 key-value 的形式存在，在RADOS 中有两种实现：xattrs 和 omap。
  ceph 可选后端支持多种存储引擎，比如 filestore，bluestore，kvstore，memstore，ceph 使用 bluestore 存储对象数据的元数据信息。

2.6.1 xattrs（扩展属性）

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

2.6.2 omap(object map 对象映射)

  omap：是 object map 的简称，是将元数据保存在本地文件系统之外的独立 key-value 存储系统中，在使用 filestore 时是 leveldb，在使用 bluestore 时是 rocksdb，由于 filestore存在功能问题(需要将磁盘格式化为 XFS格式)及元数据高可用问题等问题，因此在目前 ceph主要使用 bluestore。
2.6.2.1 filestore与leveldb
  ceph 早期基于 filestore 使用 google 的 levelDB 保存对象的元数据，LevelDb 是一个持久化存储的 KV 系统，和 Redis 这种内存型的 KV 系统不同，leveldb 不会像 Redis 一样将数据放在内存从而占用大量的内存空间，而是将大部分数据存储到磁盘上，但是需要把磁盘上的leveldb 空间格式化为文件系统(XFS)。
  FileStore 将数据保存到与 Posix 兼容的文件系统(例如 Btrfs、XFS、Ext4)。在 Ceph 后端使用传统的 Linux 文件系统尽管提供了一些好处，但也有代价，如性能、 对象属性与磁盘本地文件系统属性匹配存在限制等。
2.6.2.2 bluestore与rocksdb
  由于 levelDB 依然需要需要磁盘文件系统的支持，后期 facebook 对 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 提供类似文件系统的能力。

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 的方式，避免了日志双写的问题，在写入性能上有了极大的提高。

2.7 Ceph CRUSH算法简介

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

1.如果是把对象直接映射到 OSD 之上会导致对象与 OSD 的对应关系过于紧密和耦合，当OSD 由于故障发生变更时将会对整个 ceph 集群产生影响。

2.于是 ceph 将一个对象映射到 RADOS 集群的时候分为两步走：
首先使用一致性 hash 算法将对象名称映射到 PG 2.7，
然后将 PG ID 基于 CRUSH 算法映射到 OSD 即可查到对象

3.以上两个过程都是以”实时计算”的方式完成，而没有使用传统的查询数据与块设备的对应表的方式，这样有效避免了组件的”中心化”问题，也解决了查询性能和冗余问题。使得 ceph集群扩展不再受查询的性能限制。

4.这个实时计算操作使用的就是 CRUSH 算法
Controllers replication under scalable hashing #可控的、可复制的、可伸缩的一致性 hash算法。
CRUSH 是一种分布式算法，类似于一致性 hash 算法，用于为 RADOS 存储集群控制数据的分配。