数据量大时osd出现数据分布不均匀

2018-03-26

字数统计: 1.2k字 | 阅读时长≈ 5分

最近在测试ceph的pg相关功能中，留意了一下各个osd的数据分布情况，发现不同的osd之间数据分布差异很大，全部盘都是HDD且容量都是8T

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

测试阶段就该做好技术调研啊~

集群的情况

首先用ceph osd df查看osd的具体容量情况：

ID CLASS WEIGHT  REWEIGHT SIZE  USE    AVAIL  %USE  VAR  PGS		
 0   hdd 7.27699  1.00000 7452G  4103G  3348G 55.07 0.90  94		
 1   hdd 7.27699  1.00000 7452G  4553G  2898G 61.10 1.00  78		
 2   hdd 7.27699  1.00000 7452G  4376G  3075G 58.73 0.96  85		
 3   hdd 7.27699  1.00000 7452G  4914G  2537G 65.94 1.08 105		
 4   hdd 7.27699  1.00000 7452G  4639G  2812G 62.25 1.02  86		
 5   hdd 7.27699  1.00000 7452G  4549G  2902G 61.06 1.00  90		
12   hdd 7.27699  1.00000 7452G  5083G  2368G 68.21 1.11  99		
16   hdd 7.27699  1.00000 7452G  4814G  2637G 64.60 1.05  83		
17   hdd 7.27699  1.00000 7452G  4458G  2993G 59.83 0.98  91		
19   hdd 7.27699  1.00000 7452G  4196G  3255G 56.31 0.92  85		
 6   hdd 7.27699  1.00000 7452G  4279G  3172G 57.43 0.94  86		
 7   hdd 7.27699  1.00000 7452G  4993G  2458G 67.01 1.09  95		
 8   hdd 7.27699  1.00000 7452G  4637G  2814G 62.23 1.02  90		
 9   hdd 7.27699  1.00000 7452G  4101G  3350G 55.04 0.90  85		
10   hdd 7.27699  1.00000 7452G  4108G  3343G 55.13 0.90  92		
11   hdd 7.27699  1.00000 7452G  5349G  2102G 71.79 1.17 102		
13   hdd 7.27699  1.00000 7452G  5890G  1561G 79.04 1.29  98		
14   hdd 7.27699  1.00000 7452G  3567G  3884G 47.87 0.78  76		
15   hdd 7.27699  1.00000 7452G  3831G  3620G 51.42 0.84  78		
18   hdd 7.27699  1.00000 7452G  4903G  2548G 65.80 1.07  94		
                    TOTAL  145T 91352G 57688G 61.29		
MIN/MAX VAR: 0.78/1.29  STDDEV: 7.08

可以看到，osd.15仅使用了51.42%的容量而osd.13则使用了79.04%的容量，二者相差近30%，在集群数据量91T的情况下，30%的数据就非常多了，并且，在集群需要持续拓展、长期运行的情况下，它们的差距恐怕会进一步扩大
对于这种osd容量差距大的情况，研读了国内大神徐小胖的PG对数据分布的影响后恍然大悟，我们即使是测试环境，数据也往往会在百T之上，并且都是小文件，这种情况下，存储池的pg分布问题就非常突出
看了下集群的存储池pg情况：

[xxx@ceph-c43 ~]$ sudo ceph osd dump |grep num
pool 6 'default.rgw.buckets.index' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 512 pgp_num 512 last_change 3071 lfor 0/2033 flags hashpspool stripe_width 0 application rgw
pool 7 '.rgw.root' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 2908 flags hashpspool stripe_width 0 application mon
pool 8 'default.rgw.control' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 2908 flags hashpspool stripe_width 0 application mon
pool 9 'default.rgw.meta' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 2908 flags hashpspool stripe_width 0 application mon
pool 10 'default.rgw.log' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 32 pgp_num 32 last_change 2908 flags hashpspool stripe_width 0 application mon
pool 11 'default.rgw.buckets.data' replicated size 2 min_size 1 crush_rule 0 object_hash rjenkins pg_num 1024 pgp_num 1024 last_change 2908 lfor 0/2024 flags hashpspool stripe_width 0 application mon

然后再查看了一下各个存储池的用量：

[xxx@ceph-c43 ~]$ sudo ceph df
GLOBAL:
    SIZE     AVAIL      RAW USED     %RAW USED
    145T     54203G       94836G         63.63
POOLS:
    NAME                          ID     USED       %USED     MAX AVAIL     OBJECTS
    default.rgw.buckets.index     6           0         0        18357G         1277
    .rgw.root                     7        1113         0        18357G            4
    default.rgw.control           8           0         0        18357G            8
    default.rgw.meta              9        2689         0        18357G           13
    default.rgw.log               10          0         0        18357G            0
    default.rgw.buckets.data      11     45385G     71.20        18357G     78896678

一目了然，default.rgw.buckets.data存放了近99.9999%的数据，而default.rgw.buckets.index却只放了少量的数据，但是default.rgw.buckets.index却使用了512个pg，这样算下来，有大量的pg没有存放数据，就被映射到osd上，由于crushmap映射的时候是根据pg而不考虑存储池及pg的实际存放数据量，使得那些没有放数据的pg(例如default.rgw.buckets.index的pg)占用了大量osd资源，因而这些osd的容量就会占用得少一些
解决方案有两个：
1、使用reweight对占用高的osd进行降权重操作，使得其上的pg迁往其他osd，但这样也只是暂时解决问题，不能从根本上消灭这个问题
2、在建存储池的时候就该想到，要提前规划pg的数目，最直接的办法就是在PG Calc上进行评估，在一开始的时候就控制好各个存储池的比例，例如上述存储池，除了default.rgw.buckets.data，其他存储池大可以只分配16个pg，如果后续出现扩展集群的场景，再来增加pg也可以

本文作者： 奋斗的松鼠
本文链接： http://www.strugglesquirrel.com/2018/03/26/数据量大时osd出现数据分布不均匀/
版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！