[Gluster-users] Volume to store vm

Sat Sep 7 20:46:15 UTC 2019

Hi Carlo,

Very good question: IMO it's a matter of compromise between having lots of small 
files to heal and how long it takes to heal each one shard.

With small shards, it increases probability to have to self-heal more files in a 
failure, also it means latency in metadata of each file could be significant 
versus time to transfer rsync deltas.

With big shards, time to rsync could be very long.

You need to find a size something enough big for avoid latency affects 
significantly to self-heal process and so small to avoid rsync delta take too 
much time....

We found 256MB shard size for distributed-replicated (replica 2 o 3) volumes is 
good enough and also we recommend to use 512MB shard size for volumes 
distributed-dispersed 3 redundancy 1. For volumes distributed-dispersed 6 
redundancy 2 we use 1024MB as shard size.

Hope this helps!

El 07/09/19 a les 15:04, Cristian Del Carlo ha escrit:
> Thank you Ramon for your answer.
>
> The only thing I can't understand is why to use such a big shard?
> The default is 64MB. I thought maybe to decrease it, I wanted to do some tests 
> on it.
>
> Best regards,
>
>
> Il giorno ven 6 set 2019 alle ore 23:09 Ramon Selga <ramon.selga at gmail.com 
> <mailto:ramon.selga at gmail.com>> ha scritto:
>
>     Hi Cristian,
>
>     Both approaches are correct but they have different usable capacity and
>     tolerance to node failures.
>
>     First one is a full replica 3 meaning you get your total node capacity
>     divided by 3, because replica 3, and it tolerates a simultaneous of two
>     nodes and very good for split-brain avoidance.
>
>     Second one is a replica 2 with arbiter, also very good for split-brain
>     avoidance (that's purpose of arbiter bricks). In this case you get your
>     total capacity divided by two except a little space going to
>     arbiter-bricks, may be less than 1% of normal storage bricks. It tolerates
>     one node failure at the same time.
>
>     For VM usage remember to enable sharding with a shard size of 256MB at
>     least before use volume.
>
>     If efficiency between total and usable capacity is a concern for you and
>     you think you could tolerate only one node failure at the same time, may I
>     suggest you to use a distributed dispersed 3 redundancy 1 volume?. You
>     will get your total capacity divided by 3 times 2 (that's 2/3 of total
>     capacity) and this config still tolerates one node failure at the same time.
>
>     Hope this helps.
>
>     *Ramon Selga*
>
>     934 76 69 10
>     670 25 37 05
>
>     DataLab SL <http://www.datalab.es/>
>
>
>     Aviso Legal <http://www.datalab.es/cont_cas/legal.html>
>
>
>
>
>     El 06/09/19 a les 17:11, Cristian Del Carlo ha escrit:
>>     Hi,
>>
>>     I have an environment consisting of 4 nodes ( with large disks).
>>     I have to create a volume to contain image of virtual machines.
>>
>>     In documentation i read:
>>     /Hosting virtual machine images requires the consistency of three-way
>>     replication,
>>     which is provided by three-way replicated volumes, three-way distributed
>>     replicated volumes,
>>     arbitrated replicated volumes, and distributed arbitrated replicated
>>     volumes. /
>>
>>     So I'm going to confusion to configure this volume.
>>     I have 4 nodes and I don't want to lose space by dedicating one to the
>>     function of arbiter.
>>
>>     Would it be reasonable to configure the volume as in these two examples?
>>
>>     # gluster volume create test1 replica 3 \
>>     server1:/bricks/brick1 server2:/bricks/brick1 server3:/bricks/brick1 \
>>     server2:/bricks/brick2 server3:/bricks/brick2 server4:/bricks/brick2 \
>>     server3:/bricks/brick3 server4:/bricks/brick3 server1:/bricks/brick3 \
>>     server4:/bricks/brick4 server1:/bricks/brick4 server2:/bricks/brick4
>>
>>     # gluster volume create test1 replica 3 arbiter 1 \
>>     server1:/bricks/brick1 server2:/bricks/brick1
>>     server3:/bricks/arbiter_brick1 \
>>     server2:/bricks/brick2 server3:/bricks/brick2
>>     server4:/bricks/arbiter_brick2 \
>>     server3:/bricks/brick3 server4:/bricks/brick3
>>     server1:/bricks/arbiter_brick3 \
>>     server4:/bricks/brick4 server1:/bricks/brick4 server2:/bricks/arbiter_brick4
>>
>>     Thanks,
>>
>>     -- 
>>
>>     */
>>     /*
>>     */Cristian Del Carlo/*
>>
>>
>>
>>     _______________________________________________
>>     Gluster-users mailing list
>>     Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>>     https://lists.gluster.org/mailman/listinfo/gluster-users
>
>     _______________________________________________
>     Gluster-users mailing list
>     Gluster-users at gluster.org <mailto:Gluster-users at gluster.org>
>     https://lists.gluster.org/mailman/listinfo/gluster-users
>
>
>
> -- 
>
> */
> /*
> */Cristian Del Carlo/*
> /Target Solutions s.r.l.
> /
> /
> /
> *T***+39 0583 1905621
> *F* +39 0583 1905675
> *@* cristian.delcarlo at targetsolutions.it 
> <mailto:cristian.delcarlo at targetsolutions.it>
>
> http://www.targetsolutions.it <http://www.targetsolutions.it/>
> P.IVA e C.Fiscale: 01815270465  Reg. Imp. di Lucca
> Capitale Sociale:  €11.000,00 iv - REA n° 173227
>
> Il testo e gli eventuali documenti trasmessi contengono informazioni riservate 
> al destinatario indicato. La seguente e-mail e' confidenziale e la sua 
> riservatezza e' tutelata legalmente dal Decreto Legislativo 196 del 30/06/2003 
> (Codice di tutela della privacy). La lettura, copia o altro uso non 
> autorizzato o qualsiasi altra azione derivante dalla conoscenza di queste 
> informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo 
> documento per errore siete cortesemente pregati di darne immediata 
> comunicazione al mittente e di provvedere, immediatamente, alla sua distruzione.
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190907/23ecf6a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m_-5423031927693632057_Imatge1
Type: image/png
Size: 164 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190907/23ecf6a0/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: m_-5423031927693632057_DataLab            sl
Type: image/png
Size: 483 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/gluster-users/attachments/20190907/23ecf6a0/attachment-0001.png>