[Gluster-users] Expand distributed replicated volume

Anuradha Talur atalur at redhat.com
Tue Jul 12 07:46:00 UTC 2016



----- Original Message -----
> From: "Gandalf Corvotempesta" <gandalf.corvotempesta at gmail.com>
> To: "Anuradha Talur" <atalur at redhat.com>
> Cc: "gluster-users" <Gluster-users at gluster.org>
> Sent: Thursday, July 7, 2016 10:14:46 PM
> Subject: Re: [Gluster-users] Expand distributed replicated volume
> 
> Il 07 lug 2016 13:18, "Anuradha Talur" <atalur at redhat.com> ha scritto:
> > Node to the cluster? You can add one per time.
> >
> > If you are asking about adding the number of bricks to a volume,
> > in case of replica 3, if you want to keep the replica count same (3)
> > then you have to add 3 bricks. These three bricks will be taken as a
> > new replica group added to the volume.
> >
> > If you want to increase the replica count to 4, then you will have to
> > add one brick each to all the existing replica groups. So that the
> > replica groups now have 4 bricks each.
> >
> > Hope this resolves your query.
> 
> Lets assume a 3 nodes cluster,  replica 3, 6 1tb disks per node, 1 brick
> per disk.
> 
> i would like to increase space and thus add a new node.
> Can i add a single node with 3 disks/bricks and automatically rebalance?

Yes you can add single node with 3 bricks. But, given that you are keeping the replica count
same, these three bricks will be replica of each other. It is not so useful in case of node
failures/shutdown.

> In this case, gluster moves data around to use the maximum number or disks
> for performance reasons?
> 
There are 2 ways to trigger rebalance after adding brick,
1) without force option : This will not move data. But will add linkto files.
Think of them as symbolic links. Files will reside in the bricks where they already exist,
but will have links in the new bricks.
2) With force option : This will actually move the data from old bricks to new bricks.

Both these operations will be done only for those files that need to
be migrated.

The new files will either
1) be created in new bricks if they hash to new bricks.
or
2) be created in new bricks even though they hash to old bricks and old bricks will
have linkto files.

If there is no space in old bricks to create linkto files too, the operation will
fail with ENOSPC (no space available).

I'm cc'ing developers from DHT team in case you have more questions with respect to
rebalance.
> We start with 18tb raw, 18 disks, 6tb usable, 100% used (6tb on 6 usable
> disks)
> After adding the new node with 3 disks we will end with 7tb usable.
> all disks would be used as 6tb/7=0.85% right?
> 

-- 
Thanks,
Anuradha.


More information about the Gluster-users mailing list