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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected] <mailto:[email protected]>
https://lists.gluster.org/mailman/listinfo/gluster-users
--
*/
/*
*/Cristian Del Carlo/*
/Target Solutions s.r.l.
/
/
/
*T***+39 0583 1905621
*F* +39 0583 1905675
*@* [email protected]
<mailto:[email protected]>
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
[email protected]
https://lists.gluster.org/mailman/listinfo/gluster-users
_______________________________________________
Gluster-users mailing list
[email protected]
https://lists.gluster.org/mailman/listinfo/gluster-users
