Ceph RadosGW 对象存储集群的部署与优化

陈阳，王丹

（1.四川大学计算机学院，成都610065；2.中国核动力研究设计院，成都610213）

0 引言

Ceph 诞生于2003 年，由加州大学Sage Weil 作为其博士学位项目开发，2006 年Ceph 通过LGPL 协议正式开源。经过全世界科研工作者和开源社区十余年的迭代开发，Ceph 从最初单一的分布式文件系统，成长为可以同时支持文件存储、对象存储、块存储的，并具有高性能、高可靠性、高扩展的分布式存储系统。

对象存储作为云计算IaaS 层面的基础服务，通过扁平化的结构，提供了海量数据存储、无限扩容等能力，被各大云计算厂商推荐用于存储海量非结构化数据。RadosGW 作为Ceph 的重要组件之一，对用户提供了兼容S3、Swift 对象存储协议的RESTful 网关，并被广泛的用于私有云对象存储系统的核心解决方案。虽然RadosGW 已经提供了完整的兼容S3 以及Swift协议的对象存储接口，但是在实际的部署以及集群调优过程中，仍然面临不小的挑战。本文则从Ceph 基本架构的角度出发，提出一种高可用的集群部署方案，并根据RadosGW 数据存储结构以及存储引擎的基本特性角度出发，对RadosGW 集群的性能进行优化。

1 Ceph的基本架构

Ceph 分布式存储系统的基本架构如图1 所示，从整体来看可以分为Rados 以及Cliens 两个部分。其中，Rados 是一个完整的对等节点分布式存储系统，数据均以对象的形式存储与Rados 集群中。Rados 实现了对象的分布式存储、数据冗余、故障恢复以及集群状态监控等存储系统的核心功能。Ceph 项目中提供了三个Clients，分别是提供文件存储服务的MDS（Meta Data Server）、提供对象存储服务的RadosGW（Rados Gateway）以及提供块存储服务的RBD（Rados Block Device），均可以根据需要单独部署。Clients 通过librados访问底层Rados 集群，将数据持久化到Rados 集群中。通过使用librados，可以迅速将Rados 作为基本分布式存储引擎，扩展自己的存储相关应用。

图1 Ceph基本架构

Rados 的核心组件包括Monitor、OSD。其中：

（1）Monitor：监控整个集群的健康状态，保存了Rados 集群CRUSH Map、PG Map、OSD Map 等集群拓扑数据。Monitor 之间采用主备模式，通过Paxos 协议选举确定主Monitor。各Monitor 之间的数据也通过Paxos协议确保一致性。

（2）OSD（Object Storage Device）：管理物理存储介质，提供了的数据存储、数据恢复等基本功能。通常情况下一个物理磁盘对应一个OSD 进程，或者一个分区对应一个OSD 进程。Rados 层的对象通过将对象Key做Hash 运算再取模的方式，分布到逻辑结构PG 之中，PG 再次通过CRUSH 算法[1]，被分布到实际的OSD中。OSD 可选择配置两种不同类型的存储后端，即Filestore 以及Bluestore。Filestore 将数据以文件的形式存储于文件系统中；Bluestore 直接接管块设备，上层业务对数据的访问不会经过文件系统等中间层。

Ceph 通过Rados 层实现分布式系统的核心功能，并通过librados 扩展外部应用的方式实现了底层存储引擎与Clients 之间的解耦。同时，在Clients 层相关应用的设计也支持分布式的高可用部署模式。

2 高可用的RadosGW部署架构

在部署RadosGW 集群的时，高可用性是集群架构设计中需要着重考虑的因素，即当物理主机发生节点故障后，是否会影响整个服务的可用性。同时，也需要充分考虑集群节点维护是否会对服务的可用性产生影响。针对Ceph 集群的特点，图2 提出一种典型的RadosGW 集群部署架构。

图2 RadosGW集群部署架构

Rados 层，从数据可用性角度来看，Rados 实现了对象的分布式存储以及数据冗余，通过合理的设置冗余规则，可以做到在OSD 主机或存储介质损坏时，集群能通过冗余副本对对象数据进行恢复保证了数据的可用性；由于Monitor 采用Paxos 一致性协议[2]，为了保证算法正常工作，需要保证Monitor 数量为基数，3 台Monitor 既保证Monitor 的高可用性，也满足Paxos 协议的要求。同时从节约成本的角度考虑，Monitor 实例可以和OSD 实例在同一台主机上混合部署；其余的OSD主机，根据规划容量进行部署，集群需要扩容时，可动态增加OSD 主机数量，满足横向扩展的要求。

Clients 层，采用了两个RadosGW 实例，两个实例之间采用主备模式，通过Keepalived[3]保持两个实例之间的心跳检测。客户端通过VIP 访问RESTful 接口，当主节点故障时，备节点会主动接管主节点的VIP，从而将客户请求引导至备节点，从而避免RadosGW 实例产生单点故障，保证了集群的高可用性。

3 异构存储环境下的优化

对于存储系统而言，更换性能更高的存储介质，可以带来显著的效果提升。传统的HDD 驱动器因其机械结构的限制，在随机小I/O 的场景下性能低下，即使在顺序I/O 的场景下，与SSD 驱动器相比也有数倍的差距。近年来SSD 驱动器发展迅速，但是“容量价格比”仍远高于传统HDD 驱动器。因此完全采用SSD 驱动器会使存储系统的成本显著的增加。异构存储的方案，通过分析RadosGW 数据的存储结构，可以根据不同数据的类型，灵活安排各类数据的存储介质进行分层存储，使整个存储系统在性能和价格之间找到平衡点。

3.1 RadosGW数据类型与存储方式

（1）Rados 对象

Rados 的每一个对象包含3 种类型的数据。分别为xattrs、omap 以及data，其中：

①xattrs：对象扩展属性，在Rados 采用Filestore 后端时，存储于文件系统扩展属性中；在采用Bluestore 后端时，以Key-value 的形式存储于Kv 数据库中（Rocks-DB 或LevelDB）。

②omap：与对象扩展属性相似，但无论采用何种后端，均存储于Kv 数据库中。

③data：对象的数据，在采用Filestore 后端时，data部分以文件的形式存储于文件系统当中；在采用Bluestore 后端时，直接存储在物理介质上。

（2）RadosGW 对象

为了避免访问产生热点，并增加对象并行读写效率，RadosGW 会将用户对象拆分为多个Rados 对象后再存入Rados 集群中。如图3 所示，用户的对象会被拆分为一个Head Object 与不等数量的Shadow Objects进行存储。其中Head Object 中除了保存数据之外，同时再对象xattrs 中存放了对象的相关属性，如：对象大小、修改时间、acl 控制信息、manifest 等，并通过manifest 信息指向了对象的Shadow Objects。Shadow Object只在data 部分存有数据，xattrs 与omap 数据为空。

图3 RadosGW对象的存储结构

（3）存储桶索引

存储桶是用户存放对象的基本单元，RadosGW 为每一个用户的桶维护了一套索引信息，主要存放了对象的Key 以及对象的Size 信息。存储桶的索引信息，保存在存储桶对应索引对象的omap 结构中，其实质则是以Key-value 的形式存储于Kv 数据库中。为了避免写入时，多个并发请求对索引对象的对象锁争用现象从而引起热点问题，RadosGW 支持一个存储桶对应多个索引对象，单个对象的索引信息通过对对象Key进行Hash 运算后，被映射到不同的索引对象中存放。

3.2 异构环境下的数据放置策略

Bluestore 支持灵活的配置block.db、block.data、block.wal 三个分区对应的物理块设备。其中block.data分区存储Rados 对象的data 数据；block.db 分区存储Rados 对象的xattrs、omap 数据，其实质是将Key-value 数据存放于Kv 数据库中，可选择RocksDB 或者LevelDB。如图4 所示，通过对SSD 驱动器划分多个分区的方式，达到使用单块SSD 驱动器存放多个OSD 的block.db、block.wal 数据的目的，从而实现下列的优化措施。

图4 数据放置策略

（1）使用SSD 存储Key-value 数据

RadosGW 构建的对象存储系统中，相较于RBD 构建的块存储系统，一个显著的特点是存在大量的Keyvalue 键值对，如对象xattrs 数据，存储桶索引等。不同于对象data 数据大部分是连续的数据，Key-value 数据是高度离散化的，会带来大量随机I/O。在Rados 层使用Bluestore 后端存储时，这些数据实质上存储于Kv数据库，如RocksDB 中。虽然RocksDB 采用LSMTree[4]的存储结构，将众多随机写入转换成顺序写入，但是compaction 过程仍然会带来显著的I/O 开销。因此针对Key-value 数据的存储，使用SSD 驱动器较于HDD 驱动器会获得显著的性能提升。

（2）使用HDD 驱动器存储data 数据

对象的data 数据以二进制形式保存，数据是连续的，在数据写入驱动器的过程中是顺序I/O。HDD 驱动器因其机械结构的原因，在处理顺序I/O 的时寻道时延较处理随机I/O 时大大减小，顺序I/O 的处理效率远高于随机I/O 的效率。同时，对象的data 数据的数据量远远高于xattrs 数据与omap 数据的数据量，采用SSD 驱动器存储data 数据，在成本上不具有优势，所以对象data 数据适合采用HDD 驱动器存储。

（3）使用SSD 存储Bluestore 的WAL 数据

在数据落盘的整个流程中，会经历数据落盘、更新索引信息等多个阶段。在整个写入过程中如果因为磁盘故障、主机宕机等不可预期事件的发生，导致写入流程没有经历完所有阶段即被打断，则会造成磁盘脏数据的产生。Bluestore 后端在写入数据时将写入操作封装成完整事物预先写入到WAL 中，在进行落盘操作有故障发生时，可以通过重放WAL 达到恢复的目的，保证了数据写入的原子性。WAL 数据量较小，可以通过将WAL 数据存储于SSD 驱动器的方式来加速Bluestore 的写入过程。

4 结语

基于Ceph RadosGW 的对象存储系统，因其高性能、高可靠性以及高可扩展性的特点，适用于企业私有云环境对象存储系统的构建。针对Ceph 集群本身的特点，合理设计集群物理架构，可以消除单点故障实现服务的高可用性，减少故障时间；采用异构存储架构并合理配置不同类型数据的存储介质，能够在可控的成本范围内，提升集群性能，满足企业日常应用的需求。