为什么 Ceph 在仍有可用存储空间时将状态变为 Err答案

【问题标题】：Why Ceph turns status to Err when there is still available storage space为什么 Ceph 在仍有可用存储空间时将状态变为 Err
【发布时间】：2023-03-20 07:56:02
【问题描述】：

我最近构建了一个 3 节点 Ceph 集群。每个节点都有七个用于 OSD 的 1TB HDD。我总共有 21 TB 的 Ceph 存储空间。

但是，当我运行工作负载以继续将数据写入Ceph 时，它会变为Err 状态，并且无法再向其写入数据。

ceph -s 的输出为：

 cluster:
    id:     06ed9d57-c68e-4899-91a6-d72125614a94
    health: HEALTH_ERR
            1 full osd(s)
            4 nearfull osd(s)
            7 pool(s) full

  services:
    mon: 1 daemons, quorum host3
    mgr: admin(active), standbys: 06ed9d57-c68e-4899-91a6-d72125614a94
    osd: 21 osds: 21 up, 21 in
    rgw: 4 daemons active

  data:
    pools:   7 pools, 1748 pgs
    objects: 2.03M objects, 7.34TiB
    usage:   14.7TiB used, 4.37TiB / 19.1TiB avail
    pgs:     1748 active+clean

根据我的理解，由于还剩下 4.37 TB 空间，Ceph 本身应该注意如何平衡工作负载，并使每个 OSD 不处于full 或nearfull 状态。但是结果出乎我的意料，1 full osd和4 nearfull osd出现了，健康是HEALTH_ERR。

我不能再用hdfs 或s3cmd 访问 Ceph，所以问题来了：
1，关于当前问题的任何解释？
2，我怎样才能从中恢复？直接用 ceph-admin 删除 Ceph 节点上的数据，然后重新启动 Ceph？

【问题讨论】：

标签： hadoop bigdata ceph

【解决方案1】：

3天没有得到答案，我取得了一些进展，让我在这里分享我的发现。

1、不同的OSD有大小差距是正常的。如果你用ceph osd df列出OSD，你会发现不同的OSD有不同的使用率。

2，从这个问题中恢复，这里的问题是指由于 OSD 已满导致集群崩溃。请按照以下步骤操作，主要来自redhat。

通过ceph health detail 获取ceph 集群健康信息。这不是必需的，但您可以获取失败 OSD 的 ID。
使用ceph osd dump | grep full_ratio 获取当前的full_ratio。不要使用上面链接中列出的语句，它已经过时了。输出可以像

full_ratio 0.95 backfillfull_ratio 0.9 nearfull_ratio 0.85

通过ceph osd set-full-ratio <ratio> 将OSD 满率设置得稍高一点。通常，我们将 ratio 设置为 0.97
现在，集群状态将从 HEALTH_ERR 更改为 HEALTH_WARN 或 HEALTH_OK。删除一些可以发布的数据。
将 OSD 完整比率更改回之前的比率。它不能总是 0.97，因为它有点冒险。

希望这个帖子对遇到同样问题的人有所帮助。 OSD配置详情请参考ceph。

【讨论】：

【解决方案2】：

Ceph 需要可用磁盘空间来在不同磁盘之间移动存储块，称为 pgs。由于这个可用空间对底层功能非常重要，一旦任何 OSD 达到near_full 比率（通常是 85% 满），Ceph 将进入HEALTH_WARN，并通过进入HEALTH_ERR 状态一次来停止集群上的写入操作一个 OSD 到达full_ratio。

但是，除非您的集群在所有 OSD 之间完全平衡，否则可能会有更多可用容量，因为 OSD 通常使用不均衡。要检查整体利用率和可用容量，您可以运行 ceph osd df。

示例输出：

ID CLASS WEIGHT  REWEIGHT SIZE    RAW USE DATA    OMAP    META    AVAIL    %USE  VAR  PGS STATUS 
 2   hdd 2.72849  1.00000 2.7 TiB 2.0 TiB 2.0 TiB  72 MiB 3.6 GiB  742 GiB 73.44 1.06 406     up 
 5   hdd 2.72849  1.00000 2.7 TiB 2.0 TiB 2.0 TiB 119 MiB 3.3 GiB  726 GiB 74.00 1.06 414     up 
12   hdd 2.72849  1.00000 2.7 TiB 2.2 TiB 2.2 TiB  72 MiB 3.7 GiB  579 GiB 79.26 1.14 407     up 
14   hdd 2.72849  1.00000 2.7 TiB 2.3 TiB 2.3 TiB  80 MiB 3.6 GiB  477 GiB 82.92 1.19 367     up 
 8   ssd 0.10840        0     0 B     0 B     0 B     0 B     0 B      0 B     0    0   0     up 
 1   hdd 2.72849  1.00000 2.7 TiB 1.7 TiB 1.7 TiB  27 MiB 2.9 GiB 1006 GiB 64.01 0.92 253     up 
 4   hdd 2.72849  1.00000 2.7 TiB 1.7 TiB 1.7 TiB  79 MiB 2.9 GiB 1018 GiB 63.55 0.91 259     up 
10   hdd 2.72849  1.00000 2.7 TiB 1.9 TiB 1.9 TiB  70 MiB 3.0 GiB  887 GiB 68.24 0.98 256     up 
13   hdd 2.72849  1.00000 2.7 TiB 1.8 TiB 1.8 TiB  80 MiB 3.0 GiB  971 GiB 65.24 0.94 277     up 
15   hdd 2.72849  1.00000 2.7 TiB 2.0 TiB 2.0 TiB  58 MiB 3.1 GiB  793 GiB 71.63 1.03 283     up 
17   hdd 2.72849  1.00000 2.7 TiB 1.6 TiB 1.6 TiB 113 MiB 2.8 GiB  1.1 TiB 59.78 0.86 259     up 
19   hdd 2.72849  1.00000 2.7 TiB 1.6 TiB 1.6 TiB 100 MiB 2.7 GiB  1.2 TiB 56.98 0.82 265     up 
 7   ssd 0.10840        0     0 B     0 B     0 B     0 B     0 B      0 B     0    0   0     up 
 0   hdd 2.72849  1.00000 2.7 TiB 2.0 TiB 2.0 TiB 105 MiB 3.0 GiB  734 GiB 73.72 1.06 337     up 
 3   hdd 2.72849  1.00000 2.7 TiB 2.0 TiB 2.0 TiB  98 MiB 3.0 GiB  781 GiB 72.04 1.04 354     up 
 9   hdd 2.72849        0     0 B     0 B     0 B     0 B     0 B      0 B     0    0   0     up 
11   hdd 2.72849  1.00000 2.7 TiB 1.9 TiB 1.9 TiB  76 MiB 3.0 GiB  817 GiB 70.74 1.02 342     up 
16   hdd 2.72849  1.00000 2.7 TiB 1.8 TiB 1.8 TiB  98 MiB 2.7 GiB  984 GiB 64.80 0.93 317     up 
18   hdd 2.72849  1.00000 2.7 TiB 2.0 TiB 2.0 TiB  79 MiB 3.0 GiB  792 GiB 71.65 1.03 324     up 
 6   ssd 0.10840        0     0 B     0 B     0 B     0 B     0 B      0 B     0    0   0     up 
                    TOTAL  47 TiB  30 TiB  30 TiB 1.3 GiB  53 GiB   16 TiB 69.50                 
MIN/MAX VAR: 0.82/1.19  STDDEV: 6.64

正如您在上面的输出中看到的那样，使用的 OSD 从 56.98% (OSD 19) 到 82.92% (OSD 14) 不等，这是一个很大的差异。

由于只有一个 OSD 是 full，并且您的 21 个 OSD 中只有 4 个是 nearfull，因此您的集群中可能还有大量可用存储空间，这意味着是时候执行一个 再平衡操作。这可以通过重新加权 OSD 手动完成，或者您可以通过运行命令 ceph osd reweight-by-utilization 让 Ceph 尽最大努力重新平衡。一旦重新平衡完成（即您没有在ceph status 中放错对象），您可以再次检查变化（使用ceph osd df）并在需要时触发另一个重新平衡。

如果您使用 Luminous 或更新版本，您可以启用 Balancer plugin 以自动处理 OSD 重新调整。

【讨论】：

感谢您让我知道重新加权操作。
非常欢迎。如果这回答了您的问题，您可以接受它作为答案吗？