Ceph RGW：数据的存储及寻址

Posted 2023-03-29

参考技术A

RGW是一个对象处理网关。数据实际存储在ceph集群中。利用librados的接口，与ceph集群通信。RGW主要存储三类数据：元数据(metadata)、索引数据(bucket index)、数据(data)。这三类数据一般存储在不同的pool中，元数据也分多种元数据，存在不同的ceph pool中。

1、 Metadata
元数据信息包括：user，bucket，以及bucket.instance。其中：
user: 主要是对象存储的用户信息
bucket：主要维护bucket name与bucket instance id之间的映射信息
bucket.instance：维护了bucket instance信息

查看user的元数据如下：
radosgw-admin metadata list user:

radosgw-admin metadata get user:testid:

radosgw-admin metadata list bucket:

radosgw-admin metadata get bucket:first:

radosgw-admin metadata list bucket.instance:

radosgw-admin metadata get bucket.instance:first:bucket_id

2、Bucket Index
bucket index主要维护的是一个bucket中object的索引信息。一个bucket对应一个或多个rados object(开启bucket shards下)。维护的是一个key-val的map结构，map存放在object的omap(rocksdb)中，key对应的rgw object，val是关于rgw object的一些元数据信息，检索bucket的存放的object时，需要这些信息。omap也包含一个Header，其存放的是bucket account info，如此bucket中Object的个数，总的size等。
3、Data
rgw object内容，存放在一个或多个rados object中。rados object分为header和tail部分，header最多可以容纳512KB的数据，如果一个rgw object的大小小于512KB，那么只有header。否则剩余的数据会按照集群rados object的大小条带化分割成多个rados object。

在Pool： zone.rgw.meta利用namespace隔离多个存储空间：

对于Pool: zone.rgw.log也包含多个namespace:

当检索对象存储中的一个object时，会包含三个要素：user，bucket,object。user主要是RGW用于获取user id验证ACL；bucket及obejct用于确定object在pool中的位置。

User

user数据存储在 zone.rgw.meta:users.uid 中，如下：

包含两部分： ups3: user本身信息; ups3.buckets: 用户所属的bucket。

ups3： 用户的基本信息，及ACL/Bucekt Quota/User Quota等；对应struct RGWUserInfo， 定义于rgw_common.h。
ups3.buckets：用户所属的Buckets，key-value结构，存放于omap结构中；对应struct cls_user_bucket_entry，定义于rgw_common.h，数据操作如下：

通过uid.buckets查到用户具有哪些buckets，并且这些bucket以下基本数据。

Bucket

Bucket信息存在在 zone.rgw.meta:root 中，如下：

first： 记录了bucket与bucket_instance_id的对应关系，其对应于数据结构：struct RGWBucketEntryPoint
.bucket.meta.first:1c60b268-0a5d-4718-ad02-e4b5bce824bf.44166.4： bucket instance；寻址方式：.bucket.meta.tenant:bucket.name:bucket_id；对应结构体：struct RGWBucketInfo。
其中Bucket ACL及IAM Policy存放在bucket instance object的attr中。如下：

获取Bucket ACL及IAM Policy数据如下：

Object

Bucket Index： Bucket中包含的Object信息，都存放在一个或多个Object的 omap 中。此omap为一个key-value结构，key为object的名称，value对应 struct rgw_bucket_dir_entry : cls_rgw_types.h 。
Bucket Index Object：

如下：

在此bucket下，有一个object: ntp.conf:

检索value:

omap header记录了以下统计信息：

对象存储object的数据存放在pool: zone.rgw.buckets.data 中。object的构成及寻址分为以下两类：

一个RGW Object可以由一个或多个rados object构成。其中第一个 object 是此RGW 的 head 对象，主要包含一些元数据信息，如 manifest, ACLs, content type, ETag, and user-defined metadata 。这些metadata存放在此head 对象的xattr中。其中 manifest 描述了此rgw object在分布情况。同时，此head对象，最多可额外容纳 4MB 数据，如果RGW Object大小下于 4MB ，那么此 RGW Object就不会分片，只有此 head 对象。
如下检索：

目前bucket下有一个 ntp.conf ， <4MB 。检索其 manifest :

如上：
max_head_size： 表示head对象最大size；
head_size： 表示当前head 对象size；
prefix： 用于在rados中分片object的寻址。

RGW OBject ACL:

上传一个 >4MB 的 RGW Object，检索其 manifest 信息：

Manifest信息：

根据 manifest 检索对象：

对于一个大的RGW Object，会被切割成多个独立的RGW Object上传，称为multipart。multipar的优势是断点续传。s3接口默认切割大小为15MB。

在此，上传一个60MB大小的Object。

分成了四个部分上传，查看rados对象：

包含了三类对象， head，multipart，shadow 。

multipart 下的 manifest :

所有的object的检索是根据上述manifest信息构建object index:

在上以上的信息中，此RGW Object大小为48128000字节，分为4段，三段15MB，最后一段为920KB。同时每段存储在rados集群中的条带化大小为4MB。因此15MB大小的分段，也分为4个rados object，一个multipart首部，及3个shadow分片。920KB大小的分段只有一个multipart首部。

.rgw.root :

包含的都是zone,zonegroup,realm等信息