存储类型介绍
块存储
块存储在使用的时候需要格式化为指定的文件系统，然后挂载使用，其对操作系统的兼容性 相对比较好(可以格式化为操作系统支持的文件系统)
挂载的时候通常是每个服务单独分配 独立的块存储，即各服务的块存储是独立且不共享使用的
使用场景:
- Redis 的 master 和 slave 的 块存储是独立的、
- zookeeper 各节点的快存储是独立的、
- MySQL 的 master 和 slave 的块存 储是独立的、
- 也可以用于私有云与公有云的虚拟机的系统盘和云盘等场景，此类场景适合使 用块存储。
cephFS
对于需要在多个主机实现数据共享的场景
使用场景: 比如多个 nginx 读取由多个 tomcat 写入到存储 的数据，可以使用 ceph FS。
对象存储
而对于数据不会经常变化、删除和修改的场景，
使用场景: 如短视频、APP 下载等，可以使用对象存储。
Ceph 基础
Ceph 是一个开源的分布式存储系统，同时支持对象存储、块设备、文件系统
ceph 的底层存储服务是由多个存储主机(host)组成的存储集群，该集群也被称之为
RADOS(reliable automatic distributed object store)存储集群，即可靠的、自动化的、分布式的对象存储系统。
librados 是 RADOS 存储集群的 API，支持 C/C++/JAVA/python/ruby/php/go等编程语言客户端
- 对象存储的访问
- 块存储的访问 RADOS gateway
- 文件存储的访问
ceph 的设计思想
Ceph 的设计旨在实现以下目标：
- 每一组件皆可扩展
- 无单点故障
- 基于软件(而非专用设备)并且开源(无供应商锁定)
- 在现有的廉价硬件上运行
- 尽可能自动管理，减少用户干预
ceph 集群角色定义
逻辑架构图
LIBRADOS、RADOSGW(对象存储网关)、RBD(块存储) 和 Ceph FS(文件系统) 统称为 Ceph 客户端接口
RADOSGW、RBD、Ceph FS 是基于 LIBRADOS 提供的多编程语言接口开发的
一个 ceph 集群的组成部分
- 若干的 Ceph OSD（对象存储守护程序）
- 硬盘的空间 型号都是一样的
- 每块硬盘都会启动一个ceph进行
- 至少需要一个 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 集群的当前状态，
- 存储利用率
- 性能指标
- 系统负载
Monitor(ceph-mon) ceph 监视器
在一个主机上运行的一个守护进程
用于维护集群状态映射(maintains maps of thecluster 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 用于处理 ceph集群数据复制、恢复、重新平衡，
并通过检查其他 Ceph OSD 守护程序的心跳来向 Ceph监视器和管理器提供一些监视信息。
通常至少需要 3 个 Ceph OSD 才能实现冗余和高可用性
MDS(ceph 元数据服务器 ceph-mds metadaa server)
代表 ceph 文件系统(NFS/CIFS)存储元数据，(即 Ceph 块设备和 Ceph 对象存储不使用MDS)
Ceph 的管理节点
- ceph 的常用管理接口是一组命令行工具程序，例如 rados、ceph、rbd 等命令，
ceph 管理员可以从某个特定的 ceph-mon 节点执行管理操作
- 推荐使用部署专用的管理节点对 ceph 进行配置管理、升级与后期维护，方便后期权限管理，管理节点的权限只对管理人员开放，可以避免一些不必要的误操作的发生。
ceph 逻辑组织架构
Pool 存储池、分区
在Ceph中，Pool被定义为存储数据时的逻辑分区，它起着类似于命名空间的作用 对业务数据 进行逻辑隔离 类似k8s的namespace。
每个Pool都包含一定数量的PG（Placement Group），而PG里的对象会被映射到不同的OSD（对象存储设备）上。
因此，一个Pool的信息会被分布到整个Ceph集群中。这种设计使得Ceph能有效地进行数据管理和冗余备份。
存储池的大小取决于底层的存储空间。
PG(placement group) 归置组
在Ceph中，PG（Placement Group）是一个放置策略组，它是对象的集合，该集合里的所有对象都具有相同的放置策略；简单点说就是相同PG内的对象都会放到相同的硬盘上。
PG是Ceph的核心概念，服务端数据均衡和恢复的最小粒度就是PG。
一个 pool 内部可以有多个 PG 存在，pool 和 PG 都是抽象的逻辑概念，一个 pool 中有多少个 PG 可以通过公式计算
OSD(Object Storage Daemon,对象存储设备)
每一块磁盘都是一个 osd，一个主机由一个或多个 osd 组成.
存储文件过程
大体思路
ceph 集群部署好之后,要先创建存储池才能向 ceph 写入数据
文件在向 ceph 保存之前要先进行一致性 hash 计算，计算后会把文件保存在某个对应的 PG
此文件一定属于某个pool 的一个 PG，在通过 PG 保存在 OSD 上。
数据对象 先写到 主OSD 之后 再将数据同步到 从OSD , 以实现数据的高可用
step1 计算文件 --> 对象的映射
计算文件(例如图片 视频)到对象的映射, 假如 file 为客户端要读写的文件, 得到 oid(object id) = ino + ono
技术名词解释
ino: inode number (INO)，File 的元数据序列号，File 的唯一id。
ono: object number (ONO)，File 切分产生的某个 object 的序号，默认以 4M 切分一个块大小。
例如 存储一个5M的视频文件 那么会计算出一个ino 举例a-xxx 会计算出2 个object id
$ino-$ono-1 存储4M$ino-$ono-2 存储1M
step2 通过 hash 算法计算出 object对应的 pool 中的 PG
通过一致性 HASH 计算 Object 到 PG， Object -> PG 映射 hash(oid) & mask-> pgid
step3 通过 CRUSH 算法 把对象映射到 PG 中的 OSD
通过 CRUSH 算法 计算 PG -> OSD 映射：[CRUSH(pgid)->(osd1,osd2,osd3)]
