主要目的是验证gfs的存储策略,是否是只考虑hash的结果,还是考虑机器的负载。
测试方案:
先在建一个volume,添加几个brick(几个brick不在同一台机器),然后存放一些文件,文件大小在1G左右,然后添加一个brick,这个brick与其他也不在同一个机器(虚拟机也可以),然后连续存储几个几百M的文件,看是否将这几个文件分布到新加的空brick还是随机分布在所有的brick。@李乾坤(kevinli)
测试环境:虚拟机四台,2G内存,40G硬盘空间
测试结果:
添加brick前:
三个brick,数据卷类型为distributed,文件大小总为1.1G,包含三个二级子目录和众多三级子目录。
将文件(1.2G)存放进volume,文件在各个brick的分布大小(du -h)情况如下:
409M
Brick
Brick1
Brick2
Brick3
大小
292M
466M
添加brick,成功。
第一次文件添加(330M)
+52M(461M)
+172M(464M)
+89M(555M)
43M
Brick
Brick1
Brick2
Brick3
Brick4
大小
第二次文件添加(248M)
+8K(461M)
+57M(521M)
+179M(734M)
+14M(57M)
Brick
Brick1
Brick2
Brick3
Brick4
大小
第三次添加文件(513M)
+117M(578M)
+171M(638M)
+112M(846M)
+237(251M)
Brick
Brick1
Brick2
Brick3
Brick4
大小
从以上测试结果可以看出,对于新增加的brick,glusterfs并没有特别对待,而是看做和旧的brick一样进行数据分配。这一测试是在分布巻下进行,在副本卷、切片卷下,之前的测试也表明,gkusterfs不会有特殊操作来区分新旧brick。