分布式文件系统GlusterFS_lustre和分布式nfs

GlusterFS是一个高层次的分布式文件系统解决方案。通过增加一个逻辑层，对上层使用者掩盖了下面的实现，使用者不用了解也不需知道，文件的存储形式、分布。

内部实现是整合了许多存储块（server）通过Infiniband RDMA或者 Tcp/Ip方式互联的一个并行的网络文件系统，这样的许多存储块可以通过许多廉价的x86主机，通过网络搭建起来。

其相对于传统NAS 、SAN、Raid的优点就是：

1.容量可以按比例的扩展，且性能却不会因此而降低。

   2.廉价且使用简单，完全抽象在已有的文件系统之上。

   3.扩展和容错设计的比较合理，复杂度较低。扩展使用translator方式，扩展调度使用scheduling接口，容错交给了本地的文件系统来处理。

   4.适应性强，部署方便，对环境依赖低，使用，调试和维护便利。

支持主流的linux系统发行版，包括 fc，ubuntu，debian，suse等，并已有若干成功应用。

[转：GlusterFS源码分析后随笔 http://www.cnblogs.com/thinkinlove/archive/2007/11/20/966195.html ]

Glusterfs是一个存储空间和访问效率都可以线性增加的一个分布式文件系统，网上资料除了gluster.org以外，几乎没有什么有关的介绍了。

通过对源码的审阅，个人感觉，比较主要的是把程序的整体结构理清，扩展方式弄明白在向下看具体的实现是比较好的。

该系统扩充的方式是使用了translator的模式，具体我还参考了《现代操作系统》中分布式文件系统章节和GNU/HURD 中解释translator的部分，后者主要是在gnu的网站上。

数 据结构上讲，整个文件系统中节点构成了一棵树，而且每个节点的操作是通过某个translator来工作的，一个节点可以附着很多的 translator。所有的translator都要实现xlator结构体和相关的xlator_fops、xlator_mops两个“成员函数的 结构体”，

Hurd 另一个重要的概念就是所谓的 translator。您可以将 translator 视为您熟习的 UNIX 其档案系统特色的实现，像 是 mount points、devices 还有 symbolic links。在 Hurd 档案系统中，每个档案都被连结到一个 叫 "translator" 的程序。当使用者程序存取这个档案时，控制权就转交给 translator 来处理。如果存取动作是读取 disk 中 真正的档案，则这种档案系统格式的 translator 会向 disk 要求资料，并传回应用程序。如果存取的是 device，则这 个 device 的 driver 会处理。同样的，在存取 symbolic link 时，translator 会直接导向到指定的位置，或是其 它的档案架构。

目前为止，translator 做到了标准 UNIX 系统无法达到的功能，它提供了 files、 device 与 symbolic link 一致的存取动作。Hurd 的 translator 还可以应用于任何种类的资料。以 FTP 存取为 例，对方系统中的档案可以直接对应至您的档案结构中 (像是 /ftp/ftp.mydomain.com/pub/myfile)，您可使用原有的工具 进来拷贝、删除或是编辑。Translator 会转换到对应 FTP 动作。您可以想像其它的 translator 有那些功用，像是您可以使 用 cat 或是 ls 等工具透过 translator 来流览数据库的内容。或是网管工具可以写成 translator，网络内所有的电脑可以对 应到一个目录。Cat 可以列出网络的资料，像是机器的 IP 位址。Gateway 可以视为目录，所以执行 cd 到一个 gateway 时，可以 看到这个 gateway 下子网域所有的机器。与 server 相同的一点，translator 不要须额外的权限。任何人都可以开发自己 的 translator，除错并尝试完成，让其它使用者也可以一起使用。

从xlator “继承”下来的操作如果不自己定义，那么就会使用默认的设置，这个在default.c里面定义。当然自己定义的操作并赋值，这个过程有些象子类覆盖父类 的操作，平行来看也就是多态。当然这是从面向对象角度来看的，该系统很多地方都使用了面向对象的思想来设计的，这个和linux 2.6以后的内核模块设计是异曲同工的。

那么一般可以这样识别一个用c实现的Class关键字的类：

例（对源文件有些修改）：

struct A {

char *name;

char *type;                   //成员

struct A *this;                 //this 指针

struct xlator_fops *fops;     //成员操作结构体1

struct xlator_mops *mops;        //成员操作结构体 2

void (*fini) (struct A *this);   // 析构函数，垃圾清理

int32_t (*init) (struct A *this);//构造函数，初始化

event_notify_fn_t notify;     //成员。。

dict_t *options;

glusterfs_ctx_t *ctx;

inode_table_t *itable;

char ready;

void *private;

};

    1.一个struct 定义里面包含一个指针 该指针的类型是该struct定义的类型。2.上面的struct内部成员中含有其他结构体的指针，象xlator_fops就是这里提到的其他结构体的指针，该结构体里面全部都是指向函数的指针，也就是成员函数 了。

当然此处也可以把xlator_fops里面的成员都释放到struct A里面， 但是这样这个struct就显得有些臃肿了，，毕竟成员函数还是不少的。上面这个例子还有两个只有类才具备的析构函数，和构造函数。

glusterfs_ctx 控制了全局的信息，很多地方传输都是使用它来传递的，一个典型的环境类。初始化些东西也是针对它来做的。

Redhat GFS和Glusterfs的目的类似，都是以全局在一个命名空间下而通过访问其他节点获取数据的。此处没有性能比较。

Lustre也是一个开源基于GNU lisence的集群文件系统，网站资源比较丰富，开发者的资源也比较多，中文资料也不少，sun公司收购了clusterfs公司，拥有了此技术。

下面地址显示的是lustre 与glusterfs做相当命令所需时间的比较：

http://www.gluster.org/docs/index.php/GlusterFS_1.3.pre2-VERGACION_vs_Lustre-1.4.9.1_Various_Benchmarks

下面的地址是NFS与glusterfs性能的测试对比：

http://www.gluster.org/docs/index.php/GlusterFS_1.2.1-BENKI_Aggregated_I/O_vs_NFSv4_Benchmark

Ok - I just spent the last 2 hours on IRC with the glusterFS dev team -- they are definitely around and active. They have been thinking/working on glusterFS for about a year and half, the first active commit was back in September. It is very active. These guys are very responsive and very intrigued by S3 and EC2. Some of them come from old VA Linux days, and they say they have a good relationship with the Amazon folks -- anyone from Amazon want to jump in?? 

The whole glusterFS framework is designed to be "pluggable" through "translators". Their line was "why write a filesystem when you can write a translator". So by writing a storage/s3 translator, the rest of glusterFS just "works" and you/me don't have to reinvent the wheel for all the rest of the filesystem details. That is what we are working through now. (They took a lunch break hehe). 

Let me do my best to answer the questions I've seen so far: 

Q: Did you get it running within EC2? 
A: Yes -- I use the CentOS4.4 AMI as my base. After adding fuse.ko and the Fuse rpms, I was able to build and install gluster on some storage "brick" instances and a client glusterfs instance quite easily. Performance was way faster than my muckFS. They also suggested I build a custom fuse.ko using their code instead of the stock fuse kernel for even better performance. 


Q: Does GlusterFS aggregate storage across all connected nodes (i.e. Machine1 has 1GB, Machine2 has 1GB, Machine3 has 1GB, does the totalvolume that can be mounted equal 3GB)? 
A: Yes -- in my test config of 1 client and 2 server bricks, my client sees the aggregate of the 2 server bricks as: 
$ df -h 
Filesystem            Size Used Avail Use% Mounted on 
/dev/sda1             4.0G 2.0G 1.8G 54% / 
/dev/sda2             147G 206M 140G   1% /mnt 
glusterfs:28845       294G 520M 279G   1% /mnt/glusterfs 

Q: Can volumes/bricks be added "on the fly", for example if you bring anew node/brick online can the volume be dynamically expanded or reducedbased upon adding or deleting bricks, respectively? 
A: At this point, it sounds like you would need to do a remount, although they discussed the idea of on-the-fly in the future. This is part of the larger reason for my muckOS project -to manage the distribution of config files and restarting of services when adding nodes to clusters for things like glusterFS or MySQL etc. 

Q: Does GlusterFS support any type of parity or RAID-style architecture, in the event a node/brick goes down? 
A: They are releasing the Automatic File Replication "translator" in 15 days for RAID 1 type mirroring. You can configure how many times a file should be replicated - even my file type. Also, the distribution of files to "bricks" has 4 different "translator" plugin options - random, round robin, NUFA (ie NUMA for files) and ALU - a least usage algorithm. 

Q: How active is the project? 
A: while the list may not be active, the IRC channel sure is -- a good chunk of their development team spent the morning with me. 

I know there are more questions, but those are the ones I have answers for so far. 

These guys seem very interested in writing a storage/s3 "translator" for glusterFS.   Since glusterFS is already async in its writes, dealing with S3 as async persistent storage is not a problem. 

More info to come as I learn it... :)