分布式存储Ceph存储系统RADOS

RADOS是Ceph最为关键的技术，它是一个完整的对象存储系统，所有存储在Ceph系统中的数据最终由这一层来存储。本文主要介绍RADOS的系统架构和IO处理流程，以了解Ceph存储的设计原理。

---

1、Ceph功能模块与RADOS

Ceph存储系统的逻辑结构在“分布式系列之分布式存储ceph初识”介绍过，大致分为4个部分：基于存储系统RADOS、基于RADOS实现的CephFS、基于RADOS的LIBRADOS层应用接口、基于LIBRADOS的应用接口RBD和RADOSGW。

• 基础存储系统RADOS：Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象的形式存储。在物理上，RADOS由大量的存储设备节点组成，每个节点拥有自己的硬件资源，并运行着操作系统和文件系统。
• 基础库LIBRADOS：LIBRADOS层的功能是对RADOS进行抽象和封装，并向上层提供API以便直接基于RADOS进行应用开发。应用程序通过访问LIBRADOS库来与RADOS系统进行交互，支持多种编程语言，比如C、C++、Python等。物理上，LIBRADOS与基于其上开发的应用在同一台机器，也称为本地API。
• 上层应用接口：Ceph上层应用接口包括对象存储RADOSGW、块存储RBD和文件系统存储CephFS。RADOSGW提供与Amazon S3和Swift兼容的RESTful API网关，供相应的对象存储应用开发使用；RBD提供标准的块设备接口，常用于虚拟化场景下为虚拟机创建volume。
• 应用层：Ceph各应用接口在不同应用场景下的使用，例如基于LIBRADOS直接开发的对象存储应用、基于RADOSGW开发的对象存储应用、基于RBD实现的云主机硬盘等。

2、RADOS系统架构

RADOS包括两类节点：存储节点和管理节点，其中存储节点称为OSD（object storage device），只需要包含CPU、网卡、本地缓存和一个磁盘或者RAID，并将传统的块存储方式替换成面向对象的存储。

• OSD：由大规模OSD组成的集群，负责存储的所有objects数据
• Monitor：管理节点由Monitors组成的强耦合、小规模集群，负责管理cluster map
• 对于RADOS系统，节点组织管理和数据分发策略均由内部的Mon全权负责，因此从client的角度设计相对简单，它给应用提供存储接口

在大数据量的存储系统中，存储设备会存储新旧设备的替换、大量的数据迁移或恢复，RADOS通过cluster map实现这些动态调配，cluster map是整个RADOS系统的关键数据结构，其中存储了整个集群的数据的分布以及成员信息。cluster map会被复制到存储集群中的所有存储节点、控制节点甚至客户端。

2.1 Monitor介绍

Ceph Monitor负责整个集群运行状况的监控，包括各个节点之间的状态、集群配置信息，这些信息由维护集群成员的守护进程提供的。Monitor集群通过操作cluster map来实现成员的管理，cluster map描述了哪些OSD被包含进存储集群以及所有数据在存储集群中的分布。

Ceph monitor中的cluster map包括OSD Map、PG Map、MDS Map和crush map，这些map不仅存储在monitor节点，也会被复制到集群中的每一个存储节点，以及和集群交互的client。当设备崩溃或数据迁移时，cluster map的内容需要进行更新，cluster map的版本号被增加，map的版本号可以使通信的双方确认自己的map是否是最新的，版本旧的一方会先将map更新成新的map，然后才会进行后续操作。

1）Monitor Map

Monitor Map包括monitor节点端到端信息，其中有Ceph集群id、监控主机名和ip地址及端口号，同时还存储了当前版本信息和最新更改记录，通过命令ceph mon map进行查看：

root@tango-centos01:/osd/data# ceph mon dump
dumped monmap epoch 1
epoch 1
fsid 4387471a-ae2b-47c4-b67e-9004860d0fd0
last_changed 0.000000
created 0.000000
0: 192.168.112.101:6789/0 mon.ceph1
1: 192.168.112.102:6789/0 mon.ceph2
2: 192.168.112.103:6789/0 mon.ceph3

2）OSD Map

OSD Map包括集群ID、创建OSD的版本信息和最新更新信息、Pool相关信息、副本数目，还包括OSD的数量、状态、权重和OSD主机信息。通过命令ceph osd dump进行查看：

root@tango-centos01:~# ceph osd dump
epoch 76
fsid 4387471a-ae2b-47c4-b67e-9004860d0fd0
created 2021-01-18 02:16:19.504735
modified 2021-01-21 21:58:55.305221
flags
pool 0 'data' replicated size 3 min_size 2 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 1 flags hashpspool crash_replay_interval 45 stripe_width 0
osd.3 up   in  weight 1 up_from 26 up_thru 64 down_at 25 last_clean_interval [7,23) 192.168.112.101:6801/1204 192.168.112.101:6802/1204 192.168.112.101:6803/1204 192.168.112.101:6804/1204 exists,up d55567da-4e2a-40ca-b7c9-5a30240c895a
......

3）PG map

PG map包括当前PG版本、时间戳、最新OSD map 的版本信息、空间使用比例，也包括每个PG ID、对象数目、OSD状态等信息。通过命令ceph pg dump进行查看：

ceph pg dump 

4）CRUSH Map：Crush map包括当前磁盘、服务器、机架等层级结构信息。通过以下命令可以查看crush map：

Ceph osd crush dump

CRUSH map使用分层结构来组织集群中的所有存储设备：

CRUSH rules主要有三个作用：

• 指定从CRUSH Map 中的哪个节点开始查找
• 指定使用那个节点作为故障隔离域
• 指定定位副本的搜索模式（广度优先 or 深度优先）

5）MDS map

MDS map包括当前的MDS版本信息、map创建的时间和最新修改时间、数据和元数据的POOL ID、集群MDS数目和MDS状态。通过命令ceph mds dump查看MDS map信息：

root@tango-centos01:~# ceph mds dump
dumped mdsmap epoch 13
epoch   13
flags   0
created 2021-09-18 02:16:19.504427
modified        2015-09-18 08:05:55.438558
4171:   192.168.112.101:6800/962 'ceph1' mds.0.2 up:active seq 7

MDS只用于Ceph文件系统该，与RDB和对象存储无关

2.2 OSD介绍

OSD是Ceph存储集群最重要的组件，Ceph OSD将数据以对象的形式存储在集群中每个节点的物理磁盘上，用户数据的存储大部分是由OSD daemon进程来实现的。Ceph集群包含多个OSD，client从ceph monitor获取cluster map后，直接与OSD进行I/O读写请求操作，不再需要Ceph monitor干预，这样使得读写过程没有额外的数据处理。

2.2.1 OSD副本配置

Ceph的核心功能具备高可靠、自动平衡、自动恢复和一致性。在OSD中，Ceph将OSD的副本分布在多个节点上来实现高可用性及容错性。OSD中的每个对象都有一个主副本，若干个从副本，默认情况下这些副本是分布在不同的存储节点的。一个OSD可能为某些对象的主OSD，同时又是其它对象的从OSD。当出现磁盘故障时，OSD daemon进程的对等机制会协同其它进程执行恢复操作，在此期间从OSD会提升为主OSD，新的从OSD副本也会重新生成，这样就保证了OSD的可靠性和一致性。

2.2.2 OSD数据存储

OSD的架构由物理磁盘驱动器、其上的文件系统以及OSD服务组成，如下图所示，一个Ceph 存储节点上可以有一个或者多个数据盘，每个数据盘上部署有特定的文件系统，比如xfs、ext4或者btrfs，由一个 OSD Daemon负责照顾其状态以及向其读写数据。对于OSD daemon进程而言，文件系统显性的支持了其扩展属性，这些扩展属性提供了对象状态、快照和元数据内部信息。

1）BTRFS：相比XFS和EXT4性能更好，有以下特性

• 扩展性：Extent、B-Tree和动态inode创建等特性保证了BTRFS在大型机器上仍有卓越的表现，其整体性能不会随着系统容量的增加而降低
• 数据一致性：当出现系统故障时，BTRFS采用COW事务技术来保证文件系统的一致性。BTRFS还支持校验和，避免了silent corrupt（未知错误）的出现，而传统文件系统无法做到这一点。
• 多设备管理相关的特性：BTRFS支持创建快照和克隆，同时能够管理多个物理设备
• 但是BTRFS的稳健性未达到生产要求，暂时不推荐在生产环境使用

2）XFS：高性能日志文件系统，有以下优点

• 分配组：XFS文件系统内部被分为多个“分配组”，它们是文件系统中的等长线性存储区。每个分配组各自管理自己的inode和剩余空间。文件和文件夹可以跨越分配组。这一机制为XFS提供了可伸缩性和并行特性，多个线程和进程可以同时在同一个文件系统上执行I/O操作。这种由分配组带来的内部分区机制在一个文件系统跨越多个物理设备时特别有用，使得优化对下级存储部件的吞吐量利用率成为可能。
• 条带化分配：在条带化RAID阵列上创建XFS文件系统时，可以指定一个“条带化数据单元”。这可以保证数据分配、inode分配，以及内部日志被对齐到该条带单元上，以此最大化吞吐量。
• 基于Extent的分配方式：XFS文件系统中的文件用到的块由变长Extent管理，每一个Extent描述了一个或多个连续的块。对那些把文件所有块都单独列出来的文件系统来说，Extent大幅缩短了列表。在XFS 中，空间分配管理由一对B+树面向extent的结构组成，其中一个B+树用于索引未被使用的Extent的长度，另一个索引这些Extent的起始块。这种双索引策略使得文件系统在定位剩余空间中的Extent时十分高效。
• 扩展属性：XFS通过实现扩展文件属性给文件提供了多个数据流，使文件可以被附加多个名/值对。扩展属性可以被添加到任意一种XFS inode上，包括符号链接、设备节点和目录等。

3）Ext4：Linux系统下的日志文件系统，有以下特性

• 大型文件系统：Ext4文件系统可支持最高1 Exbiby te的分区与最大16 Tebiby te的文件
• Extents：Ext4引进了Extent文件存储方式，以替换之前使用的块映射方式。Extent指的是一连串的连续实体块，这种方式可以增加大型文件的效率并减少分裂文件
• 日志校验和：Ext4使用日志校验和特性来提高文件系统可靠性
• 快速文件系统检查：Ext4将未使用的区块标记在inode当中，这样可以使诸如e2fsck之类的工具在磁盘检查时将这些区块完全跳过，从而节约大量的文件系统检查的时间。这个特性已经在2.6.24版本的Linux内核中实现

Ceph官方明确推荐在生产环境中使用 XFS，在开发、测试、非关键应用上使用btrfs。

2.2.3 OSD中IO流向

Ceph使用filestore作为存储后端时，在提交数据到后端存储前，Ceph先将日志和数据写入单独的存储区称为journal，这是一个单独的SSD磁盘或者分区。类似于数据库的write-ahead-log机制，在这种机制下，Ceph任何写入都是先写入journal文件，再被转移到FileStore的写入队列中，数据和元数据被异步写到指定区域，如下图所示：

1. 首先使用libaio的dio写入OSD的journal部分
2. 然后使用writev向filesystem发起buffer-io，当filestore_max_sync_interval后将buffer-io落盘

2.3 Ceph IO流程

2.3.1 OSD读写完整流程

该过程具有强一致性的特点：

1. Ceph的读写操作采用Primary-Replica模型，Client只向Object所对应OSD set的Primary发起读写请求，这保证了数据的强一致性。
2. 由于每个Object都只有一个Primary OSD，因此对Object的更新都是顺序的，不存在同步问题。
3. 当Primary收到Object的写请求时，它负责把数据发送给其他Replicas，只有当这个数据被保存在所有的OSD上时，Primary才应答Object的写请求，这保证了副本的一致性。这也带来一些副作用，相比那些只实现了最终一致性的存储系统比如Swift，Ceph只有所有的拷贝都写入完成后才算写入完成，这在出现磁盘损坏时会出现写延迟增加。
4. 在OSD上，在收到数据存放指令后，它会产生2~3个磁盘seek操作：
   1. 把写操作记录到OSD的Journal文件上(Journal是为了保证写操作的原子性)
   2. 把写操作更新到Object对应的文件上
   3. 把写操作记录到PG Log文件上

2.3.2 正常IO流程图

1. client创建cluster handler。
2. client读取配置文件。
3. client连接上monitor，获取集群map信息。
4. client读写io 根据crush map 算法请求对应的主osd数据节点。
5. 主osd数据节点同时写入另外两个副本节点数据。
6. 等待主节点以及另外两个副本节点写完数据状态。
7. 主节点及副本节点写入状态都成功后，返回给client，io写入完成。

2.3.3 新主IO流程图

如果新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 由于OSD1上未创建 PG,不存在数据，那么PG上的I/O无法进行，怎样工作的呢？

1. client连接monitor获取集群map信息。
2. 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。
3. 临时主osd2会把数据全量同步给新主osd1。
4. client IO读写直接连接临时主osd2进行读写。
5. osd2收到读写io，同时写入另外两副本节点。
6. 等待osd2以及另外两副本写入成功。
7. osd2三份数据都写入成功返回给client, 此时client io读写完毕。
8. 如果osd1数据同步完毕，临时主osd2会交出主角色。
9. osd1成为主节点，osd2变成副本。

2.3.4 Ceph RBD IO流程图

Pool和PG知识将在后续内容中介绍，这里以RBD块存储为例介绍IO流程

1. 客户端创建一个pool，需要为这个pool指定pg的数量。
2. 创建pool/image rbd设备进行挂载。
3. 用户写入的数据进行切块，每个块的大小默认为4M，并且每个块都有一个名字，名字就是object+序号。
4. 将每个object通过pg进行副本位置的分配。
5. pg根据cursh算法会寻找3个osd，把这个object分别保存在这三个osd上。
6. osd上实际是把底层的disk进行了格式化操作，一般部署工具会将它格式化为xfs文件系统。
7. object的存储就变成了存储一个文rbd0.object1.file。

最后总结下，本文主要介绍了Ceph存储的RADOS系统架构，包括MON和OSD，以及OSD的IO处理流程。

---

参考资料：

1. Ceph分布式存储实战
2. Ceph设计原理与实现
3. https://docs.ceph.com/en/pacific/architecture/
4. https://www.jianshu.com/p/1e2898d71db8
5. https://www.cnblogs.com/sammyliu/p/4836014.html
6. https://www.jianshu.com/p/cc3ece850433
7. https://insujang.github.io/2020-08-30/introduction-to-ceph/

转载请注明原文地址：https://blog.csdn.net/solihawk/article/details/123021739
文章会同步在公众号“牧羊人的方向”更新，感兴趣的可以关注公众号，谢谢！