Building High-Availability Shared Storage: Deploying GlusterFS on a 3-Node Hetzner Cloud Cluster

Introduction to High-Availability Storage in Modern Infrastructure

In the era of cloud computing and distributed applications, data availability is paramount. High availability (HA) is no longer a luxury reserved for massive enterprises; it is a fundamental requirement for any business running mission-critical workloads. When deploying applications across multiple virtual private servers (VPS), a common bottleneck is the shared storage layer. Traditional Network Attached Storage (NAS) solutions or single-node Network File Systems (NFS) introduce a single point of failure (SPOF). If that storage node goes down, the entire application stack halts.

To overcome this challenge, engineering teams leverage software-defined storage (SDS) solutions. GlusterFS stands out as an enterprise-grade, scalable network file system designed to aggregate disk storage resources into a single global namespace. In this technical guide, we will walk through the architecture and implementation of a highly available, replicated GlusterFS volume across a 3-node VPS cluster hosted on Hetzner Cloud. This setup ensures that your data remains consistent and accessible even if an entire cloud server goes offline.

Why Hetzner Cloud and GlusterFS?

Choosing the right infrastructure provider and storage technology requires balancing cost, performance, and reliability. Hetzner Cloud offers an exceptional price-to-performance ratio, making it an ideal choice for bootstrapping resilient infrastructure. By combining Hetzner’s robust hardware with GlusterFS, businesses can achieve enterprise-level storage redundancy without the enterprise-level price tag.

GlusterFS utilizes a modular, brick-based architecture. For true high availability, a 3-node replicated volume is the industry standard. While a 2-node cluster is technically possible, it is highly susceptible to a scenario known as split-brain, where network partitioning causes both nodes to diverge and lose consensus. Adding a third node provides a quorum, allowing the cluster to safely determine the authoritative state of the data at all times.

Prerequisites and Network Architecture

Before executing configuration commands, we must establish a secure and predictable network topology. For this deployment, we will provision three CX21 (or similar) Hetzner Cloud instances running Ubuntu 24.04 LTS. To ensure secure, low-latency communication between the nodes, we will utilize Hetzner's private networking feature.

Cluster Specifications:

• Node 1: Hostname: gluster-node01 | Private IP: 10.0.0.11
• Node 2: Hostname: gluster-node02 | Private IP: 10.0.0.12
• Node 3: Hostname: gluster-node03 | Private IP: 10.0.0.13

Security Note: Never expose GlusterFS management or daemon ports to the public internet. Always restrict communication to the private network interface and configure your firewall rules accordingly.

Step 1: System Preparation and Network Resolution

First, we must ensure all nodes can communicate using hostnames. Update the /etc/hosts file on all three servers to include the private IPs of the cluster:

10.0.0.11 gluster-node01
10.0.0.12 gluster-node02
10.0.0.13 gluster-node03

Next, synchronize the package repositories and upgrade the system packages to their latest versions across all nodes:

sudo apt update && sudo apt upgrade -y

GlusterFS relies heavily on accurate timestamps for file locking and replication state. Install and enable the systemd-timesyncd service to ensure time synchronization across the cluster:

sudo apt install systemd-timesyncd -y
sudo systemctl enable --now systemd-timesyncd

Step 2: Preparing the Storage Bricks

In GlusterFS terminology, a brick represents a directory on a physical filesystem that contributes storage to a volume. For production environments, it is strongly recommended to use a separate, dedicated disk or partition formatted with XFS rather than using the root filesystem.

Assuming you have attached an additional volume to each Hetzner instance (e.g., /dev/sdb), format the disk with the XFS file system:

sudo mkfs.xfs -f /dev/sdb

Create a mount point and configure /etc/fstab to ensure the storage persistence across reboots:

sudo mkdir -p /mnt/gluster_brick
echo '/dev/sdb /mnt/gluster_brick xfs defaults 0 0' | sudo tee -a /etc/fstab
sudo mount -a

Once mounted, create the specific directory inside that mount point which will serve as the actual GlusterFS brick:

sudo mkdir -p /mnt/gluster_brick/ha_vol

Step 3: Installing GlusterFS Server

Ubuntu's default repositories contain GlusterFS packages, but to ensure long-term stability and access to security patches, it is best practice to use the official Gluster upstream PPA. Execute the following commands on all three nodes:

sudo apt install software-properties-common -y
sudo add-apt-repository ppa:gluster/glusterfs-11 -y
sudo apt update
sudo apt install glusterfs-server -y

After installation, start the GlusterFS management daemon and enable it to launch automatically during system boot:

sudo systemctl start glusterd
sudo systemctl enable glusterd

Verify that the service is active and running smoothly:

sudo systemctl status glusterd

Step 4: Establishing the Trusted Storage Pool

At this stage, the nodes are running independent GlusterFS daemons. We must link them together into a single trusted storage pool. This operation only needs to be executed from one single node (e.g., gluster-node01).

From gluster-node01, probe the other two instances via their private network hostnames:

sudo gluster peer probe gluster-node02
sudo gluster peer probe gluster-node03

To confirm that the cluster relationship has been successfully established, execute the peer status command:

sudo gluster peer status

The output should indicate that two peers are connected, listing their hostnames and state as "Peer in Cluster".

Step 5: Creating and Starting the Replicated Volume

With the trusted storage pool active, we can now define our high-availability volume. We will create a 3-way replicated volume named ha-shared-volume. Run this command from gluster-node01:

sudo gluster volume create ha-shared-volume replica 3 \
  gluster-node01:/mnt/gluster_brick/ha_vol \
  gluster-node02:/mnt/gluster_brick/ha_vol \
  gluster-node03:/mnt/gluster_brick/ha_vol

Once the volume creation is successful, initiate the volume to make it available for client connections:

sudo gluster volume start ha-shared-volume

Check the global configuration and health status of your newly created storage layer:

sudo gluster volume info

Step 6: Mounting and Testing the High-Availability Volume

Now that the backend is fully operational, any application server (client) can mount the volume. To test this locally, we can mount the volume on our existing servers using the native GlusterFS client hardware.

Install the client driver package on your application server:

sudo apt install glusterfs-client -y

Create a dedicated directory where your applications will access the shared files:

sudo mkdir -p /shared/data

Mount the volume. A major advantage of the native GlusterFS client is its built-in failover capabilities. When mounting, you specify one node; if that node goes down, the client automatically switches to another node in the cluster seamlessly:

sudo mount -t glusterfs gluster-node01:/ha-shared-volume /shared/data

Verifying Self-Healing and Redundancy

To simulate a production failure, create a test file within the mounted directory on gluster-node01:

echo "High-Availability Test Data" | sudo tee /shared/data/test.txt

Verify that the file immediately replicates to the remaining bricks by checking the file system paths on gluster-node02 and gluster-node03. To test resilience, forcefully power off gluster-node01 via the Hetzner Cloud Console. You will observe that your application servers can still read and write to /shared/data without interruption, proving the efficacy of your high-availability storage solution.

Conclusion and Operational Best Practices

Deploying a 3-node GlusterFS cluster on Hetzner Cloud delivers a resilient, scalable, and economical shared storage layer tailored for highly available production workloads. By leveraging private networking and XFS bricks, you eliminate critical single points of failure. However, building the cluster is only the first step. For optimal lifecycle management, ensure you implement structured monitoring for brick health, configure proper alert routing for split-brain anomalies, and perform routine backup procedures. This proactive stance ensures your decentralized data storage remains highly performant and secure against unexpected infrastructure degradation.