GlusterFS on Ubuntu 24.04 on Azure User Guide

Overview

GlusterFS is a mature, open source, POSIX compliant distributed file system. It aggregates storage from a set of servers into a single namespace and presents it as an ordinary directory tree, so applications read and write files exactly as they would on a local disk while the data underneath is distributed across bricks and, once you add peers, replicated. The cloudimg image installs the stock upstream GlusterFS 11 server from the Ubuntu 24.04 archive, configures a single node distribute volume named gv0 with one brick on a dedicated Azure data disk, and mounts that volume with the native GlusterFS FUSE client at /srv/glusterfs, ready to use the moment first boot completes. Backed by 24/7 cloudimg support.

What is included:

• GlusterFS 11 (glusterd, the native FUSE client and the gluster CLI), managed by systemd
• A single node distribute volume gv0, started, with one brick at /data/brick1/gv0
• Persistent brick storage on a dedicated 40 GiB Azure data disk formatted xfs and mounted at /data
• The volume already mounted with the native client at /srv/glusterfs
• An nftables host firewall that drops the entire GlusterFS protocol on every non loopback interface
• 24/7 cloudimg support

This is a storage product. GlusterFS has no native login, so the appliance keeps the whole storage protocol off the network: glusterd (ports 24007-24008) and the brick (ports 49152-49200) are firewalled to the local machine and reached only through the local mount. This is a single node starter volume: one node holds one copy of every file, so it is an evaluation and starter topology, not a redundant one - the final step of this guide shows how to grow it into a replicated multi node cluster.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a good starting point. NSG inbound: allow 22/tcp from your management network. No inbound application ports are needed, because the GlusterFS protocol is deliberately not exposed - the volume is used through the local mount on the VM.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for GlusterFS by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) only. Then Review + create -> Create. The dedicated data disk that holds the brick is provisioned automatically from the image.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name glusterfs \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm GlusterFS is installed and running

Check the server version, that the daemon, the mount unit and the host firewall are all active, and that the volume is mounted with the native client:

glusterd --version | head -1
systemctl is-active glusterd glusterfs-mount nftables
findmnt -no SOURCE,FSTYPE,TARGET /srv/glusterfs

You should see GlusterFS 11, three active services, and the native FUSE mount at /srv/glusterfs:

glusterfs 11.1
active
active
active
gfs-node:/gv0 fuse.glusterfs /srv/glusterfs

Step 5 - Inspect the volume

The gluster CLI is the GlusterFS admin tool. Print the volume definition and its runtime status - one distribute volume, Started, with its single brick Online:

sudo gluster volume info gv0
sudo gluster volume status gv0

Volume Name: gv0
Type: Distribute
Volume ID: fc57bed4-48c7-48e4-9283-b8d0a0a16746
Status: Started
Number of Bricks: 1
Transport-type: tcp
Bricks:
Brick1: gfs-node:/data/brick1/gv0

Status of volume: gv0
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick gfs-node:/data/brick1/gv0             49153     0          Y       ...

Status: Started and Online: Y confirm the volume is live and serving. The brick lives on the dedicated data disk mounted at /data, not on the OS disk.

Step 6 - Read and write through the mount

The volume is mounted at /srv/glusterfs. Write a file through the mount, read it back, and see it land on the brick - GlusterFS is storing and serving your data:

echo "hello from cloudimg" | sudo tee /srv/glusterfs/hello.txt
sudo cat /srv/glusterfs/hello.txt
sudo sha256sum /srv/glusterfs/hello.txt
sudo find /data/brick1/gv0 -maxdepth 1 -name hello.txt -printf '%M %u %g %s %p\n'
sudo rm -f /srv/glusterfs/hello.txt

hello from cloudimg
hello from cloudimg
b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9  /srv/glusterfs/hello.txt
-rw-r--r-- root root 20 /data/brick1/gv0/hello.txt

The file you wrote through /srv/glusterfs appears on the brick at /data/brick1/gv0 - the mount and the brick are two views of the same data. Point your applications at /srv/glusterfs and use it like any other directory.

Step 7 - Security: the protocol is firewalled to the machine

GlusterFS has no native username or password; its access control is IP based plus the host firewall. This image ships an nftables table that drops every GlusterFS port on every interface except loopback, so nothing that speaks the GlusterFS protocol is reachable from outside the VM, whatever your NSG allows. Inspect it:

sudo nft list table inet cloudimg_glusterfs
ss -H -lnt 'sport = :24007'

table inet cloudimg_glusterfs {
        chain input {
                type filter hook input priority filter; policy accept;
                iif "lo" accept
                tcp dport { 24007-24008, 38465-38467, 49152-49200 } drop
        }
}
LISTEN 0      1024         0.0.0.0:24007      0.0.0.0:*

glusterd listens on the machine, but the nftables drop rule makes ports 24007-24008 and the brick ports 49152-49200 unreachable from any non loopback interface. The local FUSE mount still works because locally destined traffic goes through the loopback path. Access the storage through the mount at /srv/glusterfs, or export it over your own protected protocol (for example NFS or SMB, secured and firewalled to suit your environment).

Step 8 - Per-VM connection info

First boot writes a root only note describing this VM's volume, brick and mount. There is no login credential - the file is a convenience reference, not a secret:

sudo cat /root/glusterfs-info.txt

Step 9 - Grow into a replicated multi-node cluster

A single node holds one copy of every file, so this VM on its own has no fault tolerance. To get redundancy, deploy one or more additional GlusterFS nodes, peer them, and convert the volume to a replicated type. In outline, on a second node deployed the same way:

# On this (first) node, allow the peer's address to the GlusterFS ports, then peer it:
sudo nft insert rule inet cloudimg_glusterfs input ip saddr <peer-private-ip> tcp dport 24007 accept
sudo nft insert rule inet cloudimg_glusterfs input ip saddr <peer-private-ip> tcp dport 49152-49200 accept
sudo gluster peer probe <peer-private-ip>

# Add a brick on the peer and raise the replica count to 2:
sudo gluster volume add-brick gv0 replica 2 <peer-private-ip>:/data/brick1/gv0
sudo gluster volume info gv0

Open the same GlusterFS ports between the nodes in your Azure NSG as well, keeping them closed to the public internet. With replica 2 every file is written to both nodes, so the volume survives the loss of either one. See the GlusterFS documentation for replicated and dispersed volume types and for tuning.

Support

This image is maintained by cloudimg with 24/7 support and a guaranteed 24 hour response SLA. GlusterFS is open source, dual licensed under the GNU General Public License version 2 and the GNU Lesser General Public License version 3; there is no per node or per capacity fee. The cloudimg charge covers packaging, security patching, image maintenance and support.