详解Ceph数据是如何布局的？

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

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

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

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的不同副本位于不同的故障域中。