0

如果 1 个 OSD 崩溃，rook-ceph 最终会尝试将丢失的数据复制到仍在工作的 OSD 上，还是等待所有 OSD 恢复健康？假设是这样，我可以解释我是如何计算的：

我开始为 kubernetes PVC 和 3 个 745 GB 的节点（总共 2.23 TB）预置 1.71 TB。Rook 的复制因子为 2 (RF=2)。

为了使复制工作，我需要 2 倍 1,71 TB（3,42 TB），所以我添加了 2 个节点，每个节点 745 GB（总共 3,72 TB）假设我使用了所有 1,71 TB 的预置。

如果我丢失了一个 OSD，我的 K8S 集群仍然运行，因为数据被复制了，但是当丢失的数据在仍然工作的 OSD 上被复制时，其他 OSD 可能会崩溃，因为假设 OSD 总是均匀分布（我知道这在很长一段时间内是不正确的）跑） ：

  • 我的集群上有 290 GB 未使用空间（总共 3,72 - 3,42 PVC 配置）
  • 每个 OSD 58 GB (290 / 5)
  • 崩溃的 OSD 有 687 GB（总共 745 个磁盘 - 58 GB 未使用）
  • Ceph 尝试在剩余的每个 OSD 上复制 172 GB 缺失数据 (687/4)
  • 这太多了，因为我们只剩下 58 GB，这应该会导致 OSD 故障级联

如果我有 6 个节点而不是 5 个，我可以无限期地释放 1 个 OSD：

  • 新池为 4.5 TB (6x745)
  • 我在集群上有 1+ TB 可用空间（总共 4,5 - 3,42 PVC 配置）
  • 每个 OSD 166+ GB (~1 TB / 6)
  • 崩溃的 OSD 最大有 579+ GB 数据。(745 - 166)
  • Ceph 尝试在剩余的每个 OSD 上复制少于 100 GB 的缺失数据 (579 / 6)
  • 这小于每个 OSD 上的可用空间（166+ GB）所以复制再次工作只剩下 5 个节点但如果另一个 OSD 崩溃我注定要失败。

最初的假设是否正确？如果是这样，数学听起来对你吗？

4

1 回答 1

3

第一：如果您重视数据，请不要使用大小为 2 的复制！您最终会遇到导致数据丢失的问题。

关于您的计算：Ceph 不会在所有节点上平均分配每 MB 数据，您的 OSD 之间会有差异。因此，拥有最多数据的 OSD 将成为您在可用空间和故障后重新平衡能力方面的瓶颈。Ceph 也不能很好地处理完整或接近完整的集群，您的计算非常接近完整的集群，这将导致新的问题。尽量避免使用超过 85% 或 90% 的已用容量的集群，提前计划并使用更多磁盘，以避免集群满载并具有更高的抗故障能力。您拥有的 OSD 越多，单个磁盘故障对集群其余部分的影响就越小。

关于恢复：ceph 通常会尝试自动恢复，但这取决于您的实际 crushmap 和池配置的规则集。例如，如果您有一个由 3 个机架组成的粉碎树，并且您的池配置为大小为 3（因此总共 3 个副本）分布在您的 3 个机架上（故障域 = 机架），那么整个机架都会发生故障。在这个例子中，直到机架再次在线，ceph 才能恢复第三个副本。数据仍然可供客户端和所有人使用，但您的集群处于降级状态。但是这个配置必须手动完成，所以它可能不适用于你，我只是想指出它是如何工作的。默认值通常是大小为 3 的池，主机作为故障域。

于 2020-11-13T10:02:01.023 回答