第一次调整
- 操作：osd.23 使用率达到92%进行调整，将其reweight从1调整至0.9
| osdid | 迁移出去的pg | 迁移进来的pg |
|---|---|---|
| osd.0 | - | 7.96 8.d2 |
| osd.1 | - | 0.13 |
| osd.2 | 8.26 | 7.3e |
| osd.3 | 8.d2 | - |
| osd.4 | 7.3e | 8.26 |
| osd.5 | - | 8.26a |
| osd.6 | - | - |
| osd.7 | 7.22 | - |
| osd.8 | - | 7.a8 |
| osd.9 | - | 7.22 |
| osd.10 | 8.1a4 | - |
| osd.11 | - | - |
| osd.12 | - | 8.1a4 |
| osd.13 | - | - |
| osd.14 | - | 8.26 8.203 |
| osd.15 | - | - |
| osd.16 | 8.19c | 8.266 |
| osd.17 | - | 7.3e 8.8c |
| osd.18 | - | 8.c4 8.19c |
| osd.19 | - | - |
| osd.20 | - | - |
| osd.21 | - | 8.19c 8.1a4 |
| osd.22 | - | 7.22 |
| osd.23 | 0.13 7.22 7.3e 7.96 7.a8 8.26 8.8c 8.c4 8.d2 8.19c 8.1a4 8.203 8.266 8.26a | - |
| osd.24 | - | 8.d2 |
为什么会产生这样的结果？可以发现，在调整了osd.23的reweight之后osd23的确有很多pg从osd.23迁移出去，分布到其他的osd上去，而其他的osd节点上也有部分pg迁出，这些pg也是涵盖在osd.23迁出去的pg中。
在这里，将osd.23上所进行的迁移称之为直接迁移，而这些pg称为调度pg，调度pg所进行的迁移成为有效迁移，从图中可以看出，绝大部分的迁移都是有效迁移（直接迁移为有效迁移的子集），而osd.2上的8.26迁移到osd.4显然是无效的，而从宏观角度来看，osd.2与osd.4只是互换了一个承载的pg，对pg的分布和osd的容量、使用率并不会产生什么影响，本质上来说，是只占资源增加数据迁移工作量的错误迁移，也是我们在进行大量数据迁移操作同时不希望影响在线业务时候不想看到的过程。
再看看一个将reweight从小调整到大的过程。
第二次调整
- 操作：osd.24 ，将其reweight从0.7调整至0.8
| osdid | 迁移出去的pg | 迁移进来的pg |
|---|---|---|
| osd.0 | - | 8.114 |
| osd.1 | 8.114 | 7.0 |
| osd.2 | 8.171 8.22a | - |
| osd.3 | - | - |
| osd.4 | 7.8 | - |
| osd.5 | 7.0 8.4c | - |
| osd.6 | - | - |
| osd.7 | 8.278 | 8.2e6 |
| osd.8 | - | - |
| osd.9 | - | - |
| osd.10 | - | - |
| osd.11 | - | - |
| osd.12 | 7.0 8.60 8.2e6 | - |
| osd.13 | - | - |
| osd.14 | 8.87 | - |
| osd.15 | - | - |
| osd.16 | - | - |
| osd.17 | - | - |
| osd.18 | - | - |
| osd.19 | 10.1 10.3f | - |
| osd.20 | 7.78 8.114 | - |
| osd.21 | - | - |
| osd.22 | 8.2e6 | - |
| osd.23 | 10.10 | - |
| osd.24 | - | 7.0 7.8 7.78 8.4c 8.60 8.87 8.114 8.171 8.22a 8.278 8.2e6 10.1 10.10 10.3f |
显然可以看出，没有产生无效迁移，并且绝大部分是直接迁移，参与调度和计算的osd数量明显减少。
当我们改变集群crush中的crush算法，采用straw2时，再来观察pg的变化。关于starw2，这里进行简单介绍。
straw2和straw的区别在于，straw算法改变一个bucket的权重的时候，因为内部算法的问题，造成了其他机器的item的计算因子也会变化，就会出现其他没修改权重的bucket也会出现pg的相互间的流动，这个跟设计之初的想法是不一致的，造成的后果就是，在增加或者减少存储节点的时候，如果集群比较大，数据比较多，就会造成很大的无关数据的迁移，这个就是上面提到的问题 为了解决这个问题就新加入了算法straw2，这个算法保证在bucket的crush权重发生变化的时候，只会在变化的bucket有数据流入或者流出，不会出现其他bucket间的数据流动，减少数据的迁移量。
附上straw2的配置方式与相关（环境为ubuntu14.04，ceph版本为H版本的0.94.10）：
首先需要调整tunables 为 hammer，使其支持crush v4(straw2)属性。
root@mon0:~/ceph/crush# ceph osd crush tunables hammer
adjusted tunables profile to hammer
root@mon0:~/ceph/crush# ceph osd crush set-tunable straw_calc_version 1
adjusted tunable straw_calc_version to 1
查看是否设置成功
root@mon0:~/ceph/crush# ceph osd crush dump|egrep "allowed_bucket_algs|profile"
"allowed_bucket_algs": 54,
"profile": "hammer",
root@mon0:~/ceph/crush# ceph osd crush dump|grep alg
"alg": "straw",
"alg": "straw",
"alg": "straw",
"alg": "straw",
"alg": "straw",
"alg": "straw",
配置完并不会立即生效，需要执行以下命令。
ceph osd crush reweight-all
修改crush map使其采用straw2。
root@mon0:~/ceph/crush# ceph osd getcrushmap -o crushmap.txt
got crush map from osdmap epoch 390
root@mon0:~/ceph/crush# crushtool -d crushmap.txt -o crushmap-decompile
root@mon0:~/ceph/crush# vim crushmap-decompile
将文件里面的所有straw修改成straw2(如果出现报错就把crushmap里面的straw2_calc_version改成straw_calc_version)
root@mon0:~/ceph/crush# crushtool -c crushmap-decompile -o crushmap-compile
root@mon0:~/ceph/crush# ceph osd setcrushmap -i crushmap-compile
设置算法。
ceph osd crush set-tunable straw_calc_version 2
查询当前crush算法
root@lab8107:~/ceph/crush# ceph osd crush dump|grep alg
"alg": "straw2",
"alg": "straw2",
"alg": "straw2",
"alg": "straw2",
"alg": "straw2",
"alg": "straw2",
"allowed_bucket_algs": 54,
内部算法重新分布
ceph osd crush reweight-all
第三次日调整
- 操作：osd.20 的reweight从1调整到0.9
| osdid | 迁移出去的pg | 迁移进来的pg |
|---|---|---|
| osd.0 | - | - |
| osd.1 | - | 8.16e 8.1fd |
| osd.2 | - | 7.16 8.1f2 |
| osd.3 | - | 8.168 |
| osd.4 | - | - |
| osd.5 | - | 8.e9 8.263 |
| osd.6 | - | - |
| osd.7 | 7.ac | 8.168 8.263 |
| osd.8 | 8.168 | 8.6d |
| osd.9 | - | - |
| osd.10 | - | - |
| osd.11 | 8.263 | - |
| osd.12 | - | 7.ac 8.237 |
| osd.13 | 8.6d | 7.16 8.ba 8.16e |
| osd.14 | 8.16e | - |
| osd.15 | 7.16 | - |
| osd.16 | - | - |
| osd.17 | - | 8.6d |
| osd.18 | - | - |
| osd.19 | - | 0.17 |
| osd.20 | 0.17 7.16 7.2b 7.ac 8.6d 8.ba 8.e9 8.168 8.16e 8.1cb 8.1d7 8.1f2 8.1fd 8.237 8.263 10.3 | - |
| osd.21 | - | 7.ac |
| osd.22 | - | - |
| osd.23 | - | 8.1d7 |
| osd.24 | - | 7.2b 8.1cb 10.3 |
在调整straw为straw2后，可以发现虽然除了直接迁移之外还要其余的有效迁移，但是并没有产生无效迁移，即所有的迁移都是围绕着调度pg进行的，通过底层可以看出，那些将更改reweight的osd选为主osd的pg，发生了有效迁移。
其中到这里基本可以看出，几种迁移性质上的不同，通过源码研究可以更深一步的去了解这些不同的迁移与recovery、bakckfill、rebalance的关系，以及迁移数据量的预估。
上述均为调整reweight,再来看一组如果进行weight操作会产生怎么样的变化。
2018 12 28 日调整
- 操作：osd.23 的weight从0.9调整到0.8
| osdid | 迁移出去的pg | 迁移进来的pg |
|---|---|---|
| osd.0 | 7.39 | 8.90 8.290 |
| osd.1 | - | 8.d2 |
| osd.2 | - | - |
| osd.3 | 8.90 8.d2 | - |
| osd.4 | - | - |
| osd.5 | - | 8.183 |
| osd.6 | - | - |
| osd.7 | - | 7.39 |
| osd.8 | - | - |
| osd.9 | - | - |
| osd.10 | - | 8.2bb 10.f |
| osd.11 | - | 3.6 |
| osd.12 | - | 8.2d8 |
| osd.13 | - | - |
| osd.14 | - | 8.90 8.258 |
| osd.15 | - | 0.c |
| osd.16 | 8.2d8 | - |
| osd.17 | 8.90 | - |
| osd.18 | - | 8.e |
| osd.19 | - | 0.a 8.2d3 10.5 |
| osd.20 | 3.6 8.e 8.2d3 10.5 10.f | 8.1af |
| osd.21 | 8.258 8.290 | 8.21d |
| osd.22 | 8.d2 | - |
| osd.23 | 0.a 8.75 8.183 8.1af 8.21d | - |
| osd.24 | 0.c | 8.75 8.d2 |
在调整weight时，显然可以发现，pg的迁移与变化显得更加杂乱无章，甚至产生了很多无效迁移。因为weight值是crush算法计算pg分布的重要依据，而reweight值只是从硬盘方面去单独调控和均衡的，多集群的影响远小于调整weight值。
下面进行了对reweight值进行更大的调整，调度pg的数量还是大于调整weight。产生迁移的节点和对集群的影响在可接受范围内。
2018 12 28晚上操作
- osd.23的reweight从0.9调整至0.7
| osdid | 迁移出去的pg | 迁移进来的pg |
|---|---|---|
| osd.0 | - | 8.26e |
| osd.1 | - | 7.d7 8.86 8.194 8.1d9 |
| osd.2 | 8.86 | 7.c3 |
| osd.3 | - | 8.bd |
| osd.4 | 7.d7 8.26e | - |
| osd.5 | - | 8.b2 |
| osd.6 | - | - |
| osd.7 | 1.2 | - |
| osd.8 | - | - |
| osd.9 | 8.48 | 1.2 |
| osd.10 | - | 8.19 8.48 |
| osd.11 | - | 8.14e |
| osd.12 | - | - |
| osd.13 | - | - |
| osd.14 | - | 7.c3 8.bd |
| osd.15 | 8.bd | 8.48 |
| osd.16 | - | - |
| osd.17 | - | 1.2 7.d7 8.26e |
| osd.18 | 7.c3 | 8.86 |
| osd.19 | - | 12.7 |
| osd.20 | - | 15.6 |
| osd.21 | - | 8.14d |
| osd.22 | - | 8.b |
| osd.23 | 1.2 7.c3 7.d7 8.b 8.19 8.48 8.86 8.b2 8.bd 8.14d 8.14e 8.194 8.1d9 8.26e 12.7 15.6 | - |
| osd.24 | - | - |
总结
1.调整reweight值的开销和影响以及数据量，小于weight值调整
2.在进行reweight变动时，将reweight值从小调大的开销小于从大调小。
3.straw2算法确实可以规避一部分无效迁移，但是在0.94.10版本中貌似影响较小。而且，在更改集群支持和将straw调整为straw2过程中，这两步都会产生大量数据迁移，很有可能影响业务。
231
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
