详解Ceph系统数据是如何布局的?

Ceph项目始于2004年,是为优秀的性能、可靠性和可扩展性而设计的统一的分布式存储系统。


在使用RADOS系统时,客户端程序通过与OSD或者Monitor的交互获取ClusterMap,然后直接在本地进行计算,得出对象的存储位置后,便直接与对应的OSD通信,完成数据的各种操作。可见,在此过程中,只要保证ClusterMap不频繁更新,则客户端显然可以不依赖于任何元数据服务器,不进行任何查表操作,便完成数据访问流程。


在RADOS的运行过程中,Cluster Map的更新完全取决于系统的状态变化,而导致这一变化的常见事件只有两种(OSD出现故障或者RADOS规模扩大)。而正常应用场景下,这两种事件发生的频率显然远远低于客户端对数据进行访问的频率。


详解Ceph系统数据是如何布局的?


OSD依赖底层文件系统Xattrs来记录对象状态和元数据,Xattr必须提供足够的容量大小,ext4仅4KB,xfs 64KB,而btrfs没有限制,Btrfs不够稳定,ext4 Xattr太小,生产部署推荐xfs测试推荐btrfs


  • Client:部署在Linux服务器上,实现数据切片,通过Crush算法定位对象位置,并进行对象数据的读写。

  • OSD:存储数据,处理数据复制,恢复,回填,重新调整,并向Monitor报告一些检测信息。单集群至少需要2个OSD,一般情况下一个OSD对应一块物理硬盘,部署btrfs、xfs或ext4的本地文件系统。

  • Monitor:实现OSD集群的状态监控,维护OSD(守护进程)映射,分组(PG)映射,和CRUSH映射。

  • Metadata Cluster:元数据集群,用于管理文件元数据,仅CephFS需要。

 

Ceph系统的逻辑架构和概念对理解数据布局和架构十分重要,所以有必要在此进行说明。


  • 一个Cluster可逻辑上划分为多个Pool。

  • 一个 Pool 包含若干个逻辑PG(Placement Group),同时可定义Pool内的副本数量。

  • 一个物理文件会被切分为多个Object。

  • 每个Object会被映射到一个PG,一个PG内可包含多个Object。

  • 一个PG映射到一组OSD,其中第一个OSD是主(Primary),其余的是从(Secondary),承担相同PG的OSD间通过心跳来相互监控存活状态。

  • 许多 PG 可以映射到某个OSD。

  • 引入PG的概念后,OSD只和PG相关,简化了OSD的数据存储;同时实现了Object到OSD的动态映射,OSD的添加和故障不影响Object的映射。



在Ceph的现有机制中,一个OSD平时需要和与其共同承载同一个PG的其他OSD交换信息,以确定各自是否工作正常,是否需要进行维护操作。由于一个OSD上大约承载数百个PG,每个PG内通常有3个OSD,因此,一段时间内,一个OSD大约需要进行数百至数千次OSD信息交换。


然而,如果没有PG的存在,则一个OSD需要和与其共同承载同一个Object的其他OSD交换信息。由于每个OSD上承载的Object很可能高达数百万个,因此,同样长度的一段时间内,一个OSD大约需要进行的OSD间信息交换将暴涨至数百万乃至数千万次。而这种状态维护成本显然过高。

 

数据寻址流程可分三个映射过程,首先要将用户要操作的File,映射为RADOS能够处理的Object。就是简单的按照Object的Size对File进行切分,相当于RAID中的条带化过程。接着把Object映射到PG,在File被映射为一个或多个Object之后,就需要将每个Object独立地映射到一个PG中去。第三次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD。

 

1.File ->Object映射


这次映射的目的是,将用户要操作的File,映射为RADOS能够处理的Object。其映射十分简单,本质上就是按照object的最大size对file进行切分,相当于RAID中的条带化过程。这种切分的好处有二。


  • 一是让大小不限的File变成最大Size一致、可以被RADOS高效管理的Object。

  • 二是让对单一File实施的串行处理变为对多个Object实施的并行化处理。


2.Object -> PG映射


在File被映射为一个或多个Object之后,就需要将每个Object独立地映射到一个PG中去。这个映射过程也很简单,如图中所示,其计算公式是(Hash(OID) & Mask -> PGID)。


3. PG -> OSD映射


第三次映射就是将作为Object的逻辑组织单元的PG映射到数据的实际存储单元OSD。如图所示,RADOS采用一个名为CRUSH的算法,将PGID代入其中,然后得到一组共N个OSD。这N个OSD即共同负责存储和维护一个PG中的所有Object。


1.File —— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言,这个file也就对应于应用中的“对象”,也就是用户直接操作的“对象”。将用户操作的File切分为RADOS层面的Object,每个Object一般为2MB或4MB,大小可设置。


2. Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是,Object的最大Size由RADOS限定(通常为2MB或4MB),以便实现底层存储的组织管理。因此,当上层应用向RADOS存入Size很大的File时,需要将File切分成统一大小的一系列Object(最后一个的大小可以不同)进行存储。为避免混淆,在本文中将尽量避免使用中文的“对象”这一名词,而直接使用File或Object进行说明。每个Object通过哈希算法映射到唯一的PG。


3. PG(Placement Group)—— 顾名思义,PG的用途是对Object的存储进行组织和位置映射。具体而言,一个PG负责组织若干个Object(可以为数千个甚至更多),但一个object只能被映射到一个PG中,即,PG和object之间是“一对多”映射关系。同时,一个PG会被映射到N个OSD上,而每个OSD上都会承载大量的PG,即,PG和OSD之间是“多对多”映射关系。在实践当中,N至少为2,如果用于生产环境,则至少为3。一个OSD上的PG则可达到数百个。


事实上,PG数量的设置牵扯到数据分布的均匀性问题。关于这一点,下文还将有所展开。每个PG通过CRUSH算法映射到实际存储单元OSD,PG和OSD间是多对多的映射关系.

 

4. OSD —— 即Object Storage Device,OSD的数量事实上也关系到系统的数据分布均匀性,因此其数量不应太少。在实践当中,至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。OSD在物理上可划分为多个故障域(机房、机架、服务器),可通过策略配置使PG的不同副本位于不同的故障域中。



上一篇:Ceph pool 资源池管理


下一篇:osd自杀问题跟踪