关于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还得谨慎，但是它确实是个架构良好的集群文件系统，未来发展空间很大，尤其是在云计算和云存储领域。