RGW 数据组织方式

基础概念

object/part/

一个 RGW Object 由 N 个 part 组成,每个 part 由 M 个 strip 组成。对于简单上传,我们认为 N 为 1, part number 为 0。对于分块上传,我们认为每块就是一个 part,part number 也是相对应的 1~N。

对于一个 part,会分为 M 个 strip,每个 strip 对应于一个 rados obj。第一个 strip 称之为 HEAD obj,其他 M-1 个strip 称之为 TAIL obj。一般情况下,对象的一些元数据都会保存在 HEAD 对象的 attr/omap 中。

如何从一个对象名找到该对象所有的 part 和 strip 呢? RGW 通过 manifest 类来实现,manifest 会描述对象每个区间的数据分别由什么对象存储。在用户读取对象 foo 的时候,RGW 直接定位到同名的 HEAD obj(名字为 <bucket_id>_<obj_id>),并读取该对象的 attr,拿到 manifest 数据。通过 manifest 可以得到文件由哪些 strip 组成,并分别去读取这些 strip obj,返回给用户。

atomic upload

atomic upload 是在一次请求内完成的上传操作,属于实现比较清晰的。对于 atomic upload 的对象看成 part 为1,part number 为 0 的情况。在实际的数据存储层(RADOS)上,会有一个名字为 <bucket_id>_<obj_name> 的 head 对象,以及若干个在 shadow namespace 下的 tail 对象,名字为 <bucket_id>.1__shadow_.<prefix_id>_<strip_num>,如
9b60b3ba-81d5-4319-9092-a7b1921a3491.4240.1__shadow_.09YONY-GM_tn2FiW3e92YOHQ7qX-fE9_.1_1。该对象所有的元数据都存储在 head obj 的 attr 中,包括 manifest 信息。

multipart upload

multipart upload 是经过 InitMultipart, N*UploadPart, CompleteMultipart 多个请求来完成的上传操作,比较复杂。与 atomic upload 不同的是,multipart upload 额外使用了一个 extra pool 来存储关于本次上传的分块信息, rgw_obj(bucket, oid+upload_id+”meta”) 对象会在 omap 中存储每个分块对应的 RGWUploadPartInfo 信息,RGWUploadPartInfo 中包含了每个分块的 manifest。在最终 CompleteMultipart 时,合并 mp meta obj 上所有分块的 manifest 数据,存储到 head obj 的 attr 中,并删除 mp meta obj。

因为,对于一个 multipart upload 的对象,会有一个同名的 head obj,每个 part 会有若干个对象组成,这些对象中第一个位于 multi namespace,其它位于 shadow namespace。