GlusterFS is a scalable, distributed file system that aggregates storage from multiple servers into a single, unified namespace accessible over the network. Unlike block-level solutions such as iSCSI or Ceph, GlusterFS operates at the file level and requires no metadata server, making it straightforward to deploy and maintain. On RHEL 9, GlusterFS is available through the CentOS Storage SIG packages and integrates well with existing NFS and SMB workflows. This tutorial walks through setting up a two-node replicated GlusterFS cluster, mounting it on a client, and verifying its health.
Prerequisites
- Two RHEL 9 servers (
node1andnode2) with resolvable hostnames or entries in/etc/hosts - A dedicated disk or directory on each node for GlusterFS bricks (separate from the OS disk is recommended)
- Root or sudo access on all nodes
- Firewall ports 24007-24008/tcp and 49152+/tcp open between nodes
- A RHEL 9 client node for testing the mount
Step 1 — Install GlusterFS Server on Both Nodes
Enable the GlusterFS repository and install the server package on both node1 and node2. The CentOS Storage SIG provides the latest stable builds for RHEL 9:
# Run on BOTH node1 and node2
dnf install -y centos-release-gluster10
dnf install -y glusterfs-server
systemctl enable --now glusterd
systemctl status glusterd
Also ensure the required firewall ports are open on both nodes:
firewall-cmd --permanent --add-service=glusterfs
firewall-cmd --reload
Step 2 — Peer the Nodes Together
From node1, probe node2 to form the trusted storage pool. You only need to run this from one side:
# On node1 only
gluster peer probe node2
# Verify the peer status
gluster peer status
Expected output will show node2 with a state of Peer in Cluster (Connected). If DNS is not available, add entries to /etc/hosts on both nodes:
# Add to /etc/hosts on both nodes
192.168.1.101 node1
192.168.1.102 node2
Step 3 — Create Brick Directories
On both nodes, create the directory that will serve as the GlusterFS brick. Using a dedicated XFS-formatted partition is strongly recommended for production:
# Run on BOTH node1 and node2
mkdir -p /data/brick1/gvol0
# Optional but recommended: use a dedicated XFS partition
# mkfs.xfs /dev/sdb
# mkdir -p /data/brick1
# echo "/dev/sdb /data/brick1 xfs defaults 0 0" >> /etc/fstab
# mount -a
# mkdir -p /data/brick1/gvol0
Step 4 — Create and Start the Replicated Volume
From node1, create a replicated volume named myvol using one brick from each node. Replica 2 means each file is stored on both nodes for redundancy:
# On node1 only
gluster volume create myvol replica 2
node1:/data/brick1/gvol0
node2:/data/brick1/gvol0
# Start the volume
gluster volume start myvol
# Verify volume info
gluster volume info myvol
gluster volume status myvol
The output of gluster volume info will confirm the volume type is Replicate, the number of bricks is 2, and the status is Started.
Step 5 — Mount the Volume on a Client
On the client node, install the GlusterFS client package and mount the volume. The client connects to either node and accesses the unified namespace:
# On the client
dnf install -y glusterfs glusterfs-fuse
# Create mount point and mount the volume
mkdir -p /mnt/gluster
mount -t glusterfs node1:/myvol /mnt/gluster
# Verify the mount
df -h /mnt/gluster
ls /mnt/gluster
For persistent mounting, add the following to /etc/fstab on the client:
node1:/myvol /mnt/gluster glusterfs defaults,_netdev 0 0
Step 6 — Monitor Health and Self-Heal
GlusterFS includes a self-heal daemon that automatically repairs files when a node comes back online after a failure. Check its status and run a manual heal if needed:
# Check volume status and heal info
gluster volume status myvol
gluster volume heal myvol info
# Trigger a manual heal
gluster volume heal myvol
# Check the self-heal daemon on each node
gluster volume status myvol | grep "Self-heal"
# List peers and pool health
gluster pool list
To add a new node to expand capacity, run gluster peer probe node3 and then use gluster volume add-brick with the appropriate replica count.
Conclusion
You have deployed a two-node replicated GlusterFS cluster on RHEL 9, where each file written to /mnt/gluster is automatically stored on both nodes for high availability. GlusterFS’s peer-based architecture eliminates single points of failure inherent in single-node NFS exports, and the self-heal daemon ensures consistency after transient network or node outages. As your storage needs grow, you can expand the cluster by adding more peers and bricks without unmounting or interrupting access.
Next steps: How to Set Up iSCSI Storage on RHEL 9, How to Install and Configure MinIO Object Storage on RHEL 9, and How to Set Up a Ceph Storage Cluster on RHEL 9.