storage - Ceph 每个 osd 的 pg 太多 : all you need to know

Question

我同时收到这两个错误。我无法减少 pg 计数，也无法添加更多存储空间。

这是一个新集群，当我向它上传大约 40GB 时收到了这些警告。我猜是因为 radosgw 创建了一堆池。

ceph 怎么可能每个 osd 有太多的 pg，而每个 pg 的对象却比平均值多，而 pgs 建议太少？

HEALTH_WARN too many PGs per OSD (352 > max 300); 
pool default.rgw.buckets.data has many more objects per pg than average (too few pgs?)

osds: 4 (2 per site 500GB per osd)
size: 2 (cross site replication)
pg:  64
pgp: 64
pools: 11

使用 rbd 和 radosgw，没什么特别的。

Answer 1

我将回答我自己的问题，希望它能对 ceph 内部的问题或类似的误解有所了解。

一劳永逸地修复每个 OSD 的 HEALTH_WARN 过多 PG(352 > 最大 300)

在平衡归置组时，您必须考虑:

我们需要的数据

每个 osd 的 pgs

每个池的 pgs

每个 osd 的池数

暗恋 map

合理的默认 pg 和 pgp 编号

副本计数

我将使用我的设置作为示例，您应该可以将其用作自己的模板。

我们拥有的数据

操作系统数量:4

数量站点:2

每个 osd 的 pgs:？？？

每个池的 pgs:？？？

每个 osd 的池数:10

合理的默认 pg 和 pgp 数量:64(...或者是吗？)

副本数:2(跨站点复制)

暗恋 map

ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY
root ourcompnay
site a
rack a-esx.0
host prdceph-strg01
osd.0 up 1.00000 1.00000
osd.1 up 1.00000 1.00000
site b
rack a-esx.0
host prdceph-strg02
osd.2 up 1.00000 1.00000
osd.3 up 1.00000 1.00000

我们的目标是填写 '???'以上是我们需要服务的内容 HEALTH OK簇。我们的池是由 rados 网关在初始化时创建的。
我们有一个 default.rgw.buckets.data所有数据都被存储在那里，其余的池是 cephs 元数据和簿记的管理和内部。

每个 osd 的 PG(什么是合理的默认值？？？？)

文档会让我们使用这个计算来确定每个 osd 的 pg 计数:

 (osd * 100)
----------- = pgs UP to nearest power of 2
 replica count

据说四舍五入是最佳的。因此，对于我们当前的设置，它将是:

 (4 * 100)
----------- = (200 to the nearest power of 2) 256
    2

osd.1 ~= 256

osd.2 ~= 256

osd.3 ~= 256

osd.4 ~= 256

这是推荐的 最大 每个 osd 的 pg 数量。那么......你目前实际拥有什么？为什么它不起作用？如果你设置了一个
'合理的默认'并理解上述为什么它不起作用!!! >=[

可能有几个原因。我们必须了解上面那些“合理的默认值”的实际含义，ceph 如何应用它们以及应用于何处。人们可能会从上面误解我可以像这样创建一个新池:
ceph osd pool create <pool> 256 256
或者我什至可能认为我可以安全地进行操作并遵循说明 (128 pgs for < 5 osds) 的文档。可以使用:
ceph osd pool create <pool> 128 128
这是错误的，一言以蔽之。因为它根本无法解释 ceph 对这些数字所做的事情之间的关系或平衡
从技术上讲，正确的答案是:
ceph osd pool create <pool> 32 32
让我解释一下原因:

如果像我一样，您为集群配置了那些“合理的默认值” (128 pgs for < 5 osds)一旦您尝试使用 rados 执行任何操作，它就会创建一大堆池，并且您的集群会变得异常拥挤。
原因是我误解了上面提到的一切之间的关系。

池:10(由 rados 创建)

每个池的 pgs:128(在文档中推荐)

osds:4(每个站点 2 个)

10 * 128 / 4 = 320 pgs per osd
此 ~320我的集群上每个 osd 可能有多个 pg。但是 ceph 可能会以不同的方式分配这些。这正是正在发生的事情
远远超过 每个 osd 最多 256 个 综上所述。我的集群 HEALTH WARN是 HEALTH_WARN too many PGs per OSD (368 > max 300) .

使用 this命令我们能够更好地看到数字之间的关系:

pool :17 18  19  20  21  22  14  23  15  24  16 | SUM
------------------------------------------------< - *total pgs per osd*
osd.0 35 36  35  29  31  27  30  36  32  27  28 | 361
osd.1 29 28  29  35  33  37  34  28  32  37  36 | 375
osd.2 27 33  31  27  33  35  35  34  36  32  36 | 376
osd.3 37 31  33  37  31  29  29  30  28  32  28 | 360
-------------------------------------------------< - *total pgs per pool*
SUM :128 128 128 128 128 128 128 128 128 128 128

您拥有的池数量与分配给它们的归置组数量之间存在直接关联。
我在上面的片段中有 11 个池，每个池都有 128 页，太多了!!我合理的默认值是 64!所以发生了什么事？？

我误解了如何使用“合理的默认值”。当我将默认值设置为 64 时，您可以看到 ceph 已将我的暗恋 map 考虑在内
我在站点 a 和站点 b 之间有一个故障域。 Ceph 必须确保站点 a 上的所有内容至少可以在站点 b 上访问。

错误的

site a
osd.0
osd.1 TOTAL of ~ 64pgs

site b
osd.2 
osd.3 TOTAL of ~ 64pgs

我们需要一个 每个池总计 64 页 所以我们合理的默认值应该从一开始就设置为 32!

如果我们使用 ceph osd pool create <pool> 32 32这意味着我们每个池的 pgs 和每个 osd 的 pgs 与那些“合理的默认值”之间的关系以及我们推荐的 最大 每个 osd 的 pgs 开始变得有意义:

所以你破坏了你的集群^_^

别担心，我们会修复它。恐怕这里的过程在风险和时间上可能会有所不同，具体取决于您的集群有多大。但唯一的办法
要想解决这个问题，那就是增加更多的存储空间，以便置放群组可以重新分布在更大的表面积上。或者我们必须把所有东西都转移到
新创建的池。

我将展示一个移动 default.rgw.buckets.data 的例子。水池:

old_pool=default.rgw.buckets.data
new_pool=new.default.rgw.buckets.data

创建一个具有正确 pg 计数的新池:
ceph osd pool create $new_pool 32
将旧池的内容复制到新池中:
rados cppool $old_pool $new_pool
删除旧池:
ceph osd pool delete $old_pool $old_pool --yes-i-really-really-mean-it
将新池重命名为“default.rgw.buckets.data”
ceph osd pool rename $new_pool $old_pool
现在重新启动 radosgws 可能是一个安全的选择。

最后正确

site a
osd.0
osd.1 TOTAL of ~ 32pgs

site b
osd.2 
osd.3 TOTAL of ~ 32pgs

正如您所看到的，我的池编号增加了，因为它们是按池 ID 添加的并且是新副本。我们每个 osd 的总 pgs 远低于 ~256 如果需要，这为我们提供了添加自定义池的空间。

pool :  26 35 27 36 28 29 30 31 32 33 34 | SUM
-----------------------------------------------
osd.0   15 18 16 17 17 15 15 15 16 13 16 | 173
osd.1   17 14 16 15 15 17 17 17 16 19 16 | 179
osd.2   17 14 16 18 12 17 18 14 16 14 13 | 169
osd.3   15 18 16 14 20 15 14 18 16 18 19 | 183
-----------------------------------------------
SUM :   64 64 64 64 64 64 64 64 64 64 64 

现在你应该用你可以使用的任何东西来测试你的 ceph 集群。就我个人而言，我已经在 boto 上编写了一堆 python 来测试基础设施并相当快地返回存储桶统计信息和元数据。他们向我保证集群恢复正常工作，没有任何以前遇到的问题。祝你好运!

一劳永逸地修复池 default.rgw.buckets.data 每个 pg 的对象比平均值多得多(pg 太少？)

这实际上意味着，您需要增加池的 pg 和 pgp 数量。所以……去做吧。考虑到上面提到的一切。但是，当您执行此操作时，请注意集群将启动 backfilling你可以观看这个过​​程 %: watch ceph -s在另一个终端窗口或屏幕中。

ceph osd pool set default.rgw.buckets.data pg_num 128
ceph osd pool set default.rgw.buckets.data pgp_num 128

有了以上部分提供的系统知识和信心，我们可以清楚地了解这种变化对集群的关系和影响。

pool :  35 26 27 36 28 29 30 31 32 33 34 | SUM
----------------------------------------------
osd.0   18 64 16 17 17 15 15 15 16 13 16 | 222
osd.1   14 64 16 15 15 17 17 17 16 19 16 | 226
osd.2   14 66 16 18 12 17 18 14 16 14 13 | 218
osd.3   18 62 16 14 20 15 14 18 16 18 19 | 230
-----------------------------------------------
SUM :   64 256 64 64 64 64 64 64 64 64 64 

你能猜出哪个池 id 是 default.rgw.buckets.data ?哈哈^_^