Gluster users - May 2017 - Add single server

On 05/01/2017 02:36 PM, Pranith Kumar Karampuri wrote:
>
>
> On Tue, May 2, 2017 at 12:04 AM, Gandalf Corvotempesta
> <gandalf.corvotempesta at gmail.com
> <mailto:gandalf.corvotempesta at gmail.com>> wrote:
>
>     2017-05-01 20:30 GMT+02:00 Shyam <srangana at redhat.com
>     <mailto:srangana at redhat.com>>:
>     > Yes, as a matter of fact, you can do this today using the CLI and
creating
>     > nx2 instead of 1x2. 'n' is best decided by you, depending
on the growth
>     > potential of your cluster, as at some point 'n' wont be
enough if you grow
>     > by some nodes.
>     >
>     > But, when a brick is replaced we will fail to address "(a)
ability to retain
>     > replication/availability levels" as we support only
homogeneous replication
>     > counts across all DHT subvols. (I could be corrected on this when
using
>     > replace-brick though)
>
>
>     Yes, but this is error prone.
>
>
> Why?
To add to Pranith's question, (and to touch a raw nerve, my apologies) 
there is no rebalance in this situation (yet), if you notice.

I do agree that for the duration a brick is replaced its replication 
count is down by 1, is that your concern? In which case I do note that 
without (a) above, availability is at risk during the operation. Which 
needs other strategies/changes to ensure tolerance to errors/faults.
>
>
>
>     I'm still thinking that saving (I don't know where, I don't
know how)
>     a mapping between
>     files and bricks would solve many issues and add much more flexibility.
>
>
>
>
> --
> Pranith

2017-05-01 20:43 GMT+02:00 Shyam <srangana at
redhat.com>:
> I do agree that for the duration a brick is replaced its replication count
> is down by 1, is that your concern? In which case I do note that without
(a)
> above, availability is at risk during the operation. Which needs other
> strategies/changes to ensure tolerance to errors/faults.
Oh, yes, i've forgot this too.

I don't know Ceph, but Lizard, when moving chunks across the cluster,
does a copy, not a movement
During the whole operation you'll end with some files/chunks
replicated more than the requirement.

If you have a replica 3, during the movement, some file get replica 4
In Gluster the same operation will bring you replica 2.

IMHO, this isn't a viable/reliable solution

Any change to change "replace-brick" to increase the replica count
during the operation ?