梳理ceph的各组件及功能,基于ceph-deploy部署ceph集群,梳理块存储、文件存储及对象存储的使用场景,基于ceph块存储实现块设备挂载及使用,基于cephFS实现多主机数据共享

1.梳理ceph的各组件及功能

ceph 的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为
RADOS(reliable automatic distributed object store)存储集群，即可靠的、自动化的、分布式的对象存储系统。
librados 是 RADOS 存储集群的 API，支持 C/C++/JAVA/python/ruby/php/go
等编程语言客户端。
ceph 集群角色定义：

LIBRADOS、RADOSGW、RBD 和 Ceph FS 统称为 Ceph 客户端接口。RADOSGW、
RBD、Ceph FS 是基于 LIBRADOS 提供的多编程语言接口开发的。
一个ceph集群的组成部分：
若干的ceph OSD（对象存储守护进程）
至少需要一个ceph monitors监视器
两个或以上的ceph管理器managers，运行ceph文件系统客户端时还需要高可用的ceph metadata server(文件系统元数据服务器)
RADOS cluster:由多台host存储服务器组成的ceph集群
OSD(Object Storage Daemon)：每台存储服务器的磁盘组成的存储空间
Mon(Monitor):ceph的监视器，维护OSD和PG的集群状态，一个ceph集群至少要有一个mon,可以是1,3,5,7等这样的奇数个。
Mgr(Manager):负责跟踪运行时指标和Ceph集群的当前状态，包括存储利用率，当前性能指标和系统负载等。
Monitor(ceph-mon) ceph 监视器
在一个主机上运行的一个守护进程，用于维护集群状态映射，比如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用于处理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 逻辑组织架构：
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(gpid)->osd1,osd2,osd3]
第四步：PG中的主OSD将对象写入到硬盘
第五步：主OSD将数据同步给备份OSD,并等待备份OSD返回确认
第六步：主OSD将写入完成返回给客户端
ceph 元数据保存方式：
Ceph 对象数据的元数据信息放在哪里呢? 对象数据的元数据以 key-value 的形式存在，在RADOS 中有两种实现：xattrs 和 omap：ceph 可选后端支持多种存储引擎，比如 filestore,bluestore，kvstore，memstore，ceph 使用 bluestore 存储对象数据的元数据信息
xattrs(扩展属性)：
是将元数据保存在对象对应文件的扩展属性中并保存到系统磁盘上，这要求支持对象存储的本地文件系统（一般是 XFS）支持扩展属性
omap(object map 对象映射):
omap：是 object map 的简称，是将元数据保存在本地文件系统之外的独立 key-value 存
储系统中，在使用 filestore 时是 leveldb，在使用 bluestore 时是 rocksdb，由于 filestore
存在功能问题(需要将磁盘格式化为 XFS 格式)及元数据高可用问题等问题，因此在目前ceph主要使用 bluestore。
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 索引，解决文件系统目录结构遍历效率低的问题
支持多种设备类型
RocksDB 通过中间层 BlueRocksDB 访问文件系统的接口。这个文件系统与传统的 Linux
文件系统（例如 Ext4 和 XFS）是不同的，它不是在 VFS 下面的通用文件系统，而是一个用户态的逻辑。BlueFS 通过函数接口（API，非 POSIX）的方式为 BlueRocksDB 提供类似文件系统的能力
BlueStore 的设计考虑了 FileStore 中存在的一些硬伤，抛弃了传统的文件系统直接管理裸设备，缩短了 IO 路径，同时采用 ROW 的方式，避免了日志双写的问题，在写入性能上有了极大的提高。
*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 存储集群控制数据的分配

二. 基于ceph-deploy部署ceph集群

仓库准备：
各节点配置 ceph yum 仓库：
导入 key 文件:
#支持 https 镜像仓库源：

~# apt install -y apt-transport-https ca-certificates curl softw