3.3. 放置组权衡
所有 OSD 中的数据持久性和数据分布调用更多的放置组，但为了节省 CPU 和内存资源，其数量应减小到满足要求的最小值。
3.3.1. 数据持久性
Ceph 可以通过防止永久丢失数据获得好处。但是，在 OSD 失败后，永久数据丢失的风险会增加，直到其数据被完全恢复为止。仍然有可能造成持久性数据丢失。以下场景描述了如何在带有三个数据副本的单个放置组中永久丢失数据：
- OSD 失败，其中包含的对象的所有副本都会丢失。对于存储在 OSD 上的放置组内的所有对象，副本的数量会从三个减少到两个。
- Ceph 通过选择新 OSD 为故障 OSD 重新创建所有对象的第三个副本，从而开始恢复故障 OSD。
- 在新 OSD 完全填充了第三个副本之前，第二个包含相同放置组副本的 OSD 会失败。然后，一些对象将只有一个存活副本。
- Ceph 还需要选择另一个 OSD，并保留复制对象来恢复所需的副本数。
- 在恢复完成前，包含同一放置组副本的第三个 OSD 会失败。如果此 OSD 仅包含对象的唯一剩余副本，则对象会永久丢失。
硬件故障不是例外，而是预计中的情况。为防止这种情况，理想的恢复过程应尽可能快。集群的大小、您的硬件配置和放置组的数量在总恢复时扮演重要角色。
小集群无法快速恢复。
在三个副本池中包含有 512 个放置组的 10 个 OSD 的集群中，OSD 将为每个放置组提供三个 OSD。每个 OSD 将最终托管 (512 * 3)/ 10 = ~150 放置组。当第一个 OSD 出现故障时，集群将同时开始恢复所有 150 个放置组。
Ceph 可能会在 9 个剩余的 OSD 之间随机存储剩余的 150 个放置组。因此，每个剩余的 OSD 可能会向所有其他 OSD 发送副本，并接收一些新的对象，因为剩余的 OSD 现在已负责分配给它们的一些 150 个放置组。
总恢复时间取决于支持池的硬件。例如，在一个 10 个 OSD 集群中，如果一个主机包含一个带有 1 TB SSD 的 OSD，且 10 GB/s 交换机连接每个 10 个主机，则恢复时间将花费 M 分钟。相反，如果主机包含两个 SATA OSD 和 1 GB/s 交换机连接五个主机，则恢复将花费更长的时间。值得注意的是，在这种大小的集群中，放置组的数量对数据持久性几乎没有影响。放置组计数可以是 128 或 8192，恢复不会较慢或更快地恢复。
但是，将同一 Ceph 集群扩展到 20 个 OSD，而不是 10 个 OSD 可能会加快恢复速度，从而显著提高数据持久性。这是因为什么？现在，每个 OSD 只会参与 75 个放置组，而不是 150 个 PG。20 个 OSD 集群仍然需要所有剩余的 19 个 OSD 执行相同副本操作，以便恢复。在 10 OSD 集群中，每个 OSD 必须复制大约 100 GB。在 20 个 OSD 集群中，每个 OSD 只需要复制 50 GB。如果网络瓶颈，恢复将快速出现两次。换句话说，当 OSD 数量增加时，恢复时间会减少。
在大型集群中，PG 数非常重要！
如果 exemplary 集群增长到 40 个 OSD，每个 OSD 只会托管 35 个放置组。如果 OSD 出现问题，恢复时间会减少，除非出现另一个瓶颈影响。但是，如果此集群增大到 200 个 OSD，每个 OSD 只会托管大约 7 个放置组。如果 OSD 崩溃，恢复将在这些放置组中的大多数 21 (7 * 3) OSD 之间发生： 恢复的时间比存在 40 个 OSD 时要比存在 40 个 OSD 所需的时间要长，这意味着应增加放置组的数量！
无论恢复时间有多短，在恢复过程中都会存在存储放置组的另一个 OSD 出现故障的情况。
在上述 10 OSD 集群中，如果任何 OSD 失败，则大约 8 个放置组（即 75 pgs / 9 osds 被恢复）将只有一个存活副本。如果其中任何 8 个剩余的 OSD 失败，则一个放置组的最后对象可能会丢失（即 8 pgs / 8 osds，只有一个剩余副本被恢复）。这是为什么首选从一些大型集群开始（例如 50 个 OSD）。
当集群大小增加到 20 个 OSD 时，放置组的数量会因为三个 OSD 丢失而损坏。第二个 OSD 大约会降级 2（即 35 pgs / 19 osds 被恢复）而不是 8，而第三个 OSD 仅在含有存活副本的两个 OSD 之一时丢失数据。换句话说，如果在恢复时间范围内丢失一个 OSD 的概率为 0.0001%，它在 10 个 OSD 的集群中为 8 * 0.0001%，在 20 个 OSD 的集群中为 2 * 0.0001%。随着数据持久性，具有 512 或 4096 个放置组在低于 50 个 OSD 的集群中大致相等。
概括讲，更多的 OSD 意味着快速恢复速度，降低因为级联故障导致放置组和其的向永久丢失的风险。
将 OSD 添加到集群时，可能需要很长时间才能为新的 OSD 填充放置组和对象。但是，任何对象都没有降级，而添加 OSD 不会影响数据持久性。
3.3.2. 数据分发
Ceph 寻求避免热点（一些 OSD 接收比其他 OSD 更多的流量）。理想情况下，CRUSH 将对象分配到放置组，以便在放置组被分配给 OSD（也可以随机）时，主 OSD 存储对象会均匀分布在群集和热点上，以及因为数据分发而造成的网络超额订阅问题。
由于 CRUSH 计算每个对象的放置组，但实际上不知道该放置组中各个 OSD 中存储的数据量，因此 放置组数量和 OSD 数量之间的比率可能会大大影响数据的分布。
例如，如果三个副本池中只有一个放置组具有十个 OSD，Ceph 将仅使用三个 OSD 来存储数据，因为 CRUSH 不会有其他选择。当更多放置组可用时，CRUSH 更有可能在 OSD 之间均匀分布对象。CRUSH 也平均分配 PG 到 OSD。
只要有一个或两个 magnitude 多个放置组，分布应该为偶数。例如，3 个 OSD 256 个放置组，10 个 OSD 512 或 1024 个放置组，以此类推。
OSD 和放置组之间的比率通常会解决实施对象条带等高级功能的 Ceph 客户端的数据分布问题。例如，4TB 块设备可能会分片为 4 MB 对象。
OSD 和放置组之间的比率不会在其他情况下解决不均匀的数据分布，因为 CRUSH 不考虑对象大小。使用 librados 接口存储一些相对较小的对象，有些非常大的对象可能会导致数据分布不均匀。例如，总计 4 GB 的 4K 对象均匀分布在 10 个 OSD 上的 1000 个放置组之间。它们将在每个 OSD 上使用 4 GB / 10 = 400 MB。如果一个 400 MB 对象添加到池中，为放置了该对象的放置组提供支持的三个 OSD 将会填充 400 MB + 400 MB = 800 MB，而其他七个 OSD 仍然仅被占据 400 MB。
3.3.3. 资源使用量
对于每个放置组，OSD 和 Ceph 监视器会一直需要内存、网络和 CPU，在恢复期间甚至更多。由集群放置组中的集群对象共享这个开销是放置组存在的主要原因之一。
尽量减少放置组的数量可以节省大量资源。
