1同行回答
在开发 Ceph 新功能时，我们考虑的最重要的设计需求就是可扩展性。Ceph 从最开始就是支持水平扩展的，所有的新功能也必须都符合这个特性。在设计所有 Ceph 模块（包括 mon，osd，mds，rgw 等）时，我们都秉承着该哲学。当资源耗尽时，Ceph 应当允许新增资源，并提升整个集群的性能。
RADOS（Ceph 底层的对象仓库）的一个特性是不保存系统的全部对象的索引，而是使用 CRUSH 算法，通过对象的名字、集群的配置和状态来计算存储位置。这大大提高了 Ceph 的扩展性，总的 IO 能力会随着系统中 OSD 的数量增加而增加，原因是在进行 IO 操作时，不需要查询全局的元数据。
然而，RGW 还是为每个 bucket 维护了一份索引，里面保存了 bucket 中全部对象的元数据。RGW 本身并没有足够有效的遍历对象的能力，所以在处理请求时，这些索引数据非常重要，比如遍历 bucket 中全部对象时。bucket 索引信息还有其他用处，比如为版本控制的对象维护日志、bucket 配额元数据和跨区同步的日志。bucket 索引不会影响对象的读操作，但确实写和修改确实会增加一些而外的操作。
这隐含了两层意思：其一，在单个 bucket 索引对象上能存储的数据总量有限，默认情况下，每个 bucket 是只有一个索引对象的，所以每个 bucket 中能存储的对象数量就是有限的了。超大的索引对象会造成性能和可靠性的问题，极端情况下，可能因为缓慢的恢复操作，造成 OSD 进程挂掉。其二，这成了性能瓶颈，因为所有对同一 bucket 的写操作，都会对一个索引对象做修改和序列化操作。
在Hammer 版本中，新增了 bucket 分片功能来解决 bucket 中存储大量数据的问题，bucket 的索引数据可以存储在多个 RADOS 对象上了，这样 bucket 中存储对象的数量就可以随着索引数据的分片数量的增加而增加了。但这只对新建的 bucket 有效，而且需要有提前的规划，要提前知道 bucket 最终会存储多少数据。后来我们增加了 bucket 分片管理命令（最早是在 Kraken 版本里，后来移植到了 Jewel 和 Hammer），允许修改 bucket 索引分片数量来缓解这个问题。但分片还是出现问题后的补救措施，而且在分片时无法进行写操作（这可能并不方便，甚至不可行）。
动态 bucket 分片
Luminous 最终引入了动态 bucket 分片，现在随着存储对象的增加，bucket 可以自动分片了。而且，还不会影响 bucket 的 IO 操作（不过在有些并发操作会有延迟）。RADOSGW 进程会自动发现需要进行分片的 bucket，并安排进行分片。有个专门的进程来负责处理这些分片操作。
配置
这项功能是默认打开的，无需操作，管理人员不再需要考虑实现细节。
将变量 rgw dynamic resharding 设置为 false（默认为 true），关闭自动分片；每个分片可存储的对象数量由该变量控制，rgw max objs per shard，默认是十万；自动分片线程扫描的间隔可以通过 rgw reshard thread interval 选项配置，默认为十分钟。
以下是几个新命令，用于监控或控制正在进行的分片操作。
手动进行分片：
$ radosgw-admin reshard add –bucket=<bucket> –num-shards=<num_shards>
查找全部规划中的分片操作：
$ radosgw-admin reshard list
手动执行规划的分片操作：
$ radosgw-admin reshard process
取消规划中且未开始的分片操作：
$ radosgw-admin reshard cancel –bucket=<bucket>
收起