问题描述
如果1个OSD崩溃，rook-ceph最终会尝试将丢失的数据复制到仍在运行的OSD还是等待所有OSD再次恢复正常？ 我们说是，以便我可以解释如何计算：
我从为Kubernetes PVC调配了1,71 TB的资源开始，每个节点有3个745 GB的节点（总计2,23 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（687/4）上复制172 GB的丢失数据
- 这太多了，因为我们仅剩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（579/6）上复制少于100 GB的丢失数据
- 每个OSD上的可用空间都小于（166+ GB），因此复制仅在剩下5个节点的情况下仍然可以进行，但是如果另一个OSD崩溃，我注定要失败。
最初的假设正确吗？如果是这样，那么数学听起来对您来说正确吗？
解决方法
首先：如果您重视数据，请不要使用大小为2的复制！您最终将遇到导致数据丢失的问题。
关于您的计算：Ceph不会在所有节点上平均分配每MB数据，因此OSD之间会有差异。因此，具有最多数据的OSD将成为您有关可用空间和发生故障后重新平衡的能力的瓶颈。 Ceph还不能很好地处理完整群集或接近完整群集，您的计算非常接近完整群集，这会导致新问题。尝试避免使用容量超过85％或90％的群集，并提前计划并使用更多磁盘来避免整个群集并具有更高的故障抵抗力。 OSD越多，单个磁盘故障对集群其余部分的影响就越小。
关于恢复：ceph通常会尝试自动恢复，但这取决于您的实际美眉贴图和配置池的规则集。例如，如果您有一个由3个机架组成的粉碎树，并且您的池配置为3个大小（因此共有3个副本）分布在3个机架中（故障域=机架），则整个机架将失败。在此示例中，cef将无法恢复第三个副本，直到机架再次联机。数据仍然可供客户端和所有客户端使用，但是您的群集处于降级状态。但是此配置必须手动完成，因此它可能不适用于您，我只想指出它是如何工作的。默认通常是大小为3且主机为故障域的池。