块存储:需要格式化,将文件直接保存到磁盘上。文件存储:提供数据存储的接口,是由操作系统针对块存储的应用,即由操作系统提供存储接口,应用程序通过调用操作系统将文件保存到块存储进行持久化。对象存储:也称为基于对象的存储,其中的文件被拆分成多个部分并散布在多个存储服务器,在对象存储中,数据会被分解为称为“对象”的离散单元,并保存在单个存储库中,而不是作为文件夹中的文件或服务器上的块来保存,对象存储需要一个简单的 HTTP 应用编程接口 (API) ,以供大多数客户端(各种语言)使用
1.ceph的设计思想
2.ceph的版本
x.0.z - 开发版(给早期测试者和勇士们)
x.1.z - 候选版(用于测试集群、高手们)
x.2.z - 稳定、修正版(给用户们)
3.ceph集群角色定义
一个 ceph 集群的组成部分:
1、若干的 Ceph OSD (对象存储守护程序)2、至少需要一个 Ceph Monitors 监视器(1,3,5,7...)3、两个或以上的 Ceph 管理器 managers ,运行 Ceph 文件系统客户端时4、还需要高可用的 Ceph Metadata Server( 文件系统元数据服务器 ) 。5、RADOS cluster: 由多台 host 存储服务器组成的 ceph 集群6、OSD(Object Storage Daemon) :每台存储服务器的磁盘组成的存储空间7、Mon(Monitor) : ceph 的监视器 , 维护 OSD 和 PG 的集群状态,一个 ceph 集群至少要有一个 mon,可以是一三五七等等这样的奇数个。8、Mgr(Manager) :负责跟踪运行时指标和 Ceph 集群的当前状态,包括存储利用率,当前性能指标和系统负载等
Monitor(ceph-mon) ceph监视器:
在一个主机上运行的一个守护进程,用于维护集群状态映射 (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 的模块来管理和公开 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 进行配置管理、升级与后期维护,方便后期权限管理,管理节点的权限只对管理人员开放,可以避免一些不必要的误操作的发生。
4.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 以实现数据的高可用。
5,存储文件的过程
第一步: 计算文件到对象的映射
计算文件到对象的映射,假如 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)]第四步: PG 中的主 OSD 将对象写入到硬盘第五步 : 主 OSD 将数据同步给备份 OSD, 并等待备份 OSD 返回确认第六步 : 主 OSD 将写入完成返回给客户端
6.ceph元数据保存方式
xattrs(扩展属性):是将元数据保存在对象对应文件的扩展属性中并保存到系统磁盘上,这要求支持对象存储的 本地文件系统(一般是 XFS)支持扩展属性。
omap(object map 对象映射):是将元数据保存在本地文件系统之外的独立 key-value 存 储系统中,在使用 filestore 时是 leveldb,在使用 bluestore 时是 rocksdb,由于 filestore 存在功能问题(需要将磁盘格式化为 XFS格式)及元数据高可用问题等问题,因此在目前 ceph 主要使用 bluestore