关于Gluster稳定性的一个BUG

这一段时间一直在研究Gluster集群文件系统,其技术架构和原理请参考前面的一篇文章“Gluster集群文件系统研究”。为了验证其所声称的高扩展、高可用、高性能的特点,我部署了一个较大规模的测试环境,4个I/O节点(即brick servers,DELL R510, 8GB内存,4块1TB SATA磁盘)和两个客户端节点(DELL R510, 16GB内存,2块SAS 300GB磁盘),进行了大量的系统测试工作,并开始着手源码深入阅读和分析。测试的结果总体上是令人满意的,能够达到官方所称的高扩展、高可用和高性能指标,可管理性、易用性也很好。但是Gluster(测试版本为3.2.1)当前的系统稳定性不足,测试中多次遇到文件目录无法创建、删除和读写的问题。

在自己尝试解决未果的情况下,我通过邮件列表向Gluster团队报告了该BUG(bugid=3132),没想到他们反应非常快,一个星期不到就给解决了,赞一个!

BUG描述

采用distributed + stripe卷,volume配置信息如下,

Volume Name: dhtstp
Type: Distributed-Stripe
Status: Started
Number of Bricks: 3 x 4 = 12
Transport-type: tcp
Bricks:
Brick1: 192.168.8.200:/mnt/sdb/dhtstp
Brick2: 192.168.8.201:/mnt/sdb/dhtstp
Brick3: 192.168.8.202:/mnt/sdb/dhtstp
Brick4: 192.168.8.203:/mnt/sdb/dhtstp
Brick5: 192.168.8.200:/mnt/sdc/dhtstp
Brick6: 192.168.8.201:/mnt/sdc/dhtstp
Brick7: 192.168.8.202:/mnt/sdc/dhtstp
Brick8: 192.168.8.203:/mnt/sdc/dhtstp
Brick9: 192.168.8.200:/mnt/sdd/dhtstp
Brick10: 192.168.8.201:/mnt/sdd/dhtstp
Brick11: 192.168.8.202:/mnt/sdd/dhtstp
Brick12: 192.168.8.203:/mnt/sdd/dhtstp
Options Reconfigured:
nfs.disable: off
nfs.addr-namelookup: off

客户端mount -t glusterfs 192.168.8.200:/dhtstp /mnt/dhtstp后,创建文件时出现“Invalid argument”错误,删除文件出现“No such file or directory”,客户端部分日志太多暂不提供。

BUG原因

stripe default setxattr works on first child. If the first cbk is not the first child, then we were loosing the xattrs. 

Stripe卷缺省情况下扩展属性工作在第一个节点,如果回调不是第一个节点的话,扩展属性会丢失,从而丢失了文件的布局信息。因此,导致文件不可访问的情况发生。

解决方法

应用Patch 7573, 其实代码只增加了4行,如下,

diff --git a/xlators/cluster/stripe/src/stripe.c b/xlators/cluster/stripe/src/stripe.c
index 4da0495..0d075e4 100644
--- a/xlators/cluster/stripe/src/stripe.c
+++ b/xlators/cluster/stripe/src/stripe.c
@@ -254,6 +254,10 @@  stripe_aggregate (dict_t *this, char *key, data_t *value, void *data)
                 }
 
                 *size = hton64 (ntoh64 (*size) + ntoh64 (*ptr));
+        } else {
+                ret = dict_set (dst, key, value);
+                if (ret)
+                        gf_log ("stripe", GF_LOG_WARNING, "xattr dict set failed");
         }
 
         return;

这个Patch我已经验证并向Gluster开发者进行了确认,相信在下一个版本中就会得到修正,暂时可以自己进行patch修复。

Gluster开始与2007年,终究还是时间短了一点,实现方面有些地方不是很好,稳定性和成熟必性方面还是有所欠缺。诸如StorNext, GPFS, Lustre, PVFS这些文件系统都是1999年左右开始的,经历了10多年考验都很成熟稳定了。还是那句话,生产环境应用Gluster还得谨慎,但是它确实是个架构良好的集群文件系统,未来发展空间很大,尤其是在云计算和云存储领域。

你可能感兴趣的:(分布式文件系统,GlusterFS)