GFS2是红帽企业Linux中用于共享块设备的集群文件系统，它允许集群中的多个节点同时读写同一块存储，并且通过分布式锁管理器来协调文件元数据的并发访问。与传统的单机文件系统不同，GFS2直接把文件系统建立在使用SAN或iSCSI提供的共享磁盘上，所有节点都拥有对块设备的直接访问路径，因此不存在NFS那样的单点转发瓶颈。当某个节点发生故障时，其余节点仍然可以继续访问文件系统，这为数据库、虚拟化镜像以及共享Web内容等场景提供了高可用的基础。
GFS2的核心架构与DLM锁机制
理解GFS2的关键在于它如何解决多节点同时修改同一份元数据的问题。GFS2把存储空间划分成多个资源组，每个资源组中包含数据块、inode以及位图等元数据。节点在需要修改某个文件或目录时，必须先向分布式锁管理器申请对应的glock锁。glock针对不同类型的元数据有不同的锁名空间，例如inode锁、资源组锁、目录锁等。DLM会根据集群成员关系和请求模式授予共享读锁或独占写锁，从而避免两个节点同时写坏同一块元数据区。
锁模式中最常见的是共享模式与独占模式，此外还包含延迟释放和空锁状态。GFS2并不会在每次文件操作完成后立即释放所有锁，而是根据缓存策略保留一段时间，以便后续操作复用，减少DLM通信开销。如果另一个节点需要冲突的锁，当前节点会收到锁降级或释放请求，这一过程由内核级别的GFS2模块与用户态的DLM服务协同完成。正是这种锁机制使得多节点并发读写同一个文件系统成为可能，但也意味着集群成员管理和锁超时配置必须正确，否则容易出现卡顿甚至脑裂。
与NFS相比，GFS2直接从本地块设备读取数据，不需要经过网络文件协议转换，因此在大块顺序读写时通常能获得更低的延迟。但GFS2对网络抖动更加敏感，因为DLM锁请求依赖集群心跳网络，如果心跳链路不稳定，锁请求可能会超时并触发文件系统冻结或节点隔离。
在RHEL上部署GFS2的前置条件与安装
部署GFS2之前需要准备三个基础组件：集群通信层Corosync、资源管理层Pacemaker以及可靠的fence隔离设备。Corosync负责节点之间的成员通信和心跳，Pacemaker负责管理文件系统、IP等资源的启动与故障转移，fence设备则保证在节点无响应时可以直接断电或重启该节点，防止两个节点同时写入共享存储造成数据损坏。所有节点必须能够访问同一块共享磁盘，并且磁盘的WWID或设备路径在每台机器上保持一致。
首先安装相关软件包，命令如下：
dnf install -y pcs pacemaker corosync fence-agents-all gfs2-utils lvm2-cluster
安装完成后启动pcsd服务并设置hacluster用户密码，然后在任意一个节点上完成集群认证和创建操作。需要确保集群名称在所有节点配置中一致，并且节点名称能够被正确解析，通常使用/etc/hosts或DNS。集群创建完成后，必须配置至少一个fence设备并启用stonith，否则Pacemaker不会启动任何资源。下面是一个基于IPMI的fence配置示例：
pcs cluster setup mycluster node1 node2 pcs cluster start --all pcs property set stonith-enabled=true pcs stonith create fence_node1 fence_ipmilan ipaddr=192.168.1.101 login=admin passwd=secret lanplus=1 action=reboot pcs stonith create fence_node2 fence_ipmilan ipaddr=192.168.1.102 login=admin passwd=secret lanplus=1 action=reboot
正式创建GFS2文件系统前，还需要使用共享LVM。普通LVM卷组无法在多节点同时激活，必须通过带集群标记的卷组来管理。执行vgcreate --shared后，LVM元数据会写入共享存储，由集群锁保护。这一步经常被忽略，导致只在单节点上看到逻辑卷，另一个节点无法识别。
创建GFS2文件系统与挂载实践
在所有节点都能看到共享磁盘的前提下，先创建物理卷和共享卷组。假设共享磁盘为/dev/sdb，逻辑卷名为lv_gfs，大小设置为100G。需要注意共享卷组在任意一个节点上创建一次即可，其他节点通过LVM集群机制自动识别。示例如下：
pvcreate /dev/sdb vgcreate --shared vg_gfs /dev/sdb lvcreate -L 100G -n lv_gfs vg_gfs
接下来格式化文件系统。mkfs.gfs2有几个关键参数：-t指定集群名称和文件系统名称，格式为“集群名:锁表名”，这个锁表名会在DLM中作为锁空间标识；-j指定日志数量，必须大于等于可能同时挂载的节点数，通常设置为节点数加一；-p指定锁协议，集群环境应使用lock_dlm。格式化命令如下：
mkfs.gfs2 -p lock_dlm -t mycluster:gfsvol -j 2 /dev/vg_gfs/lv_gfs
手动挂载测试时可以执行mount -t gfs2 -o noatime /dev/vg_gfs/lv_gfs /mnt/gfs，确认能够读写后再写入/etc/fstab。但生产环境中建议使用Pacemaker的Filesystem资源进行管理，这样当节点故障时资源会自动迁移到其他节点。创建Pacemaker资源的命令如下：
pcs resource create gfs_fs Filesystem device="/dev/vg_gfs/lv_gfs" directory="/mnt/gfs" fstype="gfs2" options="noatime" op monitor interval=20s
挂载成功后可以通过df -hT查看文件系统类型是否为gfs2，也可以使用gfs2_tool df /mnt/gfs查看GFS2内部的资源组分布和空闲空间。所有节点都应执行相同的挂载验证，尤其是检查写操作是否能在多个节点间立即可见。
性能调优与常见故障处理
GFS2的性能调优需要从文件系统格式化参数和挂载选项两个方面入手。格式化时可以通过-b指定块大小，一般保持默认4K即可；-r指定资源组大小，较大的资源组能减少元数据开销，但会增加锁粒度。挂载时常用的选项包括noatime减少时间戳写入，commit=60将日志提交周期从默认值调整到60秒，以降低同步频率。需要注意的是，并非所有调优都适合所有业务，数据库类负载和文件共享类负载的最优参数差异较大，建议在测试环境中对比后再应用到生产。
一个典型的问题是节点在挂载GFS2后长时间处于卡死状态，这通常与DLM锁等待或集群通信故障有关。可以登录正常节点执行dlm_tool ls查看锁空间状态，或者执行gfs2_tool counters /mnt/gfs观察各类锁请求的等待计数。如果发现某个节点的glock长时间不释放，可以通过echo 1 > /proc/sys/fs/gfs2/lockdump触发锁转储，再从日志中定位具体是哪个文件或资源组发生了锁竞争。必要时可以执行fsck.gfs2 -y /dev/vg_gfs/lv_gfs进行文件系统修复，但必须先确保所有节点已经卸载该文件系统。
另一个容易忽视的问题是fence配置错误导致的资源不启动。如果stonith资源处于停止状态，Pacemaker会拒绝启动任何其他资源，此时用pcs status可以看到明显提示。集群节点的时钟也需要保持同步，时间偏差过大会影响DLM的锁超时判断，建议所有节点启用chrony或ntpd并绑定到同一时间源。对于运行时间较长的集群，定期检查/var/log/messages中的GFS2告警和DLM超时记录，能够提前发现存储多路径或交换机链路的隐患。
