gfd glusterFS。开源的分布式的文件系统
存储服务器、客户端、网络(可以使用NFS或samba组成网关连接各个节点的通信)
传统的分布式系统元服务器,元服务器保存存储节点的目录树信息。缺点:一旦元服务器故障,所有的存储节点全部失效
现在的分布式系统——GFS:取消了元服务器机制,数据横向扩展能力更强,可靠性更强,存储效率更高

(1)扩展性更强、性能出色
(2)高可用,可以自动对文件进行复制,也可以多次复制,确保数据总是可以访问,即便硬件故障也能正常访问
(3)全局统一的命名空间,所有节点都在一个分支的管理之下,客户端访问分支节点即可
(4)弹性卷,不同服务器上的不同的硬盘分区组成一个分布式卷,可以动态扩容(类似于LVM,不同硬盘上的不同分区组成逻辑上的硬盘)
(5)基于标准协议,GFS支持多种存储服务,比如NFS、FTP、HTTP以及GFS自带的协议,应用协议可以直接使用数据,不需要做任何修改
(1)brick(存储块):存储服务器提供的用于物理存储的专用分区,是GFS中的基本存储单元,也是对外提供服务的存储目录。是由服务器和目录的绝对路径组成
格式:server:dir
192.168.233.10:/opt/gfs
node1:/opt/gfs
(2)volume(逻辑卷):一个逻辑卷就是一组brick的集合。管理GFS就是管理这些逻辑卷
(3)fuse(GFS的内核模块):允许用户创建自己的文件系统
(4)vfs(虚拟端口):内核空间对用户提供的访问磁盘的接口
(5)glusterd(后台管理进程):服务端在每个存储节点上都要运行

(1)分布式卷:GFS的默认卷类型
(2)复制卷(镜像化)
(3)分布式复制卷(工作中使用)
(4)条带卷:6.0版本后已取消
(5)分布式条带卷:已取消
文件数据通过hash算法分布到设置的所有brick上。属于raid0,没有容错机制。在分布式卷的模式下,没有对文件分块,直接存储在某个server的节点上,且存取效率也没有提高,简而言之,直接使用本地文件系统进行存储

类似于raid 1。文件会同步在多个brick server上,读性能提升,写性能稍差,有冗余功能,坏一个节点不影响数据,但要备份数据,磁盘利用率50%

两两复制。文件会在组内同步,不同的组之间数据不一定同步
情况1:

情况2:

实验思路:
(1)分布式复制卷

(2)复制卷

(3)分布式

实验条件:四台服务器、一台客户端
| 主机名 | IP地址 | 存储服务器文件存放目录 | 组件 |
| node1 | 20.0.0.10 | /data/test1 /data/test2 /data/test3 | GFS服务 |
| node2 | 20.0.0.20 | /data/test1 /data/test2 /data/test3 | GFS服务 |
| node3 | 20.0.0.30 | /data/test1 /data/test2 /data/test3 | GFS服务 |
| node4 | 20.0.0.40 | /data/test1 /data/test2 /data/test3 | GFS服务 |
| 客户端 | 20.0.0.13 | GFS服务 |
实验步骤:
1、在四台服务器节点上
(1)修改主机名

![]()
![]()
(2)安装GFS服务
安装官网源yum -y install centos-release-gluster
安装服务yum -y install glusterfs glusterfs-server glusterfs-fuse glusterfs-rdma


(3)映射主机名和IP地址vim /etc/hosts

2、在node1节点上添加节点服务器,形成存储信任池(在一个节点上操作即可)
分布式复制卷:node1:/data/test1 node2:/data/test1 node3:/data/test1 node4:/data/test1
(1)创建
mkdir /data
gluster volume create fenbufuzhi replica 2 node1:/data/test1 node2:/data/test1 node3:/data/test1 node4:/data/test1 force

(2)开启卷【必须】
gluster volume start fenbufuzhi
(3)查看卷的信息
gluster volume info fenbufuzhi

(4)查看卷的列表gluster volume list

4、配置客户端
(1)映射主机名和IP地址vim /etc/hosts

(2)挂载【二选一】
①永久挂载存储服务器节点
![]()

②临时挂载![]()
5、测试
客户端
存储服务器




结论:根据分布式复制卷的机制、策略和存储服务器的数量,在客户端创建文件会同步复制到所有节点服务器上
注:此时分布式复制的策略是replica 2,两两成组,在客户端创建同样的文件,数据会分散复制到两组服务器中【组内互补,组间完整备份】
6、模拟故障
关闭node1节点的gluster服务![]()
测试存储服务器能否同步存储数据
客户端
![]()
存储服务器



结论1:节点故障不影响数据同步备份
7、故障恢复
恢复node1节点的gluster服务
![]()
测试存储服务器能否同步存储数据
客户端

存储服务器




结论2:节点恢复正常数据同步备份
结论:分布式复制卷的存储服务器节点故障与否均不影响客户端的数据同步备份到存储服务器
复制卷:node1:/data/test2 node2:/data/test2 node3:/data/test2 node4:/data/test2
gluster volume create fenbufuzhi replica 4 node1:/data/test2 node2:/data/test2 node3:/data/test2 node4:/data/test2 force
9、配置客户端
临时挂载存储服务器节点
10、测试
客户端
存储服务器




结论:根据复制卷的机制和策略replica 4,各自成组,每个组内完整备份数据,组间完整备份数据
分布卷:node3:/data/test3 node4:/data/test3
gluster volume create fenbu node3:/data/test3 node4:/data/test3 force
12、配置客户端
挂载存储服务器节点

13、测试
客户端
存储服务器


结论:根据分布式卷的机制,数据会分散复制到两组服务器中【组内互补】
14、访问控制
(1)拒绝客户端访问
gluster volume set fenbufuzhi auth.reject 20.0.0.13
![]()
客户端

(2)允许网段访问
gluster volume set fenbufuzhi auth.reject 20.0.0.*

15、查看所有卷的状态gluster volume status

16、停止存储服务器gluster peer datach node3

节点上有卷不允许停止节点
直接停止此服务来停止节点
17、删除卷【先停再删】
gluster volume stop node1
gluster volume delete fenbufuzhi

