2.3 Ceph 的归置组
Ceph 存储系统使用的 CRUSH 算法在一致性 Hash 算法的基础上充分考虑了多副本、故障域隔离等约束，尽量减少集群在故障场景下的数据迁移量，实现这一目标的关键举措即为 PG 逻辑概念的引入。
前文提到 Ceph 可以理解为对 RADOS 对象存储系统的二次封装，Ceph 中所有的用户数据都被抽象成多个 Object，如果 Ceph 存储系统以 Object 为追踪目标，那么要追踪的单元个体数量就太多了，不仅会消耗大量的计算资源，而且在一个有数以亿计对象（EB 级存储集群）的系统中直接追踪对象的位置及其元数据信息也是完全不现实的。Ceph 引进 PG逻辑概念，将一系列的 Object 聚合到 PG 里，并将 PG 映射到一系列的 OSD 上去。系统中PG 数量远远小于 Object 数量，存储系统以 PG 为存储单元个体，直接追踪 PG 状态，比较好地处理了性能和可扩展性的界限。
PG 的引入也会增加一些系统资源开销，如 PG 逻辑的处理会直接消耗存储节点的部分CPU 和内存，增大 PG 的数量会增加存储系统 Peering 状态处理的数量。
2.3.1 PG 数量的选择
上述分析可以看出，PG 是用户数据切片（Object）与真实提供存储空间的存储介质（OSD 守护进程）之间的纽带。Ceph 存储系统需要设置较为合理的 PG 数量，过少的 PG数量会导致集群 peer 过程太慢，数据迁移效率过低；过多的 PG 数量则会增加集群存储节点的计算资源负担。PG 的数量在 Ceph 的存储池（Pool）创建时指定，通常推荐每个 OSD守护进程承载 100 个 PG 较为合适，考虑到集群数据的副本策略，对于单存储池的简单场景，可以通过如下公式进行 PG 数量确定。
Total PGs=(OSDs×100)/Replicas
在上述数据寻址计算中，可以看到要对 Hash 计算结果进行取模运算，存储池的 PG 数量建议取值为 2 的n 次方，这样可以加速数据寻址的计算过程，即对上述公式计算结果，向上或向下靠近 2 的n 次方数值进行存储池的 PG 总数选取。
对于多存储池的复杂场景，可以参考 Ceph 官方推荐的计算器。
