Ceph分布式存储(一)
定义:
Ceph是一个开源的、可靠地、自动均衡、自动恢复的、自治的分布式存储系统,该系统具备高可用性、高性能及可扩展等特点
支持云基础架构、媒体存储库、备份和恢复系统、海量存储,它具备诸多优势:摆脱对基于硬件的专有存储解决方案的依赖,是分布式存储的主流方案
Ceph特点:
高性能:
a. 摒弃了传统的集中式存储元数据寻址的方案,采用CRUSH算法,数据分布均衡,并行度高
b.考虑了容灾域的隔离,能够实现各类负载的副本放置规则,例如跨机房等
c. 能够支持上千个存储节点的规模,支持TB到PB级的数据
高可用性:
a. 副本数可以灵活控制
b. 支持故障域分隔,数据强一致性
c. 多种故障场景自动进行修复自愈
d. 没有单点故障,自动管理
高可扩展性:
a. 去中心化
b. 扩展灵活
c. 随着节点增加而线性增长
特性丰富:
a. 支持三种存储接口:块存储、文件存储、对象存储
b. 支持自定义接口,支持多种语言驱动
三种存储服务:
对象存储(Cephrgw)、块设备存储(CephRBD)和 文件系统服务(CephFs)
对象存储(Object Storage):
既可以通过使用Ceph的库利用C, C++, Java, Python, PHP代码,也可以通过Restful网关以对象的形式访问或存储数据,并兼容亚马逊的S3和OpenStack的Swift
块存储(Block Storage):
作为块设备像硬盘一样直接挂载 Ceph 的 RBD(RBD是Ceph面向块存储的接口) 在常见的存储中 DAS、SAN 提供的都是块存储
文件系统(File System) :
如同网络文件系统一样挂载,包括POSIX接口,它跟传统的文件系统如 Ext4 xfs是一个类型的,但区别在于分布式存储提供了并行化的能力,如 Ceph 的 CephFS (CephFS是Ceph面向文件存储的接口),但是有时候又会把 GlusterFS ,HDFS 这种非POSIX接口的类文件存储接口归入此类。当然 NFS、也是属于文件系统存储;
Ceph体系架构
Ceph的底层是RADOS,RADOS本身也是分布式存储系统,CEPH所有的存储功能都是基于RADOS实现。RADOS采用C++开发,所提供的原生Librados API包括C和C++两种。Ceph的上层应用调用本机上的librados API,再由后者通过socket与RADOS集群中的其他节点通信并完成各种操作
RADOS GateWay、RBD其作用是在librados库的基础上提供抽象层次更高、更便于应用或客户端使用的上层接口
其中,RADOS GW是一个提供与Amazon S3和Swift兼容的RESTful API的gateway,以供相应的对象存储应用开发使用。RBD则提供了一个标准的块设备接口,常用于在虚拟化的场景下为虚拟机创建volume。目前,Red Hat已经将RBD驱动集成在KVM/QEMU中,以提高虚拟机访问性能。这两种方式目前在云计算中应用的比较多
CEPHFS则提供了POSIX接口,用户可直接通过客户端挂载使用,它是内核态的程序,所以无需调用用户空间的librados库。它通过内核中的net模块来与Rados进行交互
个人理解:
1. Ceph支持文件系统存储、块存储、对象存储;
2.
中间 librados 是提供上层接口(librbd、librgw、libcephfs
)访问底层 RADOS 集群存储系统的各种库函数;
3. RAODS 提供了一个完整的存储系统,包含:Monitors、OSDs、MDS
a. Monitor:用来监视Ceph集群的健康状态,并保存各种map信息;
b. OSDs:主要用来存储数据的守护进程,以PG位单位进行数据的存储、迁移和恢复;
c. MDS:文件系统的元数据管理服务流程,主要针对CephFS中的元数据信息进行管理
4. 在 librados 的基础上又抽象出了块设备库(librbd)、对象存储的库(libgw)和文件系统库(libcephfs)
Ceph 核心组件概念:
(1)Monitors:监视器,维护集群状态的多种映射,同时提供认证和日志记录服务,包括有关monitor 节点端到端的信息,其中包括 Ceph 集群ID,监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息,通过 "ceph mon dump"查看 monitor map ceph mon stat 查看状态
(2)MDS(Metadata Server):Ceph 元数据,主要保存的是Ceph文件系统的元数据。注意:ceph的块存储和ceph对象存储都不需要MDS
(3)OSD:即对象存储守护程序,但是它并非针对对象存储。是物理磁盘驱动器,将数据以对象的形式存储到集群中的每个节点的物理磁盘上,OSD负责存储数据、处理数据复制、恢复、回(Backfilling)、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现,在构建 Ceph OSD的时候,建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测,检测结果汇报给Monitor
(4) RADOS:Reliable Autonomic Distributed Object Store,RADOS是ceph存储集群的基础,在ceph中所有数据都以对象的形式存储,并且无论什么数据类型,RADOS对象 存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致
(5)librados:librados库,为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口
(6)RADOSGW:网关接口,提供对象存储服务。它使用librgw和librados来实现允许应用程序与Ceph对象存储建立连接。并且提供S3 和 Swift 兼容的RESTful API接口。
(7)RBD:块设备,它能够自动精简配置并可调整大小,而且将数据分散存储在多个OSD上
(8)CephFS:Ceph文件系统,与POSIX兼容的文件系统,基于librados封装原生接口
(9)Pool:是自定义的存储池命名空间,用来隔离对象与PG,是存储对象的逻辑分区
ceph数据的存储过程:
Ceph基本原理是把一个文件分割为大小相同的小块(object),然后根据一定的规则算法映射到一个中间组织层(PG),再把各个PG分散存储在不同的OSD上
无论使用哪种存储方式(对象、块、文件),存储的数据都会被切分成对象(Objects)
Objects size大小可以由管理员调整,通常为2M或4M。每个对象都会有一个唯一的OID,由ino与ono生成,虽然这些名词看上去很复杂,其实相当简单。ino即是文件的File ID,用于在全局唯一标示每一个文件,而ono则是分片的编号。比如:一个文件FileID为A,它被切成了两个对象,一个对象编号0,另一个编号1,那么这两个文件的oid则为A0与A1。Oid的好处是可以唯一标示每个不同的对象,并且存储了对象与文件的从属关系。由于ceph的所有数据都虚拟成了整齐划一的对象,所以在读写时效率都会比较高
但是对象并不会直接存储进OSD中,因为对象的size很小,在一个大规模的集群中可能有几百到几千万个对象。这么多对象光是遍历寻址,速度都是很缓慢的;并且如果将对象直接通过某种固定映射的哈希算法映射到osd上,当这个osd损坏时,对象无法自动迁移至其他osd上面(因为映射函数不允许)。为了解决这些问题,ceph引入了归置组的概念,即PG
PG是一个逻辑概念,我们linux系统中可以直接看到对象,但是无法直接看到PG。它在数据寻址时类似于数据库中的索引:每个对象都会固定映射进一个PG中,所以当我们要寻找一个对象时,只需要先找到对象所属的PG,然后遍历这个PG就可以了,无需遍历所有对象。而且在数据迁移时,也是以PG作为基本单位进行迁移,ceph不会直接操作对象
一个PG负责组织若干个object(可以为数千个甚至更多),但一个object只能被映射到一个PG中,即,PG和object之间是“一对多”映射关系。同时,一个PG会被映射到n个OSD上,而每个OSD上都会承载大量的PG,即,PG和OSD之间是“多对多”映射关系。在实践当中,n至少为2,如果用于生产环境,则至少为3,这也是存储的数据高可用的核心
对象时如何映射进PG的?还记得OID么?首先使用静态hash函数对OID做hash取出特征码,用特征码与PG的数量去模,得到的序号则是PGID。由于这种设计方式,PG的数量多寡直接决定了数据分布的均匀性,所以合理设置的PG数量可以很好的提升CEPH集群的性能并使数据均匀分布。
最后PG会根据管理员设置的副本数量进行复制,然后通过crush算法存储到不同的OSD节点上(其实是把PG中的所有对象存储到节点上),第一个osd节点即为主节点,其余均为从节点
基于上述定义,便可以对寻址流程进行解释了,具体而言 Ceph中的寻址至少要经历以下三次映射:
(1)File -> object映射
(2)Object -> PG映射,hash(oid) & mask -> pgid
(3)PG -> OSD映射,CRUSH算法
ceph对象元数据mds与监控服务mon还有osd的关系:
客户端读写数据会先访问元数据服务器,访问到元数据之后,然后去monitor拿一个crush map,再去OSD寻找这个数据
如果是提供块存储则可以不需要元数据服务,直接访问监控服务即可
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!