Glusterfs支持七种Volume,即Distribute卷、Stripe卷、Replica卷、Distribute stripe卷和Distribute replica卷,Distribute Stripe, Replica Volume卷这七种卷能够知足不一样应用对高性能、高可用的需求。php
基本卷:linux
(1) distribute volume:分布式卷算法
(2) stripe volume:条带卷服务器
(3) replica volume:复制卷网络
复合卷:并发
(4) distribute stripe volume:分布式条带卷分布式
(5) distribute replica volume:分布式复制卷ide
(6) stripe replica volume:条带复制卷高并发
(7) distribute stripe replicavolume:分布式条带复制卷工具
数据分布:
1、Distributed volume
2、Stripe volume
3、Replicated volume
4、distribute stripe volume
5、distribute replica volume
6、stripe replica volume
7、distribute stripe replica volume
基本卷:
(1) distribute volume:分布式卷
文件经过hash算法分布到全部brick server上,这种卷是glusterfs的基础和最大特色;实只是扩大的磁盘空间,若是有一个磁盘坏了,对应的数据也丢失,文件级RAID 0,不具备容错能力。
(2) stripe volume:条带卷
相似RAID0,文件分红数据块以Round Robin方式分布到brick server上,并发粒度是数据块,支持超大文件,大文件性能高;
(3) replica volume:复制卷
文件同步复制到多个brick上,文件级RAID 1,具备容错能力,写性能降低,读性能提高。
复合卷:
(4) distribute stripe volume:分布式条带卷
brickserver数量是条带数的倍数,兼具distribute和stripe卷的特色;
(5) distribute replica volume:分布式复制卷
brickserver数量是镜像数的倍数,兼具distribute和replica卷的特色,能够在2个或多个节点之间复制数据。
(6) stripe replica volume:条带复制卷
相似RAID 10
同时具备条带卷和复制卷的特色
(7) distribute stripe replicavolume:分布式条带复制卷
三种基本卷的复合卷
一般用于类Map Reduce应用
1、Distributed volume
在该模式下,并无对文件进行分块处理,文件直接存储在某个server节点上。“没有从新发明轮子”,这句话很好的归纳了这种GlusterFS的设计思路。由于使用了已有的本地文件系统进行存储文件,因此通用的不少linux命令和工具能够继续正常使用。这使得GlusterFS能够在一个比较稳定的基础上发展起来,也更容易为人们所接受。由于须要使用到扩展文件属性,因此其目前支持的底层文件系统有:ext三、ext四、ZFS、XFS等。
因为使用本地文件系统,一方面,存取效率并无什么没有提升,反而会由于网络通讯的缘由而有所下降;另外一方面,支持超大型文件会有必定的难度。虽然ext4已经能够支持最大16T的单个文件,可是本地存储设备的容量实在有限。因此若是有大量的大文件存储需求,能够考虑使用Stripe模式来实现,如考虑新建专门存储超大型文件的stripe卷。
功能:
将文件存放在服务器里,如上图,File1和File2存放在server1,而File3存放在server2,文件都是随机存储
2、Stripe volume
其实Stripe模式至关于raid0,在该模式下,系统只是简单地根据偏移量将文件分红N块(N个stripe节点时),而后发送到每一个server节点。server节点把每一块都做为普通文件存入本地文件系统中,并用扩展属性记录了总的块数(stripe-count)和每一块的序号(stripe-index)。stripe数必须等于volume中brick所包含的存储服务器数,文件被分红数据块,以Round Robin的方式存储在bricks中,并发粒度是数据块,大文件性能好
功能:
将文件存放在不一样服务器里,如上图,File被分割为6段,一、三、5放在server1,二、四、6放在server2
3、Replicated volume
Replicated模式,也称做AFR(AutoFile Replication),至关于raid1,即同一文件在多个镜像存储节点上保存多份,每一个replicated子节点有着相同的目录结构和文件。replicated模式通常不会单独使用,常常是以“Distribute+ Replicated”或“Stripe+ Replicated”的形式出现的。若是两台机的存储容量不一样,那么就如木桶效应,系统的存储容量由容量小的机器决定。replica数必须等于volume中brick所包含的存储服务器数,可用性高。建立一个两两互为备份的卷,存储池中一块硬盘损坏,不会影响到数据的使用,最少须要两台服务器才能建立分布镜像卷。
Replicated模式是在文件的级别上进行的(相比较于HDFS),并且在建立卷volume时就肯定每一个server节点的职责,并且只能人工的进行调整。这样的话就相对的不灵活,若是一个节点A出了问题,就必定要用新的节点去替代A,不然就会出现一些问题隐患。
在Replicated模式下,每一个文件会有以下几个扩展属性:
读写数据时,具体的状况以下:
读数据时:系统会将请求均衡负载到全部的镜像存储节点上,在文件被访问时同时就会触发self-heal机制,这时系统会检测副本的一致性(包括目录、文件内容、文件属性等)。若不一致则会经过changelog找到正确版本,进而修复文件或目录属性,以保证一致性。
写数据时:以第一台服务器做为锁服务器,先锁定目录或文件,写changelog记录该事件,再在每一个镜像节点上写入数据,确保一致性后,擦除changelog记录,解开锁。
若是互为镜像的多个节点中有一个镜像节点出现了问题,用户的读/写请求均可以正常的进行,并不会受到影响。而问题节点被替换后,系统会自动在后台进行同步数据来保证副本的一致性。可是系统并不会自动地需找另外一个节点来替代它,而是须要经过人工新增节点来进行,因此管理员必须及时地去发现这些问题,否则可靠性就很难保证。
功能:
将文件存放在服务器里,如上图,File1同时存在server1和server2,File2也是如此,至关于server2中的文件是server1中文件的副本。
4、distribute stripe volume
分布式的条带卷,volume中brick所包含的存储服务器数必须是stripe的倍数(>=2倍),兼顾分布式和条带式的功能。每一个文件分布在四台共享服务器上,一般用于大文件访问处理,最少须要 4 台服务器才能建立分布条带卷。
功能:
将文件存到不一样服务器里,如上图,File被分割成4段,一、3在server1(exp1)中,二、4在server1(exp2)中。server2(exp3)一、3存放server1(exp1)中的备份文件,server2(exp4)二、4存放server1(exp2)中的备份文件。
5、distribute replica volume
分布式的复制卷,volume中brick所包含的存储服务器数必须是 replica 的倍数(>=2倍),兼顾分布式和复制式的功能。
功能:
将文件备份随机存放在服务器里,如上图,server1(exp1)存放File1文件,Server1(exp2)存放File2文件。server2(exp3)存放File1的备份文件,server2(exp4)存放File2的备份文件。
6、stripe replica volume
功能:
将文件分割并备份随机存放在不一样的服务器里,如上图,File被分割4段,一、3存放在server1(exp1)上,二、4存放在server2(exp4),server1上的(exp3)存放server2(exp4)的备份文件,server2上的(exp2)存放server1(exp1)的备份文件。
7、distribute stripe replica volume
分布式条带复制卷分布条带数据在复制卷集群。为了得到最佳效果,你应该使用分布在高并发的条带复制卷环境下并行访问很是大的文件和性能是相当重要的。
功能:
将文件分割并备份随机存放在不一样服务器里,如上图,File被分割成4段,一、3存放在server1(exp1)中,二、4存放在server2(exp3)中。server1(exp2)存放server1(exp1)的备份文件,server2(exp4)存放server2(exp3)的备份文件。
参考资料:
http://www.gluster.com/products/gluster-file-system-architecture-white-paper/
http://www.gluster.com/products/performance-in-a-gluster-system-white-paper/
http://gluster.com/community/documentation/index.php/Main_Page
http://blog.csdn.net/liuaigui/