ceph df max available 计算错误
ceph df max available miscalculation
Ceph 集群显示以下奇怪的行为 ceph df 输出：
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 817 TiB 399 TiB 418 TiB 418 TiB 51.21
ssd 1.4 TiB 1.2 TiB 22 GiB 174 GiB 12.17
TOTAL 818 TiB 400 TiB 418 TiB 419 TiB 51.15
--- POOLS ---
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
pool1 45 300 21 TiB 6.95M 65 TiB 20.23 85 TiB
pool2 50 50 72 GiB 289.15k 357 GiB 0.14 85 TiB
pool3 53 64 2.9 TiB 754.06k 8.6 TiB 3.24 85 TiB
erasurepool_data 57 1024 138 TiB 50.81M 241 TiB 48.49 154 TiB
erasurepool_metadata 58 8 9.1 GiB 1.68M 27 GiB 2.46 362 GiB
device_health_metrics 59 1 22 MiB 163 66 MiB 0 85 TiB
.rgw.root 60 8 5.6 KiB 17 3.5 MiB 0 85 TiB
.rgw.log 61 8 70 MiB 2.56k 254 MiB 0 85 TiB
.rgw.control 62 8 0 B 8 0 B 0 85 TiB
.rgw.meta 63 8 7.6 MiB 52 32 MiB 0 85 TiB
.rgw.buckets.index 64 8 11 GiB 1.69k 34 GiB 3.01 362 GiB
.rgw.buckets.data 65 512 23 TiB 33.87M 72 TiB 21.94 85 TiB
如上所示，可用存储空间为 399TiB，池列表中的最大可用空间显示为 85TiB。我为每个池复制池使用 3 个副本，为 erasurepool_data.
使用 3+2 擦除代码
据我所知 Max Avail 段根据副本大小显示最大原始可用容量。所以达到85*3=255TiB。同时群集显示将近 400 个可用。
该相信哪个？
这只是一个错误吗？
当您添加纠删码池时，即 erasurepool_data 在 154，您将得到 255+154 = 399。
MAX AVAIL 列表示在第一个 OSD 变满之前可以使用的数据量。它考虑了来自 CRUSH 图的跨磁盘数据的预计分布，并使用 'first OSD to fill up' 作为目标。它似乎不是错误。如果 MAX AVAIL 不是您期望的，请使用 ceph osd 树查看数据分布并确保分布均匀。
您还可以在此处查看一些有用的 posts，其中解释了一些计算错误：
- Using available space in a Ceph pool
- ceph-displayed-size-calculation
- max-avail-in-ceph-df-command-is-incorrec
由于涉及纠删码，请检查此 SO post:
- ceph-df-octopus-shows-used-is-7-times-higher-than-stored-in-erasure-coded-pool
原来max available space是根据集群中最满的osd计算的，与集群中的total free space无关。据我所知，这种波动主要发生在小集群上。
Ceph 集群显示以下奇怪的行为 ceph df 输出：
--- RAW STORAGE ---
CLASS SIZE AVAIL USED RAW USED %RAW USED
hdd 817 TiB 399 TiB 418 TiB 418 TiB 51.21
ssd 1.4 TiB 1.2 TiB 22 GiB 174 GiB 12.17
TOTAL 818 TiB 400 TiB 418 TiB 419 TiB 51.15
--- POOLS ---
POOL ID PGS STORED OBJECTS USED %USED MAX AVAIL
pool1 45 300 21 TiB 6.95M 65 TiB 20.23 85 TiB
pool2 50 50 72 GiB 289.15k 357 GiB 0.14 85 TiB
pool3 53 64 2.9 TiB 754.06k 8.6 TiB 3.24 85 TiB
erasurepool_data 57 1024 138 TiB 50.81M 241 TiB 48.49 154 TiB
erasurepool_metadata 58 8 9.1 GiB 1.68M 27 GiB 2.46 362 GiB
device_health_metrics 59 1 22 MiB 163 66 MiB 0 85 TiB
.rgw.root 60 8 5.6 KiB 17 3.5 MiB 0 85 TiB
.rgw.log 61 8 70 MiB 2.56k 254 MiB 0 85 TiB
.rgw.control 62 8 0 B 8 0 B 0 85 TiB
.rgw.meta 63 8 7.6 MiB 52 32 MiB 0 85 TiB
.rgw.buckets.index 64 8 11 GiB 1.69k 34 GiB 3.01 362 GiB
.rgw.buckets.data 65 512 23 TiB 33.87M 72 TiB 21.94 85 TiB
如上所示，可用存储空间为 399TiB，池列表中的最大可用空间显示为 85TiB。我为每个池复制池使用 3 个副本，为 erasurepool_data.
据我所知 Max Avail 段根据副本大小显示最大原始可用容量。所以达到85*3=255TiB。同时群集显示将近 400 个可用。
该相信哪个？ 这只是一个错误吗？
当您添加纠删码池时，即 erasurepool_data 在 154，您将得到 255+154 = 399。
MAX AVAIL 列表示在第一个 OSD 变满之前可以使用的数据量。它考虑了来自 CRUSH 图的跨磁盘数据的预计分布，并使用 'first OSD to fill up' 作为目标。它似乎不是错误。如果 MAX AVAIL 不是您期望的，请使用 ceph osd 树查看数据分布并确保分布均匀。
您还可以在此处查看一些有用的 posts，其中解释了一些计算错误：
- Using available space in a Ceph pool
- ceph-displayed-size-calculation
- max-avail-in-ceph-df-command-is-incorrec
由于涉及纠删码，请检查此 SO post:
- ceph-df-octopus-shows-used-is-7-times-higher-than-stored-in-erasure-coded-pool
原来max available space是根据集群中最满的osd计算的，与集群中的total free space无关。据我所知，这种波动主要发生在小集群上。