ceph health
HEALTH_WARN 1 near full osd(s)

啊哈，尝试稍微调整一下分配给 OSD 的权重。在 osd 之间重新平衡负载似乎很简单，但并不总是像我们希望的那样进行……

增加 osd 权重

首先获取放置组的映射。

$ ceph pg dump > /tmp/pg_dump.1

我们慢慢来，我们将以 0.05 的步长增加 osd.13 的权重。

$ ceph osd tree | grep osd.13
13  3                   osd.13  up  1   

$ ceph osd crush reweight osd.13 3.05
reweighted item id 13 name 'osd.13' to 3.05 in crush map

$ ceph osd tree | grep osd.13
13  3.05                osd.13  up  1

新的权重已更改到 crushmap 中。看看集群中发生了什么。

$ ceph health details
HEALTH_WARN 2 pgs backfilling; 2 pgs stuck unclean; recovery 16884/9154554 degraded (0.184%)
pg 3.183 is stuck unclean for 434.029986, current state active+remapped+backfilling, last acting [1,13,5]
pg 3.83 is stuck unclean for 2479.504088, current state active+remapped+backfilling, last acting [5,13,12]
pg 3.183 is active+remapped+backfilling, acting [1,13,5]
pg 3.83 is active+remapped+backfilling, acting [5,13,12]
recovery 16884/9154554 degraded (0.184%)

好的，pg 3.183 和 3.83 处于 active+remapped+backfilling 状态

$ ceph pg map 3.183
osdmap e4588 pg 3.183 (3.183) -> up [1,13] acting [1,13,5]

$ ceph pg map 3.83
osdmap e4588 pg 3.83 (3.83) -> up [13,5] acting [5,13,12]

在这种情况下，我们可以看到 id 为 13 的 osd 已添加到这两个放置组。Pg 3.183 和 3.83 将分别从 osd 5 和 12 中移除。如果我们查看 osd 带宽，我们可以看到这些传输 osd.1 —> osd.13 和 osd.5 —> osd.13

OSD 1 和 5 是 pg 3.183 和 3.83 的主节点（参见 acting 表），而 OSD 13 正在写入。

我等待集群完成。然后，

$ ceph pg dump > /tmp/pg_dump.3

让我们看看变化。

# Old map
$ egrep '^(3.183|3.83)' /tmp/pg_dump.1 | awk '{print $1,$9,$14,$15}'
3.183 active+clean [1,5] [1,5]
3.83 active+clean [12,5] [12,5]

# New map
$ egrep '^(3.183|3.83)' /tmp/pg_dump.3 | awk '{print $1,$9,$14,$15}'
3.183 active+clean [1,13] [1,13]
3.83 active+clean [13,5] [13,5]

因此，对于 pg 3.183 和 3.83，osd 5 和 12 将被 osd13 替换

减少 osd 权重

与上面相同，但这次是为了减少“接近满比率”的 osd 的权重。

$ ceph pg dump > /tmp/pg_dump.4

$ ceph osd tree | grep osd.7
7   2.65                osd.7   up  1

$ ceph osd crush reweight osd.7 2.6
reweighted item id 7 name 'osd.7' to 2.6 in crush map

$ ceph health detail
HEALTH_WARN 2 pgs backfilling; 2 pgs stuck unclean; recovery 17117/9160466 degraded (0.187%)
pg 3.ca is stuck unclean for 1097.132237, current state active+remapped+backfilling, last acting [4,6,7]
pg 3.143 is stuck unclean for 1097.456265, current state active+remapped+backfilling, last acting [12,6,7]
pg 3.143 is active+remapped+backfilling, acting [12,6,7]
pg 3.ca is active+remapped+backfilling, acting [4,6,7]
recovery 17117/9160466 degraded (0.187%)

在 osd 带宽上，我们可以看到这些传输 osd.4 —> osd.6 和 osd.12 —> osd.6

OSD 4 和 12 是 pg 3.143 和 3.ca 的主节点（参见 acting 表），而 OSD 6 正在写入。OSD 7 将从两个 PG 中释放，这两个 PG 都将被添加到 OSD 6。在我的例子中，osd 7 没有读取，因为它只是这两个 pg 的副本。

# Before
$ egrep '^(3.ca|3.143)' /tmp/pg_dump.3 | awk '{print $1,$9,$14,$15}'
3.143 active+clean [12,7] [12,7]
3.ca active+clean [4,7] [4,7]

# After
$ ceph pg dump > /tmp/pg_dump.5
$ egrep '^(3.ca|3.143)' /tmp/pg_dump.5 | awk '{print $1,$9,$14,$15}'
3.143 active+clean [12,6] [12,6]
3.ca active+clean [4,6] [4,6]

好吧，显然，数据并没有真正传输到期望的 osd，现在它也太满了。我认为需要一些时间才能达到良好的平衡。

使用 crushtool

一个好主意是使用带有 otpion —show-utilization 的 crushtool 进行测试。

首先检索当前的 crushmap

$ ceph osd getcrushmap -o crushmap.bin

您可以显示特定池和 rep 大小的利用率

$ ceph osd dump | grep '^pool 0'
pool 0 'data' rep size 2 min_size 1 crush_ruleset 0 object_hash rjenkins pg_num 64 pgp_num 64 last_change 1 owner 0 
$ crushtool --test -i crushmap.bin --show-utilization --rule 0 --num-rep=2
  device 0: 123
  device 1: 145
  device 2: 125
  device 3: 121
  device 4: 139
  device 5: 133
  device 6: 129
  device 7: 142
  device 8: 146
  device 9: 139
  device 10:    146
  device 11:    143
  device 12:    129
  device 13:    136
  device 14:    152

进行修改，并使用新的权重进行测试

$ crushtool -d crushmap.bin -o crushmap.txt
# edit crushmap.txt
$ crushtool -c crushmap.txt -o crushmap-new.bin
$ crushtool --test -i crushmap-new.bin --show-utilization --rule 0 --num-rep=2

如果一切顺利，重新导入 crushmap

$ ceph osd setcrushmap -i crushmap-new.bin

https://ceph.net.cn/docs/master/man/8/crushtool/

osd reweight-by-utilization

此外，您可以使用 ceph osd reweight-by-utilization。

https://ceph.net.cn/docs/master/rados/operations/control/#osd-subsystem