为什么 Ceph 在仍有可用存储时将状态变为 Err space
Why Ceph turns status to Err when there is still available storage space
我最近搭建了一个3节点的Ceph集群。每个节点都有 7 个 1TB HDD 用于 OSD。我总共有 21 TB 的存储空间 space 用于 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.37TBspace，Ceph自己应该注意如何平衡工作量，让每个OSD不在full ] 或 nearfull 状态。但是结果并不如我所料，出现1 full osd和4 nearfull osd，健康是HEALTH_ERR。
我不能再用hdfs或s3cmd访问Ceph了，所以问题来了：
1, 对当前问题有什么解释吗？
2、我该如何恢复？直接用ceph-admin删除Ceph节点上的数据，然后重启Ceph？
3天没有得到答案，我有一些进步，让我在这里分享我的发现。
1、不同的OSD有大小差异是正常的。如果你列出ceph osd df的OSD，你会发现不同的OSD有不同的使用率。
2、要从这个问题中恢复，这里的问题是指由于OSD full导致的集群崩溃。按照以下步骤操作，主要来自 redhat。
- 通过
ceph health detail 获取 ceph 集群健康信息。这不是必需的，但您可以获得失败的 OSD 的 ID。
- 使用
ceph osd dump | grep full_ratio 获取电流 full_ratio。不要使用上面列出的语句 link，它已经过时了。输出可以像
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85
- 将 OSD 满率设置得高一点
ceph osd set-full-ratio <ratio>。一般我们设置ratio为0.97
- 现在，集群状态将从HEALTH_ERR变为HEALTH_WARN或HEALTH_OK。删除一些可以发布的数据。
- 将 OSD 满屏比例改回之前的比例。它不能总是 0.97，因为它有点冒险。
希望这个帖子对 运行 遇到同样问题的人有所帮助。 OSD配置详情请参考ceph。
Ceph 需要空闲磁盘 space 才能在不同磁盘之间移动名为 pgs 的存储块。由于这个空闲 space 对底层功能至关重要，一旦任何 OSD 达到 near_full 比率（通常为 85% 已满），Ceph 将进入 HEALTH_WARN，并将停止对 OSD 的写操作一旦 OSD 达到 full_ratio.
，进入 HEALTH_ERR 状态集群
但是，除非您的集群在所有 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 重新调整。
我最近搭建了一个3节点的Ceph集群。每个节点都有 7 个 1TB HDD 用于 OSD。我总共有 21 TB 的存储空间 space 用于 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.37TBspace，Ceph自己应该注意如何平衡工作量，让每个OSD不在full ] 或 nearfull 状态。但是结果并不如我所料，出现1 full osd和4 nearfull osd，健康是HEALTH_ERR。
我不能再用hdfs或s3cmd访问Ceph了，所以问题来了：
1, 对当前问题有什么解释吗？
2、我该如何恢复？直接用ceph-admin删除Ceph节点上的数据，然后重启Ceph？
3天没有得到答案，我有一些进步，让我在这里分享我的发现。
1、不同的OSD有大小差异是正常的。如果你列出ceph osd df的OSD，你会发现不同的OSD有不同的使用率。
2、要从这个问题中恢复，这里的问题是指由于OSD full导致的集群崩溃。按照以下步骤操作，主要来自 redhat。
- 通过
ceph health detail获取 ceph 集群健康信息。这不是必需的，但您可以获得失败的 OSD 的 ID。 - 使用
ceph osd dump | grep full_ratio获取电流 full_ratio。不要使用上面列出的语句 link，它已经过时了。输出可以像
full_ratio 0.95
backfillfull_ratio 0.9
nearfull_ratio 0.85
- 将 OSD 满率设置得高一点
ceph osd set-full-ratio <ratio>。一般我们设置ratio为0.97 - 现在，集群状态将从HEALTH_ERR变为HEALTH_WARN或HEALTH_OK。删除一些可以发布的数据。
- 将 OSD 满屏比例改回之前的比例。它不能总是 0.97，因为它有点冒险。
希望这个帖子对 运行 遇到同样问题的人有所帮助。 OSD配置详情请参考ceph。
Ceph 需要空闲磁盘 space 才能在不同磁盘之间移动名为 pgs 的存储块。由于这个空闲 space 对底层功能至关重要，一旦任何 OSD 达到 near_full 比率（通常为 85% 已满），Ceph 将进入 HEALTH_WARN，并将停止对 OSD 的写操作一旦 OSD 达到 full_ratio.
HEALTH_ERR 状态集群
但是，除非您的集群在所有 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 重新调整。