Luminous 中的新增功能：RGW 动态存储桶分片

Luminous 引入了一个新的 RGW 功能，可以自动管理 RGW 桶索引对象的分片。这完全自动化了 RGW 内部索引对象的管理，在此之前，Ceph 管理员必须密切关注这一点，以防止拥有非常大的桶的用户导致性能和可靠性问题。

背景 ¶

当我们处理 Ceph 功能时，最重要的设计要求之一是所有内容都应该能够扩展。Ceph 从一开始就构建为允许水平扩展，并且我们添加的每个功能都需要符合此属性。这种理念被用于设计所有内部 Ceph 组件（mon、osd、mds、rgw 等）：当资源耗尽时，应该始终能够添加更多硬件，以便可以生成新的守护进程，从而提高整个集群的性能。

RADOS（Ceph 的底层对象存储）的一个特性是它不会为系统中的所有对象保留索引。相反，它利用 CRUSH 算法根据其名称、集群配置和集群状态来计算任何对象的位置。这是一个可扩展性促进器：整体 IO 容量可以随着系统中 OSD 的数量而扩展，因为不需要任何元数据服务器或查找来用于这些 IO 操作。RADOS 网关 (RGW) 在 RADOS 之上提供了一个与 S3 兼容的对象存储服务，利用了此属性，实际上，访问 RGW 对象时，无需触及任何索引。

但是，RGW 仍然为每个桶维护一个索引，其中包含它所包含的所有对象的列表和元数据。这是必需的，因为 RGW 需要能够在请求时提供此数据（例如，在列出 RGW 桶内容时），并且 RADOS 本身不提供有效的列出功能。此桶索引还用于其他任务，例如维护版本化操作的日志、桶配额元数据以及多区域同步的日志。桶索引不会影响对象读取操作，但它会增加写入和修改 RGW 对象时的额外操作。

这意味着有两个方面。首先，单个桶索引对象可以存储的数据量有限。我们用于桶索引的 RADOS 对象键值接口不是无限的，并且默认情况下每个桶仅使用一个 RADOS 索引对象。非常大的索引对象可能导致性能和可靠性问题，在极端情况下，甚至可能由于缓慢的恢复操作而导致 OSD 崩溃。第二个问题是它最终成为一个性能瓶颈，因为对桶的所有写入最终都会修改和序列化单个 RADOS 对象。

Hammer 引入了一个桶分片功能来处理大型桶。每个桶索引现在都可以跨多个 RADOS 对象展开，从而允许桶可以容纳的对象数量随着索引对象（分片）的数量而扩展。但是，这仅适用于新创建的桶，并且需要提前计划和预知最终的桶容量。我们添加了一个桶重分片管理员命令（最初在 Kraken 中，但回移植到 Jewel 和 Hammer），该命令允许修改桶索引分片的数量，以缓解此问题。但是，重分片通常是在事后完成的，当桶索引已经显示出有问题症状时（或者以其他方式引起了管理员的注意），并且它需要在重分片过程中使桶的写入静止（这并不总是方便或可能的）。

动态桶重分片 ¶

Luminous 最终引入了动态桶重分片功能。桶索引现在将随着桶中对象数量的增长自动重分片。此外，无需停止对桶进行的 IO 操作（尽管重分片进行中时，某些并发操作可能会遇到额外的延迟）。radosgw 进程会自动识别需要重分片的桶（如果每个分片的对象数量太大），并为这些桶安排重分片。一个特殊线程负责处理计划的重分片操作。

配置 ¶

该功能默认启用；无需采取任何操作，管理员不再需要担心此实现细节。

可以通过将“rgw dynamic resharding”设置为“false”（默认值为 true）来禁用重分片。可以使用“rgw max objs per shard”（默认值为 100k）来控制每个分片的对象数量。重分片线程周期可以通过“rgw reshard thread interval”选项进行配置（默认值为 10 分钟）。

有一些新的 *radosgw-admin* 命令可用于监视和控制正在进行的重分片

• 手动安排桶的重分片

$ radosgw-admin reshard add --bucket=--num-shards=<num_shards>

• 列出计划的桶重分片

$ radosgw-admin reshard list

• 手动处理计划的重分片

$ radosgw-admin reshard process

• 取消计划的重分片

$ radosgw-admin reshard cancel --bucket=

结论 ¶

索引的内部分片不是用户应该担心的事情，现在终于如此了，RGW 在 Luminous 中也是如此。这项功能是正在进行的多项努力之一，旨在提高 Ceph 的简单性、易用性和自动化管理。