glusterfs卷的使用

一、前言

    在 GlusterFS 中，卷（Volume）是一个逻辑存储单元，用于管理和组织存储在 GlusterFS 集群中的数据。卷将多个存储节点（Brick）连接成一个统一的命名空间，并提供统一的文件系统接口，使用户可以像访问本地文件系统一样访问和管理数据，GlusterFS 中的卷有几种常见的模式，每种模式都具有不同的特点和用途以下是 GlusterFS 中常见的卷模式，分布式卷、复制卷、条带卷、复制条带卷、分布式复制卷，其中在生产中最常使用的是分布式复制卷

二、使用

通过之前文章中创建glusterfs集群去创建卷

这里还要说一下brick的命名规则

参考：Brick Naming Conventions - Gluster Docs

/data/gfsdata1/k8s/nacos
/data/<volume>/brick/<brick>
参考官网的命名规则volume为磁盘的挂载点，brick为卷的挂载点
我这直接就使用一下的目录方式，需要在所有的挂载节点都创建该目录
mkdir /data/gfsdata1/nacos
/data/<volume>/<brick>

如果对目录有限制容量需要可以参考官网

参考：Quotas - Gluster Docs 

分布式卷

分布式卷将数据分布在多个存储节点上，但不复制数据，也不提供冗余。这种模式适用于需要扩展存储容量，但不需要数据冗余或高可用性的场景。数据在存储节点之间以均衡的方式分布，提高了存储容量和吞吐量

gluster volume create nacos ceph01:/data/gfsdata1/nacos ceph02:/data/gfsdata1/nacos ceph03:/data/gfsdata1/nacos

复制卷

复制卷将数据复制到多个存储节点上，提供数据冗余和高可用性。每个数据块都会在指定数量的存储节点上进行复制，以确保即使某个节点故障，数据仍然可用。这种模式适用于对数据可靠性和高可用性要求较高的场景

gluster volume create nacos replica 3 ceph01:/data/gfsdata1/nacos ceph02:/data/gfsdata1/nacos ceph03:/data/gfsdata1/nacos

条带卷

条带卷将数据分割成固定大小的数据块，并将这些数据块分布在多个存储节点上。这种模式可以提高数据读写的并行性和吞吐量，适用于需要处理大型文件和高并发访问的场景。然而，条带卷并不提供数据冗余或高可用性

gluster volume create nacos stripe 2 ceph01:/data/gfsdata1/nacos ceph02:/data/gfsdata1/nacos

分布式条带卷

分布式条带卷是分布式卷和条带卷的结合，当一个文件被写入分布式条带卷时，文件会被分割成多个数据块（或称为条带），每个数据块会被独立地存储在网络中的不同节点上。这种模式综合了分布式和条带的优点，适用于存储和访问大文件以及高带宽需求的场景

gluster volume create nacos stripe 2 ceph01:/data/gfsdata1/nacos ceph02:/data/gfsdata1/nacos ceph03:/data/gfsdata1/nacos ceph01:/data/gfsdata2/nacos

分布式复制卷

分布式复制卷是分布式卷和复制卷的结合，它将数据分布在多个存储节点上，并对数据进行复制，以提高数据可靠性和高可用性。这种模式适用于需要同时扩展存储容量和提供数据冗余的场景

gluster volume create dis-rep replica 3 ceph01:/data/gfsdata1/nacos ceph02:/data/gfsdata1/nacos ceph03:/data/gfsdata1/nacos ceph01:/data/gfsdata2/nacos ceph02:/data/gfsdata2/nacos ceph03:/data/gfsdata2/nacos

重点来说一下复制卷和分布式复制卷，这两种用的比较多，使用复制卷和分布式复制卷时会有一个脑裂的问题

脑裂是指文件的两个或多个复制副本出现分歧的情况，用于解决脑裂有两种方式

一种是设置三个副本节点，第二种是使用引入仲裁节点，即每两个副本就要有一个仲裁节点，资源多的话可以选择三副本节点的方式，资源少就选择仲裁节点的方式，仲裁节点只存储元数据即文件/目录名称（即树结构）和扩展属性（元数据），不存储文件中的数据

参考：Split brain and ways to deal with it - Gluster Docs

使用仲裁方式的分布式副本卷

gluster volume create nacos replica 2 arbiter 1  ceph01:/data/gfsdata1/nacos ceph02:/data/gfsdata1/nacos ceph03:/data/gfsdata1/nacos ceph01:/data/gfsdata2/nacos ceph02:/data/gfsdata2/nacos ceph03:/data/gfsdata2/nacos
创建命令时节点brick的排序也有讲究，第一第二个节点为复制节点，第三个节点为前两个节点的仲裁节点

启用卷

 gluster volume start nacos

查看卷

gluster volume info

查看仲裁节点的目录

可以看到所有文件只存储目录名称，不存储数据

三、故障测试 

这里只做说明不做演示，实测的总结

无论是仲裁节点还是副本节点，任意掉点其中之一，不会影响数据的写入，但是在节点掉点后，会存在大概半分钟的不可写入时间，即所有写入都在等待，会在半分钟后恢复，导致的原因是在节点掉线后，会有超时检测，默认的时间 为42s，即使是写入大文件也不影响，在超时检测时间结束后会继续写入

四、其它

在官网的仲裁器说明中有一个说明

如果 2 个brick已启动，并且其中一个是仲裁器（即第 3 个砖块），并且 它会将给定文件归咎于另一个已启动的砖块，则所有写入 FOPS 都将因 ENOTCONN 而失败。这是因为，在这种情况下，唯一的真实副本位于倒下的砖块上。因此，在砖块也升起之前我们不能允许写入。如果仲裁者不责怪另一块砖块，FOPS 将被允许继续进行。这里的“指责”指的是 AFR 变更日志扩展属性的值

这里就是脑裂的问题，就是存活的这个brick跟挂掉的brick数据不一致，导致仲裁节点认为挂掉的节点数据是正确的，在写入数据的时候会拒绝数据写入，直到挂掉的brick恢复

如果挂掉的brick没法恢复，可以参考官网的解决方式

参考：Troubleshooting Split-Brains - Gluster Docs