Ceph 基础知识点

Ceph官方文档：docs.ceph.org.cn

Ceph的两种存储引擎：

1、xfs文件系统FileStore

2、磁盘裸设备blockStore成为BlueStore

因为早期是把数据存储在格式化好的磁盘上的，后期直接把数据存放在裸设备上由Ceph直接管理裸设备。

Ceph存储方式：每个数据流就是一个对象，每个对象自己存储元数据和数据。存储时会将一个文件的数据流切分为固定大小数据对象，默认每个4M，每个对象就是一个基础管理单元，类似k8s中的Pod。

Object

file->objects（对象自带元数据，每个对象都有ID）。

FileStore方式：

        将文件存入OSD时由于存储是一个文件系统，需要将Object再转换成元数据和文件，object的元数据存放在levelDB中，object的文件放在文件系统中，因为文件有属组属主等信息，需要将这些信息再存放在xfs文件系统的元数据里面。

BlueStore方式：

        将对象的文件直接存放在裸设备上，对象的元数据放在RocksDB中，RocksDB也是有元数据的，它的元数据放在blueFS文件系统中。生产环境中可以把数据放在机械磁盘中，把RocksDB和BlueFS存放在固态硬盘上。Ceph的新版本都是使用的BlueStore。

对象存储方式：多主机组成的存储集群，称为RADOS存储集群（Reliable Automatic Distributed Object Store）。

存储集群API：librados是集群的存储API，可以使用多种语言调用API来实现存储。

CRUSH算法：通过计算的方式完成对象路由，实现了免查询即可找到对象存在的位置。

CephFS：文件系统，至少需要一个守护进程ceph-mds。

RBD：块设备，模拟磁盘设备，不需要守护进程，通过librbd api调用即可。

RadosGW：对象存储，云存储，至少需要一个守护进程ceph-radosgw。

mon：有状态服务，保存着集群级别的元数据信息，如集群节点数、OSD数、集群状态、PG状态等信息。monitor需要高可用，内部使用分布式一致性协作协议Paxos（类似于etcd的raft协议）进行数据同步。每个节点都可写，写完之后同步给其他节点。

        monitor保存这集群运行图Cluster map，包括monitor map、manager map、OSD map、CRUSH map、PG map。

        monitor也负责集群的认证，内部认证CephX，内部各个组件之间的通信都要经过monitor，它是一个认证中心。外部认证，用户名密码等信息。

mgr：从L版开始引入manager，跟踪运行时的指标数据，磁盘占用情况、CPU使用情况、维护查询操作，如监控Ceph要进行集群数据查询，mgr则将数据缓存下来以供查询操作等功能。mgr属于无状态服务，两个节点即可实现高可用。

osd：磁盘。单独的存储磁盘设备，每个osd都有单独的守护进程ceph-osd。

mds：文件系统元数据服务ceph-mds，需要冗余，只有在使用CephFS才需要启动。

        RADOS将存储空间分成多个存储池pool，存储池也可以再划分为名称空间（可选），每个存储池都有归制组PG（placement group），都是抽象的概念，真实并不存在。使用CRUSH算法进行存储数据。

CRUSH算法第一步：对象映射到PG

        文件被切分为多个对象之后，再将对象进行一致性hash计算之后，在再hash环上的PG进行映射。

CRUSH算法第二部：PG映射到OSD

        根据存储池冗余副本数量和类型找到足量的OSD来存储，PG是一个管理单元，冗余的是PG，一主两副就是一个主PG加上两个冗余PG，分别存放在不同节点上。先写入主PG再同步到其他PG。