- 1简易C语言词法分析器_编制一个能够分析给定范围内的整数、标识符的词法分析器
- 2CentOS GitLab安装_centos8.2离线安装gitlab
- 3【万字长文】R语言入门学习路线与资源汇总
- 4anacron程序_anacron进程很多
- 5软件测试（敏捷开发、迭代模型）_1.3.迭代模型的基本概念和特点
- 6最新Tuxera NTFS2024破解版mac读写NTFS磁盘工具
- 7[附源码]计算机毕业设计springboot环境保护宣传网站_毕业设计核辐射宣传平台
- 8STM32中的位带(bit-band)操作_头文件定义pbin(6)时,说明
- 9深度学习优化算法演变_优化算法的演进
- 10（二）ncnn | Windows10 + Android Studio环境配置_set_vulkan_compute failed, network use_vulkan_comp
GlusterFS 集群安装及使用(二)_gluster-setgfid2path
赞
踩
GlusterFS 集群安装及使用
一、GlusterFS、MFS、Ceph的比较
glusterfs、mfs、Ceph、Luster 相等为分布式文件系统，单纯的优缺点是无法描述的，下列是从它们的 Metadata server 、fuse、冗余、数据可靠性、故障恢复、扩展、适用场景、领域等进行简单比对。
（1.） MFS(moosefs)的特点
Metadata server： 单个MDS，存在单点故障、并发瓶颈
fuse：支持
访问接口：POSIX
冗余：多副本
数据可靠性：由数据的多副本提供可靠性。
故障恢复：手动恢复
扩展性：增加存储服务器，可以提高容量和文件操作性能。但是由于 不能增加MDS，因此元数据操作性能不能提高，是整个系统的瓶颈
适合场景：大量小文件读写
缺点：存在单点故障
（2.）GFS(glusterfs)的特点
metadata server：没有MDS，不存在单点故障。靠运行在各个节点上的动态算法来代替MDS,不需同步元数据,无硬盘I/O瓶颈。
fuse: 支持
访问接口：POSIX
冗余：通过镜像的方式
数据可靠性：通过镜像提供可靠性
故障恢复：当节点、硬件、磁盘、网络发生故障时，系统会自动处理这些故障，管理员不需介入
扩展性：容量可以扩展
适用场景：适合大文件
缺点：无元数据服务器，堆栈式架构(基本功能模块可以进行堆栈式组合，实现强大功能)。具有线性横向扩展能力。由于没有元数据服务器，因此增加了客户端的负载，占用相当的CPU和内存。但遍历文件目录时，则实现较为复杂和低效，需要搜索所有的存储节点。因此不建议使用较深的路径
（3.）Ceph的特点
metadata server：多个MDS，不存在单点故障和瓶颈。MDS可以扩展，不存在瓶颈
fuse: 支持
访问接口：POSIX
冗余：多副本
数据可靠性：由数据的多副本提供可靠性。
故障恢复：当节点失效时，自动迁移数据、重新复制副本。
扩展性：可以增加元数据服务器和存储节点。容量可扩展。文件操作性能可扩展。元数据操作性能可扩展
适用场景：小文件
缺点:略，自行研究，之后会更新
二、GFS集群安装部署
此安装背景是由于k8s的需要进行安装的，也可另为它用。
（1.）准备环境
由于资源有限，此次采用2台机器进行搭建
（1.1）服务器准备
192.168.0.15 master
192.168.0.14 master
192.168.0.10 client
系统信息：
[root@kube-slave02 ~]# cat /etc/redhat-release
CentOS Linux release 7.7.1908 (Core)
[root@kube-slave02 ~]# uname -r
3.10.0-1062.el7.x86_64
- 1
- 2
- 3
- 4
关闭防火墙，selinux
[root@kube-slave02 ~]# systemctl stop firewalld.service
[root@kube-slave02 ~]# systemctl disable firewalld.service
[root@kube-slave02 ~]# setenforce 0
setenforce: SELinux is disabled
[root@kube-slave02 ~]# getenforce
Disabled
- 1
- 2
- 3
- 4
- 5
- 6
（2.）搭建步骤
（2.1）配置本地hosts
[root@kube-slave02 ~]# vim /etc/hosts
192.168.0.14 kube-slave01
192.168.0.15 kube-slave02
- 1
- 2
- 3
（2.2）安装glusterfs
在两台服务器上分别安装，我用的yum相对来说较为简单，只安装server端即可，做briks，client不需要
[root@kube-slave02 ~]# yum install -y centos-release-gluster
[root@kube-slave02 ~]# yum install -y glusterfs glusterfs-server glusterfs-fuse glusterfs-rdma
[root@kube-slave02 ~]# systemctl start glusterd && systemctl enable glusterd && systemctl status glusterd
● glusterd.service - GlusterFS, a clustered file-system server
Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: enabled)
Active: active (running) since 三 2020-08-19 09:30:05 CST; 1h 23min ago
Docs: man:glusterd(8)
Main PID: 18681 (glusterd)
CGroup: /system.slice/glusterd.service
└─18681 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO
8月 19 09:30:04 kube-slave02 systemd[1]: Starting GlusterFS, a clustered file-system server...
8月 19 09:30:05 kube-slave02 systemd[1]: Started GlusterFS, a clustered file-system server.
[root@kube-slave02 ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
（2.3）将slave添加/删除到gluster集群中
注意，因为没有MDS,所以添加的时候可以在任意服务器上进行，添加的时候，不需要添加localhost，即：在node1上添加其他slave时，不在需要添加node1(默认会自动添加)直接添加其他节点即可，如下：
[root@kube-slave02 ~]# gluster peer status
Number of Peers: 0
[root@kube-slave02 ~]# gluster peer probe kube-slave01
peer probe: success.
[root@kube-slave02 ~]# gluster peer status
Number of Peers: 1
Hostname: kube-slave01
Uuid: bfb8639d-6e18-4087-8726-4142f24b5919
State: Peer in Cluster (Connected)
[root@kube-slave02 ~]# gluster pool list
UUID Hostname State
bfb8639d-6e18-4087-8726-4142f24b5919 kube-slave01 Connected
beaa6e72-a165-42d1-a61f-2ed14600ca58 localhost Connected
[root@kube-slave02 ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
注意：使用probe添加节点时,如果添加的是IP地址那么相应的显示的也是IP地址，如果添加的是hostname，显示的也是hostname，据情况而定
如果移除节点如下:
[root@kube-slave02 ~]# gluster volume info
No volumes present
[root@kube-slave02 ~]# gluster peer detach kube-slave01
All clients mounted through the peer which is getting detached need to be remounted using one of the other active peers in the trusted storage pool to ensure client gets notification on any changes done on the gluster configuration and if the same has been done do you want to proceed? (y/n) y
peer detach: success
[root@kube-slave02 ~]# gluster pool list
UUID Hostname State
beaa6e72-a165-42d1-a61f-2ed14600ca58 localhost Connected
[root@kube-slave02 ~]# gluster peer status
Number of Peers: 0
[root@kube-slave02 ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
注意：以上移除节点是在没有volume的时候，可以直接移除，如果有volume,以及volume中存在数据时，此方式不适用，后边会说
此时gluster集群多节点已完成！！！
三、GFS卷的使用
在创建之前，需要在自己服务器上，找个分区，本次添加的新硬盘，自行配置
（1.） 分布式卷
文件通过hash算法分布到所有brick server上，这种卷是glusterfs的基础和最大特点；只是扩大磁盘空间，如果有一个磁盘坏了，对应的数据也丢失，文件级RAID 0，不具有容错能力
（1.1）创建分布式卷
[root@kube-slave02 ~]# gluster volume create fenbushi-01 192.168.0.15:/nfs/fenbushi-01 kube-slave01:/nfs/fenbushi-01 force volume create: fenbushi-01: success: please start the volume to access data [root@kube-slave02 ~]# gluster volume list fenbushi-01 [root@kube-slave02 ~]# gluster volume info Volume Name: fenbushi-01 Type: Distribute Volume ID: 5205bd57-68ae-4f37-a35d-493cbf5e28cb Status: Created Snapshot Count: 0 Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: 192.168.0.15:/nfs/fenbushi-01 Brick2: kube-slave01:/nfs/fenbushi-01 Options Reconfigured: transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on [root@kube-slave02 ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
此时可以看到现在已经存在一个分布式卷组，注意：本机节点会自动进行添加，通过IP地址进行识别，如果需要只有两个节点，只需要指定另外一个节点即可，如果节点超过2个，必须指明那些节点。多个节点之间路径可以不同，但是为了方便维护管理，建议目录相同
（1.2）挂载分布式卷
因为分布式卷现在是create状态，虽然现在slave直见可以进行数据的同步，但是无法让客户端挂载，所以创建完成之后，需要启动卷。挂载使用nfs挂载即可
[root@kube-slave02 ~]# gluster volume start fenbushi-01 volume start: fenbushi-01: success [root@kube-slave02 ~]# gluster volume info fenbushi-01 Volume Name: fenbushi-01 Type: Distribute Volume ID: 5205bd57-68ae-4f37-a35d-493cbf5e28cb Status: Started Snapshot Count: 0 Number of Bricks: 2 Transport-type: tcp Bricks: Brick1: 192.168.0.15:/nfs/fenbushi-01 Brick2: kube-slave01:/nfs/fenbushi-01 Options Reconfigured: transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on [root@kube-slave02 ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
客户端挂载：
[root@kube-master ~]# yum -y install nfs-utils
[root@kube-master ~]# mkdir /linux
[root@kube-master ~]# mount.glusterfs 192.168.0.15:fenbushi-01 /linux/
[root@kube-master ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
192.168.0.15:fenbushi-01 79G 900M 75G 2% /linux
- 1
- 2
- 3
- 4
- 5
- 6
注意：此时挂载的数据类型为glusterfs 且挂载的容量为两个slave节点的总和
测试：
[root@kube-master ~]# cd /linux
[root@kube-master linux]# echo "1111" >> 1.txt
[root@kube-master linux]# cat 1.txt
1111
- 1
- 2
- 3
- 4
注意，因为分布式卷采用的是hash算法分布到所有brick 上的 因此，文件有可能存在kube-slave01 上，也可能 存在kube-slave02上，此处忽略，自行查看。
（2.） 条带卷
类似 RAID0，文件分成数据块以 Round Robin 方式分布到 brick server 上，并发粒度是数据块，支持超大文件，大文件的读写性能高
（2.1） 创建条带卷
[root@kube-slave02 ~]# gluster volume create tiaodai-01 stripe 2 192.168.0.15:/nfs/fuzhi kube-slave01:/nfs/fuzhi
stripe option not supported
- 1
- 2
因为stripe 在6.1版本之后已经被弃用了，所以不支持了。
（2.2） 挂载条带卷
（3.） 复制卷
（3.1） 创建复制卷
[root@kube-slave02 nfs]# gluster volume create fuzhi-01 replica 3 192.168.0.15:/nfs/fuzhi/ kube-slave01:/nfs/fuzhi/ kube-master:/gluster/nfs volume create: fuzhi-01: success: please start the volume to access data [root@kube-slave02 nfs]# gluster volume info fuzhi-01 Volume Name: fuzhi-01 Type: Replicate Volume ID: cbc288d5-0502-405c-8b46-196ff71f8577 Status: Created Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: 192.168.0.15:/nfs/fuzhi Brick2: kube-slave01:/nfs/fuzhi Brick3: kube-master:/gluster/nfs Options Reconfigured: transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on performance.client-io-threads: off [root@kube-slave02 nfs]# gluster volume start fuzhi-01 volume start: fuzhi-01: success [root@kube-slave02 nfs]# gluster volume info fuzhi-01 Volume Name: fuzhi-01 Type: Replicate Volume ID: cbc288d5-0502-405c-8b46-196ff71f8577 Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: 192.168.0.15:/nfs/fuzhi Brick2: kube-slave01:/nfs/fuzhi Brick3: kube-master:/gluster/nfs Options Reconfigured: transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on performance.client-io-threads: off
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
注意：两个节点容易脑裂，真正的生产环境，包括gfs，以及其他集群尽量保持在最低奇数(3)节点，此处为三个节点
（3.2） 挂载复制卷
挂载采用nfs，参考分布式卷，因为复制卷所以磁盘容量只显示最小的，如果50G、40G、30G 那么最终流量为30G，
[root@kube-master ~]# mount.glusterfs 192.168.0.15:fuzhi-01 /fuzhi/
[root@kube-master ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
192.168.0.15:fuzhi-01 40G 451M 38G 2% /fuzhi
[root@kube-master fuzhi]# touch {1..99}.txt
- 1
- 2
- 3
- 4
- 5
此时复制卷已制作完成，
（4.） 分布式复制卷
Brick server 数量是镜像数的倍数，兼具 distribute 和 replica 卷的特点,可以在 2 个或多个节点之间复制数据。分布式的复制卷，volume 中 brick 所包含的存储服务器数必须是 replica 的倍数(>=2倍)，兼顾分布式和复制式的功能。
（4.1） 创建分布式复制卷
生产环境中节点务必保持在4个节点以及偶数增长，此处为4节点
[root@kube-slave02 ~]# gluster volume create ff-01 replica 4 192.168.0.15:/nfs/ff kube-master:/gluster/ff kube-slave01:/nfs/ff kube-slave03:/home/ff force volume create: ff-01: success: please start the volume to access data [root@kube-slave02 ~]# gluster volume info ff-01 Volume Name: ff-01 Type: Replicate Volume ID: f4261224-f95a-4e29-8de4-402723d09a8c Status: Created Snapshot Count: 0 Number of Bricks: 1 x 4 = 4 Transport-type: tcp Bricks: Brick1: 192.168.0.15:/nfs/ff Brick2: kube-master:/gluster/ff Brick3: kube-slave01:/nfs/ff Brick4: kube-slave03:/home/ff Options Reconfigured: transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on performance.client-io-threads: off [root@kube-slave02 ~]# gluster volume start ff-01 volume start: ff-01: success
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
（4.2） 挂载分布式复制卷
[root@kube-slave03 ~]#mount.glusterfs 192.168.0.15:ff-01 /ff/
[root@kube-slave03 ~]# df -h
文件系统 容量 已用 可用 已用% 挂载点
192.168.0.15:ff-01 71G 2.5G 67G 4% /ff
[root@kube-slave03 ff]# cd /ff
[root@kube-slave03 ff]# touch {1..10}.txt
[root@kube-slave03 ff]# ls
10.txt 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
注意：此时可以看到容量为四个卷组相加之后除以2的容量 N+N+N+N/2,因为是分布式复制卷，具体的容量跟replica指定的有关系，如果后期进行扩容时，replica常见时为2 那么之后扩容的节点需为,4,8,10,12 等
查看gluster集群，如下：
[root@kube-slave01 ~]# ls /nfs/one/
4.txt 8.txt 9.txt
[root@kube-slave01 ~]#
- 1
- 2
- 3
[root@kube-slave02 ~]# ls /nfs/one/
4.txt 8.txt 9.txt
[root@kube-slave02 ~]#
- 1
- 2
- 3
[root@kube-master ~]# ls /gluster/one/
10.txt 1.txt 2.txt 3.txt 5.txt 6.txt 7.txt
[root@kube-master ~]#
- 1
- 2
- 3
[root@kube-slave03 ~]# ls /home/one/
10.txt 1.txt 2.txt 3.txt 5.txt 6.txt 7.txt
[root@kube-slave03 ~]#
- 1
- 2
- 3
总结：由此可以结论，分布式复制卷将数据文件分布在多个复制集（replicated sets ）中，每个复制集中数据有镜像冗余
（5.） 分布式条带卷
（5.1） 创建分布式条带卷
[root@kube-slave02 ~]# gluster volume create tiaodai-01 stripe 2 kube-slave03:/home/tt kube-slave01:/nfs/tt 192.168.0.15:/nfs/tt kube-master:/home/tt
stripe option not supported
Usage:
volume create <NEW-VOLNAME> [stripe <COUNT>] [[replica <COUNT> [arbiter <COUNT>]]|[replica 2 thin-arbiter 1]] [disperse [<COUNT>]] [disperse-data <COUNT>] [redundancy <COUNT>] [transport <tcp|rdma|tcp,rdma>] <NEW-BRICK> <TA-BRICK>... [force]
[root@kube-slave02 ~]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
总结：glusterfs 6.1版本之后，不在支持stripe ，复制条带卷、分布式复制条带卷不在多说，可以自行查阅 经常用的就是分布式复制卷了，还需根据实际业务需求
四、常见卷故障处理
只针对复制卷、分布式复制卷，因为分布式卷不具备容错能力，因此很少采用分布式卷。
（1） slave宕机测试
流程：1.将其中一个slave进行断网操作，client创建文件后，查看是否还同步
2.将slave恢复服务以及网络，恢复看是否和其他节点一致，如下：
在客户端操作
[root@kube-master fuzhi]# touch {1..10}.txt
[root@kube-master fuzhi]# ls
10.txt 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
- 3
查看slave是否都存在文件
[root@kube-slave01 ~]# ls /nfs/fuzhi/
10.txt 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
[root@kube-slave02 ~]# ls /nfs/fuzhi/
10.txt 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
[root@kube-master ]# ls /gluster/nfs/
10.txt 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
在客户端删除1~5的txt,确认删除操作同步是否存在问题
[root@kube-master fuzhi]# rm -rf {1..5}*
[root@kube-master fuzhi]# ls
6.txt 7.txt 8.txt 9.txt
[root@kube-master fuzhi]#
- 1
- 2
- 3
- 4
查看slave，只查看一个，其他略
[root@kube-slave01 ~]# ls /nfs/fuzhi/
6.txt 7.txt 8.txt 9.txt
[root@kube-slave01 ~]#
- 1
- 2
- 3
将kube-slave01主机网卡断掉，模拟网络故障 查看文件是否同步
[root@kube-slave02 ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:0c:29:98:7e:e1 brd ff:ff:ff:ff:ff:ff inet 192.168.0.15/24 brd 192.168.0.255 scope global noprefixroute dynamic ens32 valid_lft 5265737sec preferred_lft 5265737sec inet6 fe80::f65:3c75:b4d1:c0b6/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:80:2d:28:38 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever 4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default link/ether 76:76:6e:e6:0d:2c brd ff:ff:ff:ff:ff:ff inet 10.244.2.0/32 scope global flannel.1 valid_lft forever preferred_lft forever [root@kube-slave02 ~]# ifdown ens32 ##虚拟机可以，其他环境慎重
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
客户端创建文件
[root@kube-master fuzhi]# touch {1..5}.txt
[root@kube-master fuzhi]# ls
1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
[root@kube-master fuzhi]#
- 1
- 2
- 3
- 4
此时除了kube-slave01之外，其他两个节点的文件是同步了，将kube-slave01恢复，查看文件是否同步
[root@kube-slave01 ~]# ls /nfs/fuzhi/
6.txt 7.txt 8.txt 9.txt
[root@kube-slave01 ~]#
- 1
- 2
- 3
[root@kube-slave02 fuzhi]# pwd
/nfs/fuzhi
[root@kube-slave02 fuzhi]# ls
1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
- 3
- 4
文件不同步，现在进行修复，修复的方法有两种，自行google，此处介绍常用的一种，在kube-slave01进行操作
[root@kube-slave01 ~]# systemctl start glusterd [root@kube-slave01 ~]# gluster gluster glusterd glusterfind glusterfs glusterfsd gluster-setgfid2path [root@kube-slave01 ~]# gluster volume info fuzhi-01 Volume Name: fuzhi-01 Type: Replicate Volume ID: cbc288d5-0502-405c-8b46-196ff71f8577 Status: Started Snapshot Count: 0 Number of Bricks: 1 x 3 = 3 Transport-type: tcp Bricks: Brick1: 192.168.0.15:/nfs/fuzhi Brick2: kube-slave01:/nfs/fuzhi Brick3: kube-master:/gluster/nfs Options Reconfigured: transport.address-family: inet storage.fips-mode-rchecksum: on nfs.disable: on performance.client-io-threads: off [root@kube-slave01 ~]# gluster volume heal fuzhi-01 full Launching heal operation to perform full self heal on volume fuzhi-01 has been successful Use heal info commands to check status. [root@kube-slave01 ~]# cd /nfs/fuzhi/ [root@kube-slave01 fuzhi]# ls 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt [root@kube-slave01 fuzhi]#
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
节点因为网络原因、或者服务器宕机，可以通过以上进行恢复，后边会有针对性的故障恢复的案例，暂时测试到这里
（2） slave磁盘硬件设备损坏
流程：(1.) 新添加一块硬盘，(2.)客户端新创建文件，（3）不通过老硬盘，看数据是否能恢复到新硬盘上
模拟kube-slave01 硬盘坏掉，需要新增加硬盘，自备
首先在客户端上新创建文件，如下：
[root@kube-slave03 ~]# cd /ff/
[root@kube-slave03 ff]# touch {1..10}.txt
[root@kube-slave03 ff]# ls
10.txt 1.txt 2.txt 3.txt 4.txt 5.txt 6.txt 7.txt 8.txt 9.txt
- 1
- 2
- 3
- 4
注意：修复的volume和挂载的volume必须为同一个，才能看出效果,新增加的设备需要进行rebalance
模拟故障如下：
重新挂载volume中的brick，如下：
[root@kube-slave01 ~]# umount /nfs [root@kube-slave01 ~]# mount /nfs [root@kube-slave01 ~]# gluster volume status Status of volume: fenbushi-01 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 192.168.0.15:/nfs/fenbushi-01 N/A N/A N N/A Brick kube-slave01:/nfs/fenbushi-01 N/A N/A N N/A Task Status of Volume fenbushi-01 ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: ff-01 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 192.168.0.15:/nfs/one 49152 0 Y 90328 Brick kube-slave01:/nfs/one N/A N/A N N/A Brick kube-master:/gluster/one 49152 0 Y 16169 Brick kube-slave03:/home/one 49152 0 Y 26729 Self-heal Daemon on localhost N/A N/A Y 24303 Self-heal Daemon on kube-slave02 N/A N/A Y 21210 Self-heal Daemon on kube-master N/A N/A Y 38460 Self-heal Daemon on kube-slave03 N/A N/A Y 27575 Task Status of Volume ff-01 ------------------------------------------------------------------------------ There are no active volume tasks Volume ff-02 is not started
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
此时发现kube-slave01 的brick的online表示N，存在PID号（不显示N/A）应当使用如下命令结束掉进程方可继续下面步骤。
kill -15 pid
- 1
新创建/test为新磁盘的挂载点
mount /dev/sdc1 /test/
- 1
恢复操作如下：
查看坏的磁盘的目录的扩展属性
[root@kube-slave01 /]# getfattr -d -m. -e hex /nfs/one/
getfattr: Removing leading '/' from absolute path names
# file: nfs/one/
trusted.afr.dirty=0x000000000000000000000000
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.dht=0x0000000100000000000000008f10aac0
trusted.glusterfs.mdata=0x010000000000000000000000005f3e3d62000000000e75ef14000000005f3e3d62000000000e75ef1400000000000000000000000000000000
trusted.glusterfs.volume-id=0x4831b6150ac74d8488eff5fc5f1975cf
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
将目录挂载到/mnt下边，并创建测试一个目录
[root@kube-slave01 /]# mount.glusterfs 192.168.0.15:ff-01 /mnt/
[root@kube-slave01 /]# mkdir /mnt/testDir001
[root@kube-slave01 /]# rmdir /mnt/testDir001
- 1
- 2
- 3
设置扩展属性，触发自愈
[root@kube-slave01 /]# setfattr -n trusted.non-existent-key -v abc /mnt
[root@kube-slave01 /]# setfattr -x trusted.non-existent-key /mnt
- 1
- 2
查看volume信息：
[root@kube-slave01 /]# gluster volume heal ff-01 info Brick 192.168.0.15:/nfs/one / Status: Connected Number of entries: 1 Brick kube-slave01:/nfs/one Status: 传输端点尚未连接 Number of entries: - Brick kube-master:/gluster/one Status: Connected Number of entries: 0 Brick kube-slave03:/home/one Status: Connected Number of entries: 0
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
执行强制迁移数据，可以同服务器，也可不同服务器：
[root@kube-slave01 /]# gluster volume replace-brick ff-01 kube-slave01:/nfs/one kube-slave01:/test commit force
volume replace-brick: success: replace-brick commit force operation successful
- 1
- 2
验证：
[root@kube-slave01 /]# umount /mnt [root@kube-slave01 /]# cd /test/ [root@kube-slave01 test]# ls 4.txt 8.txt 9.txt lost+found [root@kube-slave02 ~]# gluster volume status Status of volume: fenbushi-01 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 192.168.0.15:/nfs/fenbushi-01 N/A N/A N N/A Brick kube-slave01:/nfs/fenbushi-01 N/A N/A N N/A Task Status of Volume fenbushi-01 ------------------------------------------------------------------------------ There are no active volume tasks Status of volume: ff-01 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------ Brick 192.168.0.15:/nfs/one 49152 0 Y 90328 Brick kube-slave01:/test 49152 0 Y 34025 Brick kube-master:/gluster/one 49152 0 Y 16169 Brick kube-slave03:/home/one 49152 0 Y 26729 Self-heal Daemon on localhost N/A N/A Y 29239 Self-heal Daemon on kube-slave03 N/A N/A Y 27677 Self-heal Daemon on kube-master N/A N/A Y 58603 Self-heal Daemon on kube-slave01 N/A N/A Y 34034 Task Status of Volume ff-01 ------------------------------------------------------------------------------ There are no active volume tasks Volume ff-02 is not started
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
（3） slave文件误删除恢复
将slave-01，slave02 volume中的文件删除，(2) 触发自动修复
删除slave-01,slave02 volume中的文件，自行删除吧。
注意： 因为创建volume时 ff-01指定的是2个副本，所以模拟删除时不要把2个副本都删除，只删除1个副本即可，如果2个副本都删除了，那么就无法恢复了(暂时没找到解决方法)。。
如果只删除了一个副本，执行一下命令即可恢复：
触发自动修复机制
[root@kube-master one]# gluster volume heal ff-01 full
- 1
如果不能恢复，需要做均衡，均衡之后在执行修复机制(是由于更换磁盘之后没有做均衡)
暂时到这里，其他的自行查阅。
五、GlusterFS存储原理与注意事项
（1） 客户端访问gfs原理
流程：
client --> 本地VFS -->本地FUSE内核 --> 设备/dev/fuse–> glusterfs client -->gluster server
阐述：当客户端访问glusterfs存储时，首先会通过挂载点读写数据，对于用户和程序来讲，glusterfs是透明得，用户和程序感觉不到自己访问得是本地还是远程GFS服务器，读写操作交给VFS，VFS会将请求交给FUSE内核模块，FUSE又通过/dev/fuse设备将数据交给Glusterfs client计算之后 最后交给gluster server
VFS: 虚拟文件系统，创建的系统文件格式有"ext4",“ext3” 除此之外还有好多文件系统，用户真正存储文件使用过libc和kernel中的VFS进行交互的，可以把VFS理解为是一个公共的API接口，可以让不同的文件系统调用，然后将不同的文件系统转换为系统文件的通用模型
FUSE: 文件系统用户空间，是一个可以加载的内核模块，支持非特权用户创建自己的文件系统而不需要修改内核代码。通过在用户空间运行文件系统的代码通过FUSE代码与内核进行桥接
/dev/fuse: 是加载fuse内核之后生成的一个设备节点，应用层可以通过该设备节点完成用户态文件系统，（libfuse是对fuse进行封装的一个库，自行查阅）
（2） AFR恢复机制
Glusterfs数据恢复是通过副本来恢复的，复制是通过镜像来做的，且是同步事务性操作，用户写一个文件时，首先会锁定该文件，进行读写，写完之后在解锁，如果中间出现问题，就通过副本恢复。
glusterfs有自动恢复的机制，每10分钟自动检测一次，也可手动触发，决定哪个副本是坏的，哪个副本需要恢复使用过changelog来决定的，在volume中的.glusterfs文件下有一个changelog文件。
changelog主要记录了改目录以及其他副本都干了些什么，增删查改都会记录，这些记录的可以通过目录的扩展属性反转出来，反转过来就可以根据扩展属性的标识,进行恢复主要命令：getfattr 参考连接链接: slave磁盘硬件设备损坏， 例如：
[root@kube-slave02 ~]# getfattr -d -m. -e hex /nfs/ma
getfattr: Removing leading '/' from absolute path names
# file: nfs/ma
trusted.afr.ma-01-client-1=0x000000000000000000000000
trusted.gfid=0x00000000000000000000000000000001
trusted.glusterfs.dht=0xf9fc1379000000000000000087c2252a
trusted.glusterfs.dht.commithash=0x3431393430343638343100
trusted.glusterfs.mdata=0x010000000000000000000000005f3f830b000000001134b6ac000000005f3f830b000000001134b6ac000000005f3f7f0d0000000009bd82c6
trusted.glusterfs.volume-id=0x7fee857065b24842bd71045e696fd145
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
其中client-1 表示brick的标识为1，0x 之后开始共24位 8位一组，如下：
0x 00000000 00000000 00000000
- 1
分别表示数据，元数据，和entry，entry可以理解为gfid
具体如何反转的请自行查阅，不过面试说这个就可以了
（3） GFS集群部署注意事项
（3.1） 集群规模较大产生的风险
因为glusterfs是无元数据设计的，并通过HASH算法来读写数据，因此每个节点都掌握了集群的配置信息，这样的好处就是每个节点都可以进行本地查询，不需要想去请求元信息服务器，每个节点的信息更新都会向其他节点通告，以此来保证节点信息的一致性。
因此：如果集群的规较大，节点较多，那么每个节点之间的信息同步会下降，也相应的增加了文件非一致性的几率，因此对于服务器相连接之间应采用网卡以及网卡IO较高一些
（3.2） 文件较大产生的元数据性能影响
因为GFS采用的是弹性hash，所已增加了可扩展性，以及提高了系统性能的可靠性，集群中的任何服务器和客户端只需根据路径和文件名就可以对数据进行定位和读写访问，文件定位可独立并行化进行。
财通这种算法的特点：
(1.)根据指定的文件名称访问，查找和定位非常快
(2.)如果不知道文件名称，直接使用ls,find，rm命令进行查找、删除时，性能就会下降，存储的节点越多，文件越多，下降的越厉害，因为文件通过HASH分散到各个集群节点上，每个节点的命名空间不同，所以列文件时，需要查询所有的节点信息之后，在进行汇总聚合，此时，hash就没有什么作用了，有元信息服务器的文件系统在此情况下，性能会更高一些。
建议：对于目录进行管理，尽量不要深层嵌套，优化glusterfs文件增大目录缓存，增加服务器内存以及优化网络io，以及磁盘采用SSD等。
（3.3） 小文件产生的元数据性能影响
海量小文件LOSF，这个目前还没有任何一款开源软件敢说可以做到80%的，难题，glusterfs使用与大文件，因此在小文件上性能并不是很高，文件多，目录层次较深 ，HASH基本就是fw，只能进行优化，以最大程度满足。具体的自行查阅
建议：优化建议从几方面入手:硬盘固态、网络万兆、优化cache、网络i/o、文件管理(小文件合并)、增加整体服务器性能(内存、cpu)
目前本人碰到的问题就这么多，后期碰到问题之后，在更新。
glusterfs的扩容，缩容，增删节点 自行查看把。
