Re: Volume to store vm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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


Aviso Legal




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@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users


--


Cristian Del Carlo
Target Solutions s.r.l.

T +39 0583 1905621

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@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users

_______________________________________________
Gluster-users mailing list
Gluster-users@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-users

[Index of Archives]     [Gluster Development]     [Linux Filesytems Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux