Ceph对象存储，.rgw.root池中，存储了与multisite特性相关的realm配置，包括realm、zonegroup、zone、period等信息，这里不探讨这些配置的业务意义，只是分析一下配置的组织管理方式。

       通过rados -p .rgw.root ls命令可以列举出所有相关rados对象。可以看到realm、zonegroup、zone信息组织方式基本是统一的，

realms.<id>.control 该对象用于watch-notify，当该realm发生变化后，commit时会交通知类型写入该对象，rgw网关之前已经watch了该对象，就会触发其notify流程进行相应的处理，如配置重新加载等。

realms_names.<realm-name> 用于存储该realm name对应的realm id

realms.<realm-id> 用于存储该realm id对应的realm info

default.realm 用于存储默认的realm id

zonegroups_names.<zonegroup-name> 用于存储该zonegroup name对应的zonegroup id

zonegroup_info.<zonegroup-id> 用于存储该zonegroup id对应的zonegroup info

default.zonegroup.<realm-id> 用于存储默认zonegroup id

zone_names.<zone-name> 用于存储该zone name对应的zone id

zone_info.<zone-id> 用于存储该zone id对应的zone info

default.zone.<realm-id> 用于存储默认zone id

period_config.<realm-id> 存储该realm使用的quota信息

periods.<period-id>.<epoch> 存储特定period-id和epoch确定的period info

periods.<period-id>.latest_epoch 存储特定period-id下最新的epoch

periods.<realm-id>:staging 特定realm下生成的period，但是还没有commit

       一般来讲realm创建后很少修改，主要修改zonegroup和zone配置，通过radosgw-admin命令修改zonegroup和zone信息后，会直接持久化到对应的rados对象，但是realm中记录的是当前使用的period id，也就是说realm不直接与zonegroup关联，而是与period关联，只修改zonegroup不生成或者更新period是无法生效的。执行radosgw-admin period update --commit，会生成一个新的periods.<period-id>.<epoch>，并更新periods.<period-id>.latest_epoch，然后通知网关进行配置加载，配置即可生效。这里需要注意的是，修改zone配置后，也是通过以上命令通知网关进行配置加载的，但是即使不通过以上命令生成新的period并通知网关，也可以重启网关使得zone配置生效。period中只包含了zonegroup信息，不包含zone详细信息。这可能是因为zone只需要本地生效，而zonegroup是多个集群共用的。