Re: General questions

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

 



Adding (back) gluster-users.

-Krutika

On Fri, Jun 21, 2019 at 1:09 PM Krutika Dhananjay <kdhananj@xxxxxxxxxx> wrote:


On Fri, Jun 21, 2019 at 12:43 PM Cristian Del Carlo <cristian.delcarlo@xxxxxxxxxxxxxxxxxx> wrote:
Thanks Strahil,


Sharding has one supported use case: in the context of providing Red Hat Gluster Storage as a storage domain for Red Hat Enterprise Virtualization, to provide storage for live virtual machine images. Note that sharding is also a requirement for this use case, as it provides significant performance improvements over previous implementations.

The deafult setting in GusterFS 6.1 appears to be:
                             
features.shard-block-size               64MB                                    
features.shard-lru-limit                16384                                  
features.shard-deletion-rate            100

That's right. Based on the tests we'd conducted internally, we'd found 64MB to be a good number both in terms of self-heal and IO performance. 4MB is a little on the lower side in that sense. The benefits of some features like eager-locking are lost if the shard size is too small. You can perhaps run some tests with 64MB shard-block-size to begin with, and tune it if it doesn't fit your needs.

-Krutika


Bricks in my case are over an xfs filesystem. I'll try different block-size but if I understand correctly, small block sizes are preferable to big block sizes and If i have doubt I will put 4M.

Very thanks for the warning, message received! :-)

Best Regards,

Cristian


Il giorno gio 20 giu 2019 alle ore 22:13 Strahil Nikolov <hunter86_bg@xxxxxxxxx> ha scritto:
Sharding is complex. It helps to heal faster -as only the shards that got changed will be replicated, but imagine a 1GB shard that got only 512k updated - in such case you will copy the whole shard to the other replicas.
RHV & oVirt use a default shard size of 4M which is the exact size of the default PE in LVM.

On the other side, it speeds stuff as gluster can balance the shards properly on the replicas and thus you can evenly distribute the load on the cluster.
It is not a coincidence that RHV and oVirt use sharding by default.

Just a warning.
NEVER, EVER, DISABLE SHARDING!!! ONCE ENABLED - STAYS ENABLED!
Don't ask how I learnGrazie dell'avviso, messaggio ricevuto!t that :)

Best Regards,
Strahil Nikolov



В четвъртък, 20 юни 2019 г., 18:32:00 ч. Гринуич+3, Cristian Del Carlo <cristian.delcarlo@xxxxxxxxxxxxxxxxxx> написа:


Hi,

thanks for your help.

I am planing to use libvirtd with plain KVM.

Ok i will use libgfapi.

I'm confused about the use of sharding is it useful in this configuration? Doesn't sharding help limit the bandwidth in the event of a rebalancing?

In the vm setting so i need to use directsync to avoid corruption.

Thanks again,

Il giorno gio 20 giu 2019 alle ore 12:25 Strahil <hunter86_bg@xxxxxxxxx> ha scritto:

Hi,

Are you planing to use oVirt or plain KVM or openstack?

I would recommend you to use gluster v6.1 as it is the latest stable version and will have longer support than the older versions.

Fuse vs libgfapi - use the latter as it has better performance and less overhead on the host.oVirt does supports both libgfapi and fuse.

Also, use replica 3 because you will have better read performance compared to replica 2 arbiter 1.

Sharding is a tradeoff  between CPU (when there is no sharding , gluster shd must calculate the offset of the VM disk) and bandwidth (whole shard  is being replicated despite even 512 need to be synced).

If you will do live migration -  you do not want to cache in order to avoid  corruption.
Thus oVirt is using direct I/O.
Still, you can check the gluster settings mentioned in Red Hat documentation for Virt/openStack .

Best Regards,
Strahil Nikolov

On Jun 20, 2019 13:12, Cristian Del Carlo <cristian.delcarlo@xxxxxxxxxxxxxxxxxx> wrote:
Hi,

I'm testing glusterfs before using it in production, it should be used to store vm for nodes with libvirtd.

In production I will have 4 nodes connected with a dedicated 20gbit/s network.

Which version to use in production on a centos 7.x? Should I use Gluster version 6?

To make the volume available to libvirtd the best method is to use FUSE?

I see that stripped is deprecated. Is it reasonable to use the volume with 3 replicas on 4 nodes and  sharding enabled?
Is there convenience to use sharding volume in this context? I think could positive inpact in read performance or rebalance. Is it true?

In the vm configuration I use the virtio disk. How is it better to set the disk cache to get the best performances none, default or writeback?

Thanks in advance for your patience and answers.

Thanks,


Cristian Del Carlo


--


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