RADOS是一个基于对象的存储系统（这里的对象是指RADOS内部的一种数据存储单元，与对象存储中的对象概念有所区别）

通常情况下应用通过RAODS抽象库librados提供的对象接口访问RADOS集群，但是librados只提供私有接口，并不支持HTTP协议访问。Ceph为了支持通用的HTTP接口设计了RGW（RADOS GateWay，即对象存储网关）系统。然后，如果RGW只提供通用的HTTP访问接口，应用需要花费较大的代价才能开发出适配RGW访问接口的软件，这不利于Ceph在云存储领域中迅速普及，因此RGW选择适配云存储领域中最广泛的Amazon S3和OpenStack Swift接口，使得现有的S3和Swift用户可以以较小的代价接入到Ceph提供的对象存储系统中。

RGW实际上是Ceph专门为对象存储应用提供RESTful接口访问RADOS集群的一个访问通道，同时为了方便应用使用，其提供的RESTful接口兼容目前在云存储领域中应用的最广泛的Amazon S3系统和OpenStack Swift系统所提供的对象访问接口。

用户指的是对象存储的使用者，一个用户可以拥有一个或者多个存储桶。 一个用户对应一个RADOS对象。

用户管理设计主要基于以下几个方面考虑：

因此，一个用户包含的信息包括用户认证信息，访问控制权限信息和配额信息。

用户认证信息

S3用户身份认证机制都是基于密钥认证的。认证过程如下：

发送请求前，使用用户私有密钥(secret_key)，请求内容等，采用与RGW网关约定好的算法计算出数字签名后，将数字签名以及用户访问密钥(access_key)封装在请求中发送给RGW网关 RGW网关收到请求后，使用用户访问密钥作为索引从RADOS集群中读取用户信息，并从用户信息中获取用户私有密钥 使用用户私有密钥，请求内容等，采用与应用约定好的算法计算数字签名 判断RGW生成的数字签名和请求的前面是否匹配，匹配则用户通过验证

访问控制权限信息

配额信息

下表为RGWUserInfo数据结构

RGW将用户信息把保存在RADOS对象的数据部分，一个用户对应一个RADOS对象。由于大部分情况下我们需要使用用户ID作为索引获取用户信息，因此该对象以用户ID命名（RADOS通过‘‘pool名+对象’’来查询一个对象，后面解释pool）。

RGW需要将访问密钥，子用户，email和用户信息所在的RADOS对象建立索引关系，针对这种情况，RGW采用了二级索引的实现方式。即分别创建以用户访问密钥、子用户、email命名的三个RADOS对象（以下称索引对象），并且将用户ID保存在对象的数据部分。从而当需要使用某个索引查询用户信息时，首先从索引对象读出用户ID，然后使用用户ID作为索引读取用户信息。

存储桶是对象的容器。一个存储桶对应一个RADOS对象。

一个存储桶包含的信息分为两类：

下表为RGWBucketInfo关键字段

创建存储桶时，RGW网关会同步创建一个或多个索引对象，用于保存改存储桶下的对象列表，以支持查询存储桶对象列表(List Bucket)功能，因此在存储桶中有新的对象上传或者删除时必须更新索引对象。

RGW采用了Ceph通常采用的解决方案，将索引对象分片(shard)，把一个索引对象切分成多个对象，不同应用对象记录在不同的索引对象上。

这个方案极大的改观了对象的写性能，但是分片后带来的一个负面影响，会影响查询桶对象列表操作的性能。分片后原先只需要读一个索引对象就可以获取存储桶下对象列表变成了针对多个索引对象的读，这时，RGW网关与RADOS集群间的网络延时，多个索引对象查询结果的合并对查询存储桶对象列表性能产生很大的影响。

为了降低这个负面影响，RGW视图对多个索引对象并发读取代串行读，以降低查询存储桶对象列表操作的处理时间。但事物都有两面性，如果一味的增加索引对象的数目，与此同时归并排序所消耗的计算量和缓存也会增加，从而也制约了查询效率。

对象是对象存储系统数据组织和存储的基本单位，一个对象包含数据和元数据。数据指的是用户保存的真正的数据，比如一个文本文件的内容或者一个视频文件的内容；元数据指的是除了数据外的其他需要保存的信息，一般由KV键值对组成。（类似于创建桶时的两类信息）

与文件系统层级管理结构不同，对象存储系统中所有对象都以扁平方式存储，对象之间没有直接关联，这种特性很容易实现将不同的对象保存在不同的物理位置。此外，对象存储不提供编辑对象部分内容的功能，对象必须作为一个整体单元操作，即使只更新对象中的一个字符，也必须将整个对象从云端下载下来，更新后上传。

应用上传的对象包括数据和元数据两部分，数据部分保存在一个或者多个RADOS对象的数据部分，元素据保存在其中一个RADOS对象的扩展属性中。（为什么是一个或多个呢？因为前面提到的分片）

RGW对于单个对象提供了两种上传接口：整体上传和分段上传

整体上传：

RGW限制了整体上传一个对象器大小不能大于5GB，当用户上传的对象大于该限制时必须分段上传，否则上传对象失败。为了更好理解用户上传对象和RADOS对象的对应关系，先了解两个值和一个类：

rgw_max_chunk_size：该宏值用来表示RGW下发到RADOS集群单个I/O的大小，同时决定应用对象分成多个RADOS对象时首对象的大小，以下简称分块大小

rgw_obj_stripe_size：公司宏值用来指定当一个对象被分成多个RADOS对象时中间对象的大小，以下简称条带大小

Class RGWWObjManifest：用来管理用户上传的对象和RADOS对象的对应关系，以下简称manifest

整体上传时，

分段上传：

分段上传对象时，RGW网关按照条带大小将每个分段分成多个RADOS对象。当所有的分段上传结束以后，RGW会另外生成一个RADOS对象，用于保存应用对象元数据和所有分段的manifest。

前面分析了RGW数据的组织和存储方式，不同的用户数据最终以RADOS对象为单位保存到了RADOS集群中。为了实现不同的应用数据存储位置的隔离，RGW使用zone来管理用户数据的存储位置，zone由一组存储池(pool)组成，不同存储池用来保存不同的数据，RGW使用数据结构RGWZoneParams来管理不同的存储池。因此配置一个RGW实例时，需要指定该RGW实例所属的zone以及确定数据的存储位置。

下表为RGWZoneParams关键字段

需要重点强调的是placement_pools字段。该字段由map组成，string是一个自定义字符串，可以认为是一个对象存储策略，用来唯一定位第二个字段RGWZonePlacementInfo。第二个字段主要定义应用对象的存储位置、用户分段上传对象时的中间数据的存储位置和存储索引对象的存储位置等。当创建一个存储桶时，用户可以显式指定zone中已存在的存储策略，后续往存储桶中上传对象时，将按照该存储策略存储对象。

下表为RGWZonePlacementInfo关键字段