本来不想再写Ceph相关的文章了，最近在做ceph元数据优化研究及架构，整体思路是：将rados作为数据存储引擎，构建分布式元数据集群来管理元数据，如：将rgw或者fs相关的元数据从ceph的元数据池中抽取出来，转存到分布式元数据集群中，以此达到提升单集群处理能力的目的；要达到这个目的，有两个基础条件：1.对ceph中rgw或者fs的各CURD操作原理及IO路径非常熟悉，2.对ceph中元数据的组织及存储非常熟悉；然后才能在rgw或者mds的IO路径中进行数据及元数据的分离操作，并以合适的格式将元数据转存到分布式元数据集群中。
这是第二篇：本篇分析Object（data）的组织形式及其存储结构
下文的操作在最新的Nautilus版本环境下进行
数据对象分析
对象存储Object的数据存储在：{zone}.rgw.buckets.data池中。一个rgw对象包含一个或者多个rados对象，下面是几种可能的情况：
1）通过s3cmd put {file} s3://{bucket}上传的对象，如果对象小于15MB，是下面这个样子：
Header对象包含元信息，如：acl（对应结构RGWAccessControlPolicy）,manifest（对应结构RGWObjManifest）,etag等，这些新包含在扩展属性xattr中，另外Header对象本身也可以包含4MB的对象。如果上传的对象大于4MB，那么就会生成Tail对象，Header中的扩展属性manifest描述了对象的布局信息，下面是一个示例：
1.1）查看扩展属性。
1.2） 小于4MB对象的manifest：obj_size给出了对象的大小105765Bytes，head_size是head对象中包含的数据大小，prefix即是Tail对象中的{prefix}，对象小于4MB，只有一个stripe， 可以看到begin_iter / end_iter 指向同一个对象（cur_part_id, cur_stripe, stripe_size, stripe_ofs都相等），默认每个stripe的大小是4MB。
1.3）大于4MB对象的扩展属性manifest，包含一个header对象一个tail对象。
可以看到obj_size = 6867303与上面ll 看到的大小一致，begin_iter指向第一个stripe（stripe_ofs=0, cur_stripe=0，stripe_size=4194304）- head对象， end_iter指向第二个stripe（stripe_ofs=4194304, cur_stripe=1, stripe_size=2672999）- tail对象, 两者的和等于obj_size ；prefix与上面看到的shadow对象中的{prefix}一致。
2）通过s3cmd put {file} s3://{bucket}上传的对象，如果对象大于15MB，是下面这个样子：
Header对象只包含元数据，自身大小为0。可能包含多个part，每个part默认15MB，可以包含1-3个tail对象，下面是一个示例：
2.1）上传一个21MB的对象，分成两个part，第一个part包含3个tail对象，第二个part包含1个tail对象。head对象不包含数据，只有属性信息。（注：ceph使用一个独立的存储池{zone}.rgw.buckets.non-ec来存储multipart的中间结果）
2.2）head的manifest信息：rules中有两个part（从1开始编号），编号分别为1和2，start_ofs表示part的起始偏移，part_size表示part的大小，stripe_max_size表示每个stripe的（tail）的最大大小。
2.3）multipart的对象大小：可以看到part1包含3个tail，part2包含1个tail。
2.4）part和tail中包含相同的扩展属性，注意：没有manifest属性。
3）在最新的Nautilus版本中还支持Object Versioning， 在这种情况对象会新增一个version属性，关于versioning的介绍及其技术原理可以参考下面的链接：RGW_Object_Versioning，on-ceph-rgw-s3-object-versioning。下面给出对象的逻辑结构：
3.1）小于15MB对象的，versioning结构：
3.3）大于15MB对象的（multipart），versioning结构：
通过文本对object存储结构的分析，大家应该基本能够构思出rgw是如何存取object的了。下一篇再简单分析下.rgw.root和{zone}.rgw.log池中的对象。