A distributed replicated GlusterFS volume fits clusters that need more capacity than one replica set can provide while still keeping redundant copies of each file. The create command is layout-sensitive because every consecutive group of bricks becomes one replica set, so a wrong brick order can put both copies of the same file on the same failure domain.
In the example below, replica 2 across four bricks creates two replica sets. The distribute layer places new files across those sets, and each set keeps two copies of the files assigned to it. The same pattern can be expanded with more bricks, but the total brick count must stay a multiple of the replica count.
Use dedicated brick filesystems, stable hostnames, and an agreed brick order before running gluster volume create. Start the volume before mounting it from clients, and treat force as an exception because it can bypass placement and brick-path checks that protect the intended replica layout.
Steps to create a distributed replicated GlusterFS volume:
- Confirm every storage peer is connected to the trusted pool.
$ sudo gluster peer status Number of Peers: 3 Hostname: node2 Uuid: 0f3e0b7c-2e59-4c73-9c1c-3e65b6c1e8c9 State: Peer in Cluster (Connected) Hostname: node3 Uuid: 8b7e3e2a-1a6e-4f2b-b4a6-2a0b9a4f7a6d State: Peer in Cluster (Connected) Hostname: node4 Uuid: 4c91a40e-77f5-4e25-b4a8-9f2a06cbb7d9 State: Peer in Cluster (Connected)
Use hostnames that resolve the same way from every peer before adding them to a volume definition.
- Choose the replica count and brick order.
For replica 2, bricks 1 and 2 form the first replica set, bricks 3 and 4 form the second replica set, and so on. Keep each set on separate nodes, racks, or storage fault domains when that protection matters.
- Create an empty brick directory below the brick filesystem on each participating peer.
$ sudo mkdir -p /srv/gluster/brick1/brick
Use dedicated storage for production bricks, and place the brick directory below the filesystem mount point instead of using the mount point itself.
- Create the distributed replicated volume from one peer in the trusted pool.
$ sudo gluster volume create volume1 replica 2 transport tcp \ node1:/srv/gluster/brick1/brick node2:/srv/gluster/brick1/brick \ node3:/srv/gluster/brick1/brick node4:/srv/gluster/brick1/brick volume create: volume1: success: please start the volume to access data
The first two bricks become one replica set, and the next two become the second replica set. Current GlusterFS documentation treats tcp as the default transport, but keeping it explicit makes the volume definition easier to review.
Do not add force unless the brick placement warning is understood and accepted. A forced layout can bypass safety checks that protect replica-set separation.
- Start the new volume.
$ sudo gluster volume start volume1 volume start: volume1: success
Start the volume before mounting it, because client operations can hang when a stopped volume is mounted.
- Verify the volume type and replica layout.
$ sudo gluster volume info volume1 Volume Name: volume1 Type: Distributed-Replicate Status: Started Snapshot Count: 0 Number of Bricks: 2 x 2 = 4 Transport-type: tcp Bricks: Brick1: node1:/srv/gluster/brick1/brick Brick2: node2:/srv/gluster/brick1/brick Brick3: node3:/srv/gluster/brick1/brick Brick4: node4:/srv/gluster/brick1/brick
- Verify every brick and self-heal daemon is online.
$ sudo gluster volume status volume1 Status of volume: volume1 Gluster process TCP Port RDMA Port Online Pid ------------------------------------------------------------------------------- Brick node1:/srv/gluster/brick1/brick 49152 0 Y 2214 Brick node2:/srv/gluster/brick1/brick 49153 0 Y 2279 Brick node3:/srv/gluster/brick1/brick 49154 0 Y 2306 Brick node4:/srv/gluster/brick1/brick 49155 0 Y 2351 Self-heal Daemon on node1 N/A N/A Y 2410 Self-heal Daemon on node2 N/A N/A Y 2446 Self-heal Daemon on node3 N/A N/A Y 2481 Self-heal Daemon on node4 N/A N/A Y 2528 Task Status of Volume volume1 ------------------------------------------------------------------------------- There are no active volume tasks
Related: How to check GlusterFS volume status
- Mount the started volume from a client after the brick status is online.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
