3.2.2     RGW架构

对象存储 S3为 AWS早在 2006年推出的 IaaS服务，如今对象存储已经成为整个互联网行业非结构化数据存储的底座。Ceph中的 RGW服务实现了对AWSS3接口的兼容，CephRGW经过 10余年的发展，如今已经成为对AWSS3 特性兼容最全面的开源实现。任何对对象存储实现感兴趣的人都能从了解 CephRGW中受益。

RGW最初叫 s3gw，由 YehudaSadeh 主导设计，在 Ceph代码 git 仓库中可以追溯到的最早涉及 s3gw的提交时间为 2009 年。遵从社区所追求的通用设计理念，s3gw更名为RGW，后续也实现了对 OpenStackSwift协议的兼容。

1.  实现架构

 

Ceph本身采用分层的架构，RAODS层中的 OSD 进程负责切片后对象数据和元数据的持久化存储，作为 RADOS层客户端存在的RGW 进程负责处理对象存储的业务逻辑。

本章节只分析 RGW单个组件的架构，不再赘述 Ceph 存储系统的整体架构。

对象存储作为对外提供HTTP（s）协议接入的服务，其逻辑有明显的分层架构设计思路。按照 HTTP（s）请求处理阶段，涉及的层有以下几个。

（1） 负责解析和验证 HTTP（s）请求的协议解析层。

（2）负责对解析后的对象存储业务请求进行处理的业务逻辑层。

（3）负责对对象存储数据和元数据进行持久化存取的数据持久化层。接下来逐层看看细节。

2.  协议解析层

 

协议解析层本质上就是 HTTP服务器的实现，RGW提供了灵活的插件式 HTTP服务器实现，具备以下特性。

◆  最早实现的兼容 FCGI协议的 FCGIHTTP 服务器前端。

◆  基于 C++HTTP服务端库 civetweb 实现的服务器前端。

◆ 基于 C++boostHTTP 标准库 beast 实现的服务器前端，也是默认配置使用的 HTTP服务器。

协议解析层的主要工作内容就是解析对象存储的 HTTP请求。对于请求认证需求，

RGW提供了以插件化方式实现的 AWSS3v2/v4类型认证以及通过外部 Keystone/LDAP组件进行认证两种方法。

在解析HTTP协议时，协议解析层会处理Swift和S3两种不同的对象存储“方言”，最终将HTTP请求统一抽象成对象存储的Op（operation）。

3.  业务逻辑层

 

业务逻辑层负责对象存储Op的处理，RGW为 Op定义了统一的处理“工序”。

（1） init_processing：初始化；

（2） verify_op_mask：验证请求的读写掩码；

（3） verify_permission：验证请求的权限；

（4） verify_params：验证请求参数；

（5） pre_exec：执行请求的预处理；

（6） execute：处理请求；

（7） complete：执行请求完成后的后续处理。

对象存储的业务复杂性导致每个   Op   在处理中都涉及如配额检查、权限控制、权限策略检查等业务逻辑的处理，在 RGW中定义了Service 组件来提供对象存储语义的调用接口。

对于需要多个 Service 组合构造的更复杂的对象存储语义，RGW提供了 Control这样的构造。

我们通过一个具体的例子来理解 RGW 业务逻辑模块化而引入的强大抽象：Service组件和 Control组件。

对于创建 User的 Bucket来说，涉及 User和 Bucket两个概念，对于 User的操作抽象成单独的UserService，Bucket的操作抽象成单独的 BucketService。两个Service不需要知道彼此的存在，因此抽象出 Control 来提供更高层级的 API，Control组件内部再调用 Service提供的服务接口。

每个 Service都有一个关联的 backendtype，目前支持SOBJ、OTP类型，不同类型的 backendtype意味着不同的数据持久化方式。当前 RGW 需要的数据和元数据存储都是基于 RADOS实现持久化的，后续持久化数据还可以保存到类似MySQL这样的关系型数据库当中。

在没有引入 Service之前，在 RGW 中开发需要操作对象或者桶的特定功能时，通常是直接操作用来保存特定功能信息的RAODS对象（用户数据切片后的对象，也就是所谓的system-object，区别于用户可见的业务层面文件数据rgw-object）。在引入Service之后，意味着通过为 Service实现新的 backendtype存储类型，CephRGW可以发展为和Minio一样的项目，即成为一个与 CephRADOS 无关的独立对象存储网关，社区目前正在推进的 RGW 持久化后端存储插件化的改造（也就是 zipper计划），正是为推动 RGW发展，实现这一目标而开展的。

4.  数据持久化层

 

前文多次提到了 RADOS，RADOS 提供的数据存储接口是对象形式的。从用户的角度来讲，直接用 librados就能使用“对象存储”。其实 RGW中的“对象”和 RADOS中的“对象”是两个概念。

首先来看对象存储服务，也就是 AWSS3标准中的对象，它在 RGW中简称 rgw-object，它的特点如下。

◆  rgw-object 可以非常大，比如单个 rgw-object 文件大小可以高达 5TB。

◆  rgw-object 是不可变的，即一旦写入，不可修改。

◆  对同一桶中的 rgw-object，Ceph 维护了有序的索引。

◆  rgw-object 在权限控制上支持丰富的语义，如存储桶策略、ACL等。

◆  rgw-object通过 HTTP 协议访问。

而 CephRADOS 层的对象，简称 Object，它的特点如下。

◆  有限的大小，比如默认配置下，其大小通常为 4MB。

◆  Object 是可变的，即写入后，允许修改。

◆  RADOS不单独为 Object 维护有序索引。

◆  不支持 Object 级别的 ACL 控制。

◆  Object通过 socket 协议访问。

对比之后会发现，RGW提供的rgw-object要比RADOS提供的Object的语义更加丰富。

RADOS提供了非常清晰的访问接口， 对外暴露Pool和 Object， 以及 Object的OMAP和 xattr。建立在 RADOS 之上的应用都要确定一个所谓的数据布局的问题，对于RGW来说，就是如何将 rgw-object映射到 RADOS集群特定 Pool的特定 Object。这部分关键的元数据被称为 manifest。

总结一下，RGW在逻辑上需要持久化的数据分 3类。

（1） Metadata，表示系统或者桶、对象的元数据，按照 ObjectOMAP的形式保存。

（2） bucketindex，保存存储桶中对象的列表，按照 ObjectOMAP的形式保存。

（3） data，保存 rgw-object的实际数据，按照 Object数据的形式保存。

其中 Metadata 以单独的存储池进行存储，按照功能类别，Metadata一部分是业务逻辑层中的Service组件和 Control 组件使用，另一部分则是保存系统运行需要的各类日志信息。这些存储池的名字空间如下。

◆  业务逻辑类：

.rgw.meta:root、.rgw.meta:heap、.rgw.meta:users.keys、.rgw.meta:users.email、.rgw.meta:users.swift、.rgw.meta:users.uid、.rgw.meta:roles。

◆  日志信息类：

.rgw.log:gc、.rgw.log:lc、.rgw.log:bl、.rgw.log、.rgw.log:intent、.rgw.log:usage。