3.2. 放置组交换

Ceph 努力防止数据永久丢失。但是，在 OSD 出现故障后，永久数据丢失的风险会增加，直到其包含的数据被完全恢复。永久数据丢失虽然很少，但仍可能发生。以下场景描述了 Ceph 如何在具有三个数据副本的单个放置组中永久丢失数据：

硬件故障并非例外，而是预期的结果。为防止这种情况，理想情况下的恢复过程应尽可能快。集群的大小、您的硬件配置和放置组在总恢复时间中扮演着重要角色。

Ceph 可能会在剩余的 9 个 OSD 中随机存储剩余的 150 个 PG。因此，每个剩余的 OSD 可能会发送对象副本到所有其他 OSD，并且接收一些新的对象，因为剩余的 OSD 不再负责现在分配给它们的部分 150 个 PG。

恢复时间总量取决于支持池的硬件。例如，在一个 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。20 OSD 集群仍然需要所有 19 个 OSD 执行相同数量的副本操作才能恢复。在 10 个 OSD 集群中，每个 OSD 必须复制约 100 GB。在 20 OSD 集群中，每个 OSD 只需要每个 OSD 复制到 50 GB。如果网络成为瓶颈，恢复会以最快的速度进行两次。换句话说，随着 OSD 数量的增加，恢复时间会减少。

在上述 10 OSD 集群中，如果任何 OSD 失败，则大约 8 个 PG（即 75 pgs / 9 osds / 9 osds）将只有一个存活副本。如果任何 8 个剩余的 OSD 失败，一个 PG 的最后一个对象可能会丢失（即 8 pgs / 8 osds，只有一个剩余的副本被恢复）。这就是为什么从一些较大的集群开始，最好使用 50 个 OSD。

当集群大小增加到 20 个 OSD 时，丢失三个 OSD 的 PG 数量会下降。第二个 OSD 丢失大约 2（即 35 pgs / 19 osds，而不是 8 个），而第三个 OSD 只有在包含 surviving copy 的两个 OSD 中的一个时，才会丢失数据。换而言之，如果恢复时间范围内丢失一个 OSD 的可能性为 0.0001%，则它从具有 10 个 OSD 的集群中的 8 * 0.0001% 到具有 20 个 OSD 的集群中 2 * 0.0001%。就数据持久性而言，在少于 50 个 OSD 的集群中，拥有 512 或 4096 个 PG 大致相等。

将 OSD 添加到集群中时，可能需要很长时间来填充具有放置组和对象的新 OSD。不过，任何对象都不会降级，添加 OSD 不会影响数据持久性。

Ceph 力图避免热点，即，一些 OSD 获得的流量比其他 OSD 更多。理想情况下，CRUSH 将对象均匀分配给放置组，使得放置组分配到 OSD 时（也是随机的），Primary OSD 存储对象，使得它们均匀分布在群集、热点和网络超额订阅问题中。

由于 CRUSH 计算各个对象的 PG，但实际上不知道此放置组内各个 OSD 中存储多少数据，而 PG 数量和 OSD 的数量可能会显著影响数据的分布。

例如，如果三个副本池中只有一个 PG，Ceph 将仅使用三个 OSD 来存储数据，因为 CRUSH 没有其他选择。当有更多放置组可用时，CRUSH 更有可能在 OSD 之间均匀分布对象。CRUSH 也均匀分配 PG 到 OSD。

只要 PG 比 OSD 高一或两个数量级，分布就应该是均匀的。例如，32 个 PG 用于 3 个 OSD，512 或 1024 个 PG 用于 10 个 OSD，以此类推。

OSD 和 PG 之间的比例通常解决了实施对象分条等高级功能的 Ceph 客户端的数据分布不均匀的问题。例如，一个 4 TB 块设备可能会分片到 4MB 对象中。

在其他情形中，OSD 和 PG 之间的比率不会解决数据分布不均匀的问题，因为 CRUSH 不考虑对象大小。使用 librados 接口存储一些相对较小的对象，一些非常大的对象可能会导致数据分布不均匀。例如，总共 4 GB 的 100万个 4K 对象均匀分布在 10 个 OSD 上的 1000 个放置组中。它们将在每个 OSD 上使用 4 GB / 10 = 400 MB。如果一个 400 MB 的对象添加到池中，则支持放置对象的 PG 的三个 OSD 将会填充 400 MB + 400 MB = 800 MB，而其他七个 OSD 仍然仅被占据 400MB。

对于每个放置组，OSD 和 Ceph 监视器始终需要内存、网络和 CPU，在恢复期间则需要更多。在放置组中通过集群对象共享此开销是放置组存在的主要原因之一。

最大程度减少 PG 数量可节省大量资源。