glusterfs——volume管理

简介:

Q: 常用的命令有哪些?

创建volume: 

gluster volume create NAME stripe SCOUNT replica RCOUNT transport TYPE  BRICKLIST

NAME为volume的名字;SCOUNT,RCOUNT分别为stripe,replica的个数;transport为传输类型(tcp/rdma);BRICKLIST为brick列表,具体形式为HOME:PATH

启用volume:  gluster volume start NAME

停用volume:  gluster volume stop NAME

删除volume:  gluster volume delete NAME

查看volume信息:  gluster volume info

查看volume运行时的信息: gluster volume statedump Name

===========================

Q: 创建/启用/停用/删除volume最终都干了些什么?

(1) 创建volume能看得到的结果是: glusterd在工作目录(默认为/var/lib/glusterd)的vols目录下,创建以volume名称为名字的目录,并在这个目录下创建相关文件记录volume的相关信息;看不到的结果是glusterd程序中也记录了volume的相关信息。(2) 启用volume的结果是在指定brick的节点上启动glusterfsd和glusterfs进程(注意:如果多个brick在同一节点下,会有多个glusterfsd进程,但只有一个glusterfs进程),同时在日志文件中更新记录的volume相关信息。(3) 停用volume的结果是结束glusterfsd和glusterfs进程。(4)删除volume则是将创建volume的相关文件信息全部清除。

===========================

Q: 创建volume时都会创建哪些文件?分别记录些什么信息?

创建volume时会在glusterd工作目录(默认为/var/lib/glusterd)的vols目录下,创建以volume名字为名的目录,在这个目录下会创建这些文件:

info文件:保存volume的复制类型,volume的brick个数,brick的详细信息,stripe个数,replica个数,传输类型,volume的唯一ID,以及内部使用的用户名密码。这些基本上都是创建volume指定的参数信息。

node_state.info:rebalance的状态信息,由gluster volume rebalance命令触发(不完全确定)。

rb_state:rebalane-brick的状态信息,由gluster volume-brick命令触发(不完全确定)。

cksum:校验值

Name-fuse.vol/trusted-Name-fuse.vol(Name为volume的名字):volume对应glusterfs的配置文件,进程启动时读取。

Name.Host.Path.vol(Name为volume的名字,Host为brick的主机名,Path为brick的存储路径'/'转换为'-'):

volume对应brick的glusterfsd的配置文件,进程启动时读取。

bricks/Host:Path(Host为brick的主机名,Path为brick的存储路径'/'转换为'-'):birck的相关信息,包括brick的主机名,文件存储路径,对应glusterfsd的侦听端口,以及连接状态。

启用volume时,会记录brick对应glusterfsd进程的pid信息到 run/HOST-PATH.pid 文件中。

===========================

Q: glusterd对这些命令的处理,内部实现大概是怎样的?

与peer节点管理一样,针对volume的操作,glusterd也维护了一个事件链表和一个状态机,以及相应的状态数组,事件处理数组。当有对volume的操作请求时,往事件链表中添加事件,并根据状态机的变化,从相应状态的事件处理数组中找到对应的事件处理函数,并完成实际的处理动作。节点管理中是根据每个peer节点的状态作为有限状态机的变化,而volume的管理则是有一个全局的变量(opinfo)记录相应的状态。

完整的处理一次请求,大概会有这样的状态机切换:

由于brick可能是远端的节点,因此glusterd在本地处理的同时,还会和远端节点的glusterd交互。从上面状态机的转换可看出,一个请求的处理过程可理解为事务的执行,包括上锁,提交,释放锁等,具体实现方式等同于2pc的提交。关键函数调用如下图所示。

===========================

Q: 这篇文章最后提到的问题是怎么回事?

这是因为创建volume时,在brick对应的存储目录上,增加了"trusted.glusterfs.volume-id"和"trusted.gfid"两个扩展属性,在删除volume时并未移除这两个属性,再次创建时,对brick的存储目录进行校验,发现已经有了扩展属性,因此会有brick已经是volume的一部分的提示。

通过getfattr命令可以查看这些存储路径的扩展属性










本文转自 yntmdr 51CTO博客,原文链接:http://blog.51cto.com/yntmdr/1619188,如需转载请自行联系原作者
目录
相关文章
|
1月前
|
存储 传感器 分布式计算
Volume(大量)
Volume(大量)
26 1
|
8月前
|
Kubernetes 容器
kubernetes挂载ceph rbd和cephfs
kubernetes挂载ceph rbd和cephfs
|
存储 JSON Kubernetes
k8s配置glusterFS详解
k8s配置glusterFS详解
|
存储 网络协议 Java
Volume特点
Volume特点
154 0
|
存储 Kubernetes Apache
kubernetes资源对象--持久化存储Persistent Volume和Persistent Volume Claim
概念 存储管理跟计算管理是两个不同的问题。理解每个存储系统是一件复杂的事情,特别是对于普通用户来说,有时并不需要关心各种存储实现,只希望能够安全可靠地存储数据。 为了简化对存储调度,K8S对存储的供应和使用做了抽象,以API形式提供给管理员和用户使用。
2497 0
|
存储 Kubernetes 文件存储
CephFS 使用
Ceph 之前介绍了 RBD 的使用方法,有了 RBD,远程磁盘挂载的问题就解决了,但 RBD 的问题是不能多个主机共享一个磁盘,如果有一份数据很多客户端都要读写该怎么办呢?这时 CephFS 作为文件系统存储解决方案就派上用场了。
2325 0
|
网络协议 Unix Linux
|
网络协议 Unix Linux
|
网络安全