OSD过载（失效）测试-reweight

ceph osd reweight

  在ceph集群中，经常会出现大量各个osd设备的磁盘利用率相差较多的情况，而无论是crush本身计算出来的的承担pg的osd组合，还是人工调整的osd组合，往往都是和权重相关的。作为placement rule通常情况下最后choose的叶子节点，磁盘设备拥有一个反应设备自身容量的权重参数-weight值（上一级节点的权重则是其所有直接子节点权重之和，例如host的weight值等于其下所有osd weight值总和），在目前主流的straw2 choose算法中，权重值越大，被选择的几率就越大。而除了该真实权重值之外，ceph中设置了一个额外的权重-reweight，该值本身不存在与cluster map中。

  通常时候，可以把reweight的效果和weight效果简单理解成相似，即值越大，本身越容易被选中，reweight越大pg数越多，reweight减少，pg数则减少即迁出pg。但reweight本身值并不存在于cluster map中，其本身不是直接参与crush算法中choose的过程的，那它是如何影响pg分布的呢

placement rule

  rule，一组包括最大副本数、容灾级别等限制在内的自定义约束条件，也可以称为ceph的数据存储策略。它直接决定了使用了该rule的pool所包含的pg要存在哪些osd上，如何存放，决定了集群的容灾域从而影响集群的健壮性。一条rule可以包含多个操作，但只有三种基本操作类型：take，select，emit

• take：选择指定类型的一个集合作为入口，并作为后续步骤的输入，大部分情况下，我们会task 一个root作为输入
• select：选择指定类型设备指定数量个(firstn算法适用于副本，indep适用于纠删码，本身区别不大），例如 choose firstn 3 type host，就是在上一步take的root下，选择3个host，如果集群本身是host容灾，也可以直接写成chooseleaf firstn 3 type host，则会选出3个host同时，一直往下递归，最终选出分属在3个不同host下的osd设备
• emit：将选择的组合输出并返回

  rule并不是本文重点，关于更多rule相关包括如何自定义符合自己需求的rule可以网上查找学习。通过上述过程中可以看出rule中最关键的步骤其实就是select操作。而select的结果有没有可能出现错误或者异常导致select的设备不能输出呢？

  有，而且还是很经常的情况，所以在select后要检查其结果是否合规，主要要避免两种情况，

  一种是冲突，也就是说选出的条目已经存在于输出条目之中。例如，osd容灾，第一次已经选出osd.0，第二次又选出osd.0，这种情况必然会触发拒绝选择，重置select过程，直到选择不冲突。

  除了冲突之外，还有一种情况就是osd过载（失效）

过载测试

  过载测试的流程如下

1. 首先判断该osd的reweight值是否大于等于1，如果大于等于1则直接通过测试
2. 判断该osd reweight值是否为0，如果为0 ，则直接拒绝选择此osd
3. 如果reweight值介于0与1之间，基于输入x（x可以简单理解为与要存储元素的编号id相关）与OSD编号计算哈希，将哈希结果和0xFFFF做与运算
4. 如果该值小于OSD reweight则通过测试，否则拒绝选择此osd。

  因此不难发现，reweight越高的osd，当期被选中时，通过过载测试的概率也就越大。如果设置为1则必然会通过，如果设置越低，则通过测试的概率越小，所以在实际ceph集群中，调高使用率低osd的reweight，和调低使用率高的osd的reweight，都可以让其使用率更靠近平均水平，也就是reweight重平衡的原理。

  而且由于rewieght不直接参与select过程，所以调整reweight对集群的影响远小于调整weight。当一个osd因为降低reweight而迁出部分pg后，后续如果将reweight调整回来，则其仍然承担原本应当承担的数据。（因为不影响select过程，select结果不变，通没通过过载测试的区别，所以承担的数据不会变化）

 &emsp新部署的osd和重新加回集群的osd，reweight都会被置为1.