1.4. 重新计算放置组


放置组(PG)定义将任何池数据分散到可用的 OSD 中。PG 基于给定的冗余算法构建。对于三向复制,冗余定义为使用三个不同的 OSD。对于纠删代码池,要使用的 OSD 数量由块的数量来定义。

在定义池时,放置组的数量定义了粒度率,数据将分散到所有可用 OSD 中。容量负载的比例越大,数量越好。但是,由于处理放置组在重建数据时也很重要,因此必须仔细选择前期的数量。支持计算工具可用于生成敏捷环境。

在存储集群生命周期中,池可能会超出最初预期的限制。建议使用重新计算的驱动器数量增加。每个 OSD 的放置组数量应该大约 100。当添加更多 OSD 到存储集群时,每个 OSD 的 PG 数量会随时间降低。从存储集群中最初使用 120 个驱动器,并将池的 pg_num 设置为 4000 后,每个 OSD 的 PG 中将最终达到 100 个 PG,以三个的复制因素来计算。随着时间的推移,当到 OSD 数量达到十倍时,每个 OSD 的 PG 数量只会变为十倍。因为每个 OSD 的小数量的 PG 将倾向于非均匀分布式容量,所以请考虑调整每个池的 PG。

可以在线调整放置组的数量。重新计算不是 PG 号的重新计算,还将涉及数据重新定位,这将是一个冗长的过程。但是,数据可用性将随时维护。

应避免使用非常高的 PG 数量,因为在故障 OSD 上重建所有 PG 将一次性开始。需要进行大量 IOPS 才能及时进行重建,而这可能无法使用。这会导致深度 I/O 队列和延迟导致存储集群不可用,或会导致长时间修复。

其它资源

  • 请参阅 PG 计算器,以计算给定用例的值。
  • 如需更多信息,请参阅 Red Hat Ceph Storage 策略指南中的 Erasure Code Pools 一章。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.