GlusterFS

GlusterFS Mount Protocol

GlusterFS is a distributed network file system designed for scalable cloud storage. It combines multiple storage servers into one shared filesystem and provides replication, failover, and high availability for workloads that require reliable shared data access.

GlusterFS Overview

GlusterFS operates through the FUSE interface and does not require a separate metadata server. Storage is distributed across several servers, allowing the filesystem to remain available and scalable as the topology grows.

Reliability Replicated data remains accessible when one of the participating storage servers becomes unavailable.
Failover Clients can continue working with replicated data after a storage brick failure.
Scalability Storage capacity and throughput can be increased by adding additional servers to the distributed topology.
No metadata server The FUSE-based architecture avoids the need for a separate server dedicated only to filesystem metadata.

Recommended Use Cases

Compared with NFS, GlusterFS is generally selected when storage reliability, concurrent access, write performance, and recovery from server failure are more important than maximum raw filesystem performance.

Choose GlusterFS for data protection

Gluster Native is recommended for topologies where backups, replication, and data availability are the primary requirements.

!

Choose NFS for performance-focused workloads

When the main requirement is maximum filesystem performance rather than replicated data safety, NFS may be the more suitable protocol.

Platform Support

The platform provides native GlusterFS support for the following container types:

Application containers All supported containers can use the Gluster Native client, except Alpine-based nodes.
Shared Storage Cluster Shared Storage Cluster nodes can operate as both Gluster Native clients and GlusterFS servers.

Replicated GlusterFS Volume

The platform configures a replicated GlusterFS volume to reduce the risk of data loss. Exact copies of the stored data are maintained on all participating bricks, so clients can continue accessing the data from another replica if one brick fails.

Volume type Replicated GlusterFS volume.
Data placement Identical copies of the data are stored on every configured brick.
Failure protection Data remains available from surviving replicas if a brick becomes unavailable.
Primary objective Improved reliability and data redundancy.
!

GlusterFS volume terminology

Do not confuse GlusterFS storage volumes with the container volumes used by Docker-based nodes on the platform. They are different storage concepts.

Automatic Configuration

The platform automatically prepares the standard GlusterFS configuration. These settings should not be modified manually because they are used by the platform’s storage-management and scaling automation.

Default volume name The automatically configured GlusterFS volume is named data.
Server addresses The IP addresses of the participating storage servers are configured automatically.
Management Default GlusterFS settings are controlled by the platform and should remain unchanged.

Limitations

!

Sleeping environments

GlusterFS shares are unavailable while an environment is sleeping.

!

Live migration

Shared GlusterFS data is not available during a live migration operation.

!

Custom volumes

Custom GlusterFS volumes can be created through SSH, but this is not recommended because custom configurations have limited integration with platform features such as automated scaling.

Troubleshooting

When a GlusterFS operation fails, first review the Tasks Panel in the platform dashboard. The task details may identify configuration, mount, replication, or availability problems.

Additional diagnostic information is available from the following locations:

GlusterFS server logs Review files under /var/log/glusterfs on the GlusterFS server.
System journal Run journalctl on Shared Storage, custom container, or VPS nodes to inspect service and mount-related events.
Dashboard Tasks Panel Check the status and detailed output of the related storage or mounting operation.
journalctl

Share Data with GlusterFS

Use the platform’s Mount Points workflow or the Exporting Data workflow to make files available through the GlusterFS protocol.

Mount Points Attach an exported GlusterFS directory to another container or environment node.
Exporting Data Configure a directory as a shared source that can be mounted by supported client containers.

Expected result

Supported client containers can access the replicated shared directory through the platform-managed GlusterFS configuration.