这个计算正确吗？(rook复制)

Question

如果一个OSD崩溃，rok-ceph到底是试图将丢失的数据复制到静止运行的OSD，还是等待所有的OSD恢复正常？让我们说是的，这样我就可以解释我是如何计算的：

我从为kubernetes PVCs和每个745 GB的3个节点(总计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 provisionning)

• Which - 3,42 PVC

• 是每OSD 58 GB (290 /5))，

• 崩溃了OSD有687 GB (745磁盘总数- 58 GB未使用)

• Ceph试图在每个OSD上复制172GB丢失的数据(687/4)

• ，这是因为我们只剩下58 GB，这将导致OSD故障级联

。

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

• 新池是4,5 TB (6x745)
• I，在集群上有1+ TB空闲空间(4,5 - 3,42 PVC
• 是166+ GB / OSD (~1 TB /6)
• 崩溃OSD具有579+ GB数据最大值)。(745-166)
• Ceph尝试在每个OSD左侧(579 /6)
• 上复制不足100 GB的丢失数据，这比每个OSD (166+ GB)上的空闲空间还少，所以只剩下5个节点就可以再次复制，但是如果另一个OSD崩溃了，那就注定了。

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

Answer 1

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

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

关于恢复:Ceph通常尝试自动恢复，但这取决于实际的crushmap和配置池的规则集。例如，如果您有一个由3个机架组成的压碎树，并且您的池配置为3大小(总共有3个副本)，那么整个机架就会失败。在本例中，ceph将无法恢复第三个副本，直到机架再次联机为止。这些数据仍然对客户端和所有用户都可用，但是您的集群处于降级状态。但是这个配置必须手动完成，所以它可能不适用于您，我只想指出它是如何工作的。默认情况下，通常是一个大小为3的池，主机作为失败域。