ceph官网重要摘抄

rgw 动态桶分片

官网地址
Luminous 版本新增功能。

较大的存储桶索引可能会导致性能问题，这可以通过对存储桶索引进行分 片来解决。在 Luminous 之前，更改存储桶分片数量（重新分片）需要离线完成，并且禁用RGW服务。自 Luminous 版本以来，Ceph 已支持在线存储桶重新分片。

每个存储桶索引分片都可以高效处理其条目，直到达到某个阈值。如果超过此阈值，系统可能会出现性能问题。动态 重新分片功能会检测到这种情况，并自动增加存储桶索引使用的分片数量，从而减少每个分片中的条目数量。此过程对用户是透明的。在重新分片过程中，对目标存储桶的写入会被短暂阻止（但读取不会）。

默认情况下，动态 存储桶索引重新分片只能将存储桶索引分片的数量增加到 1999，尽管此上限是一个配置参数（请参阅下面的配置）。如果可能，该过程会选择质数分片，以便更均匀地将条目数量分布在存储桶索引分片中。

重新分片机会检测以后台进程的形式运行，该进程会定期扫描所有bucket。需要重新分片的 bucket 会被添加到队列中。一个线程在后台运行，按顺序逐个处理排队的重新分片任务。

rgw 动态分片的相关配置
rgw_dynamic_resharding
rgw_max_objs_per_shard
rgw_max_dynamic_shards
rgw_reshard_bucket_lock_duration
rgw_reshard_thread_interval
rgw_reshard_num_logs

博客 Luminous 中的新功能：RGW 动态桶分片

MANUAL IMMEDIATE BUCKET RESHARDING

radosgw-admin bucket reshard --bucket <bucket_name> --num-shards <new number of shards>

在选择分片数量时，管理员必须预测每个存储桶的峰值对象数量。理想情况下，每个分片在任何时候都不应超过100000 个条目。

此外，存储桶索引分片为质数时，其均匀分布存储桶索引条目的效果更佳。例如，7001 个存储桶索引分片优于 7000 个，因为前者为质数。许多网站都有质数列表；使用您最喜欢的搜索引擎搜索“质数列表”即可找到一些网站。

ceph osd blocklist 原因

官网地址

A capability grants the client the ability to cache and possibly manipulate some portion of the data or metadata associated with the inode. When another client needs access to the same information, the MDS will revoke the capability and the client will eventually return it, along with an updated version of the inode’s metadata (in the event that it made changes to it while it held the capability).

Clients can request capabilities and will generally get them, but when there is competing access or memory pressure on the MDS, they may be revoked. When a capability is revoked, the client is responsible for returning it as soon as it is able. Clients that fail to do so in a timely fashion may end up blocklisted and unable to communicate with the cluster.

功能授予客户端缓存和可能操纵与 inode 关联的部分数据或元数据的能力。当另一个客户端需要访问相同信息时，MDS 将撤销该功能，客户端最终将返回该功能以及 inode 元数据的更新版本（如果它在拥有该功能期间对其进行了更改）。

客户端可以请求功能，并且通常会获得这些功能，但是当 MDS 上存在竞争访问或内存压力时，这些功能可能会被 撤销。当功能被撤销时，客户端有责任尽快归还该功能。未能及时归还该功能的客户端最终可能会被列入黑名单，并且无法与集群通信。

动态子树分区

官网地址
在传统的子树分区中，文件系统层次结构的子树被分配给各个 MDS。此元数据分布策略提供了良好的层次局部性、缓存的线性增长和跨 MDS 的水平扩展，以及跨 MDS 的元数据的相当好的分布。

传统子树分区的问题是，工作负载深度增长（跨单个 MDS）会导致活动热点。这会导致缺乏垂直扩展和浪费不繁忙的资源/MDS。

这导致采用一种更加动态的元数据处理方式：动态子树分区，其中来自繁忙 MDS 的目录层次结构的负载密集部分被迁移到非繁忙 MDS。

该策略可确保活动热点在出现时得到缓解，因此除了水平扩展之外，还可以实现元数据工作负载的垂直扩展。

动态子树分区
CephFS 长期以来一直有一个动态元数据平衡器（有时称为“默认平衡器”），它可以拆分或合并子树，同时将它们放在“较冷”的 MDS 等级上。移动元数据可以提高整体文件系统吞吐量和缓存大小。

但是，平衡器存在效率和性能问题，因此默认情况下处于关闭状态。这是为了避免管理员通过增加设置“打开多 mds” max_mds，然后发现平衡器已经搞乱了集群性能（恢复很简单，但可能需要一些时间）。

打开平衡器的设置是：

ceph fs set <fs_name> balance_automate true # 这是 reef (18)版本才有的设置选项，低版本关闭动态子树分区使用 mds_bal_interval 选项
低版本设置示例如下

ceph config set mds.myfs-a mds_bal_interval 0
ceph config set mds.myfs-b mds_bal_interval 0

仅应通过适当的配置（例如设置bal_rank_mask（如下所述））来打开平衡器。建议仔细监控文件系统性能和 MDS。