本来不想再写Ceph相关的文章了，最近在做ceph元数据优化研究及架构，整体思路是：将rados作为数据存储引擎，构建分布式元数据集群来管理元数据，如：将rgw或者fs相关的元数据从ceph的元数据池中抽取出来，转存到分布式元数据集群中，以此达到提升单集群处理能力的目的；要达到这个目的，有两个基础条件：1.对ceph中rgw或者fs的各CURD操作原理及IO路径非常熟悉，2.对ceph中元数据的组织及存储非常熟悉；然后才能在rgw或者mds的IO路径中进行数据及元数据的分离操作，并以合适的格式将元数据转存到分布式元数据集群中。
这是第三篇也是最后一篇关于rgw中存储结构分析的文章：.rgw.root 和 {zone}.rgw.log池中对象结构的分析
下文的操作在最新的Nautilus版本环境下进行
root池
root池默认的名字为.rgw.root，通常也不建议修改，这池用来存储realm，period，zonegroup，zone的信息，各元素的记录模式类似，包括：一个对象记录名字到id的映射，一个对象记录元素的信息，一个对象记录当前的默认值，相关的结构定义在rgw_zone.h文件中；下面是一个示例：
1）先来看realm：它维护了一个全局命名空间，对象realms_names.{realm_name}记录了名字到id的映射，对象realms.{realm_id}记录了realm的元数据，对应结构RGWRealm，对象default.realm记录了默认realm的id， realms.{realm_id}.control记录notify通知。
2）period：表示realm的某一次变更，periods.{period_id}.latest_epoch对象记录最新的epoch号，period_config.{realm_id}对象记录config信息， periods.{period_id}.{epoch}对象代表一次历史变更记录，包含该次变更的相信内容，对应结构RGWPeriod，通过radosgw-admin period get --period={period_id}拿到的就是该信息（与rados get -p .rgw.root periods.a0904d8d-d546-468d-a796-a8c91287d3c7.1 period.txt && ceph-dencode import period.txt type RGWPeriod decode dump_json获取的信息一致）。注：如果在master zone执行radosgw-admin period update --commit会生成新的period，在slave zone上更新则只会在原period基础上更新epoch，如果更新了zone信息，而没有commit，就会存在一个对象periods.{period_id}.staging， 这个变更并不会生效。
3）zonegroup：可以理解为区域（region），提供区域内的统一命名空间，对象zonegroups_names.{group_name}记录名字到id的映射，在zonegroup_info.{group_id}记录zonegroup的信息，对应结构RGWZoneGroup，通过radosgw-admin zonegroup get --rgw_zonegroup={name}拿到的就是该信息（与rados get -p .rgw.root zonegroup_info.95b0684a-c426-4ba8-a58b-d5f0a407d452 zonegroup.txt && ceph-dencode import zonegroup.txt type RGWZoneGroup decode dump_json获取的信息一致）， default.zonegroup.{realm_id}记录默认的zonegroup id。
4）zone：理解为可用区（AZ），通常是一个数据中心或者集群，与zonegroup类似，也包含三个对象，对象zone_names.{name}记录名字到id的映射，在zone_info.{id}记录zone的参数信息，对应结构RGWZoneParams，通过radosgw-admin zone get --rgw_zone={name}拿到的就是该信息（与rados get -p .rgw.root zone_info.0761b956-1ec4-405c-b84e-9a4805f7f6a2 zone.txt && ceph-dencode import zone.txt type RGWZoneParams decode dump_json获取的信息一致）， default.zone.{realm_id}记录默认的zone id。
log池
{zone}.rgw.log池用来存放与gc，lc，reshard以及sync相关的log信息，下面是一个示例：
1）lc：生命周期管理，开启bucket的生命周期功能后，bucket会以omap 的形式写入log 池的命名空间为 lc 的对象中，根据配置会生成多个lc.{id}对象，对象个数由参数rgw_lc_max_objs决定，根据bucket hash取模分配对象。示例中设置了32个对象。
lc.13对象中有一个bucket，omap的header中记录了当前lc进度的marker。
2) gc: 垃圾回收，对象个数由参数rgw_gc_max_objs决定，示例中设置了32个对象，这个参数也定义了gc的并发数，每个gc对象的omap包含了要清理的对象，在等待了rgw gc obj min wait时间后，对象会彻底的从存储池被删除，并更新gc对象。
control池
其实还有一个control池，{zone}.rgw.control，用来存储bucket notify相关的消息，这个特性还没有实践过，就不班门弄斧了。
结尾：通过三篇文章，抛砖引玉，简单分析了rgw中的元数据组织及存储结构（主要分析了user，bucket（instance，index），object相关的组织及存储结构，还有multisite中数据同步等没有分析到），权当给大家提供一个思路以及示例，其他的分析结合代码也就比较简单了。