在企业渲染、AI 数据集、媒体资产、虚拟化等场景中，经常会遇到一个问题：
如何让多台服务器共享同一份数据，并且具备横向扩容能力？
传统 NAS 在容量、性能以及扩展性方面都有一定限制，而 GlusterFS 则提供了一种更加灵活的分布式存储方案。
最近重新梳理了一下过往的工作记录，整理出了一套 GlusterFS 集群部署方案，顺便把整个部署过程记录下来，希望能够帮助准备搭建 GlusterFS 的朋友。
为什么选择 GlusterFS？
GlusterFS 最大的特点就是：
横向扩容简单
不依赖中心节点
支持 PB 级存储
支持 XFS、EXT4 等文件系统
可以直接导出 NFS、SMB
对 RAID 阵列支持良好
相比传统 NAS：
NAS
├── 单设备
├── 容量固定
├── 性能固定
└── 升级成本高
GlusterFS
├── 多节点组成
├── 可以持续增加节点
├── 性能随节点增长
└── 更适合企业存储
软件版本
本次测试环境如下：
之所以选择 Fedora，是因为当时 Fedora 已经原生提供 GlusterFS 10。
相比旧版本：
Metadata 性能更好
小文件性能有所提升
DHT 调度优化
Bug 修复较多
如果使用 Rocky Linux，可根据官方仓库支持情况选择对应版本。
硬件规划建议
RAID 仍然十分重要
很多人认为：
都用了分布式存储，就不需要 RAID。
实际上并不是。
GlusterFS 解决的是：
节点故障
数据副本
横向扩展
而 RAID 解决的是：
单盘损坏
本地 IO
顺序读写性能
二者并不冲突。
企业环境依旧建议：
RAID 控制器
BBU 缓存
企业级 SAS/SATA HDD
SSD Cache（如果使用软 RAID）
本次磁盘规划
每台服务器：
12 Bay 2U Server
RAID5
├── Disk1~5
RAID5
├── Disk6~10
Hot Spare
├── Disk11
Hot Spare
└── Disk12
这样设计主要有几个优势：
两组 RAID 并行
IO 分散
热备自动接管
更好的恢复效率
实践过程中发现：
如果将 12 块盘全部组成一个 RAID6，在持续大文件写入时，偶尔会出现写入速度由数百 MB/s 降低到几十 MB/s 的情况，原因涉及 RAID 控制器策略、缓存及磁盘负载等因素，需要结合具体硬件进一步分析。因此实际生产中更倾向于采用多组 RAID 的方式。
安装 GlusterFS
安装软件：
yum install glusterfs-server -y
systemctl enable --now glusterd
确认服务状态：
systemctl status glusterd
配置主机名
例如：
hostnamectl set-hostname node1
其它节点：
node2
node3
node4
保持命名统一即可。
配置 hosts
所有节点保持一致：
10.0.0.11 node1
10.0.0.12 node2
10.0.0.13 node3
10.0.0.14 node4
生产环境建议：
DNS
Hosts
两者都配置。
网络规划
建议将管理网络与业务网络分离。
例如：
管理网络
10.0.0.x
存储网络
192.168.10.x
如果服务器拥有多块万兆网卡，可以：
bond0
├── eth0
└── eth1
Storage
├── eth2
Management
└── eth3
推荐：
LACP（802.3ad）
MTU 9000（视交换机而定）
独立交换机
这样能够获得更稳定的带宽。
SELinux 与防火墙
测试环境可关闭：
setenforce 0
systemctl disable --now firewalld
生产环境建议根据实际情况开放所需端口，而不是直接关闭。
创建 Trusted Pool
任选一台节点执行：
gluster peer probe node2
gluster peer probe node3
gluster peer probe node4
查看状态：
gluster peer status
正常应看到所有节点均为：
Peer in Cluster (Connected)
说明集群建立成功。
准备 Brick
将 RAID 格式化为 XFS：
mkfs.xfs /dev/sdb
mkfs.xfs /dev/sdc
创建挂载目录：
mkdir -p /glusterdata/brick1
mkdir -p /glusterdata/brick2
加入：
/etc/fstab
实现自动挂载。
创建 Volume
创建目录：
mkdir /glusterdata/brick1/gv0
mkdir /glusterdata/brick2/gv0
创建 Volume：
gluster volume create gv0 \
node1:/glusterdata/brick1/gv0 \
node2:/glusterdata/brick1/gv0 \
node3:/glusterdata/brick1/gv0 \
node4:/glusterdata/brick1/gv0 \
node1:/glusterdata/brick2/gv0 \
node2:/glusterdata/brick2/gv0 \
node3:/glusterdata/brick2/gv0 \
node4:/glusterdata/brick2/gv0
启动：
gluster volume start gv0
查看：
gluster volume info
配置 NFS-Ganesha
安装：
yum install nfs-ganesha -y
配置：
EXPORT
{
Export_Id = 101;
Path = "/gv0";
FSAL
{
name = GLUSTER;
hostname = "192.168.10.11";
volume = "gv0";
}
Squash = "No_root_squash";
Pseudo = "/gv0";
SecType = "sys";
}
其中：
Export_Id 每台服务器保持唯一
hostname 修改为当前节点 IP
volume 为 Gluster Volume 名称
启动：
systemctl restart ganesha
验证：
showmount -e localhost
输出类似：
Export list
/gv0
说明共享已经正常导出。
故障恢复实践
真正的企业环境，部署只是第一步。
更重要的是：
出现故障以后如何恢复。
下面分享两种比较典型的情况。
场景一：磁盘损坏
如果底层已经配置 RAID：
整个过程通常非常简单：
坏盘
↓
更换新盘
↓
RAID 自动 Rebuild
↓
GlusterFS 无需任何处理
因此这也是为什么企业环境一直建议保留 RAID。
如果没有 RAID，则需要重新建立 Brick，并恢复 GlusterFS 的扩展属性（xattr），随后执行 Heal。
可以使用：
getfattr
查看 Brick 属性。
然后使用：
setfattr
恢复对应属性。
最后执行：
gluster volume heal <卷名> info
当：
Number of entries: 0
说明同步已经完成。
场景二：服务器损坏
如果整台服务器损坏：
处理思路如下：
新服务器安装相同系统
保持磁盘布局一致
配置相同主机名及网络
安装 GlusterFS
恢复节点配置
加入集群
执行 Heal
同步命令：
gluster volume heal <卷名> full
查看：
gluster volume heal <卷名> info
即可观察同步状态。
需要注意的是，全量 Heal 会消耗大量磁盘和网络资源，建议选择业务低峰期执行。
运维经验总结
经过长时间使用，个人总结了几条经验：
1、优先选择硬 RAID
性能更加稳定。
2、Brick 使用 XFS
XFS 对大容量磁盘支持更成熟。
3、管理网络与存储网络隔离
避免客户端流量影响后台同步。
4、保持所有节点配置一致
包括：
主机名规范
挂载路径
文件系统
Brick 数量
网络规划
一致性越高，后续维护越简单。
5、定期检查 Heal 状态
建议日常巡检：
gluster volume status
gluster volume heal gv0 info
gluster peer status
及时发现：
节点离线
Brick 异常
Heal 未完成
网络问题
结语
GlusterFS 并不是一套"安装完成就结束"的存储系统，它更像是一套需要长期运维的分布式基础设施。
在生产环境中，真正影响稳定性的往往不是软件本身，而是底层硬件规划、网络架构、磁盘布局以及日常巡检策略。合理的 RAID 设计、规范的网络隔离、统一的节点配置，以及完善的故障恢复流程，往往比单纯追求版本更新更加重要。
希望这些内容能够帮助正在建设企业共享存储平台的朋友少走一些弯路。