<div dir="ltr"><div>Adding (back) gluster-users.</div><div><br></div><div>-Krutika<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 1:09 PM Krutika Dhananjay &lt;<a href="mailto:kdhananj@redhat.com">kdhananj@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 21, 2019 at 12:43 PM Cristian Del Carlo &lt;<a href="mailto:cristian.delcarlo@targetsolutions.it" target="_blank">cristian.delcarlo@targetsolutions.it</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Thanks Strahil,</div><div><br></div><div>in this link <a href="https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.4/html/administration_guide/sect-creating_replicated_volumes" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.4/html/administration_guide/sect-creating_replicated_volumes</a> i see:</div><div><br></div><div><i>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. <br></i></div><div><i><br></i></div><div>The deafult setting in GusterFS 6.1 appears to be:</div>                              <br><div>features.shard-block-size               64MB                                    <br>features.shard-lru-limit                16384                                   <br>features.shard-deletion-rate            100 <br></div></div></div></blockquote><div><br></div><div>That&#39;s right. Based on the tests we&#39;d conducted internally, we&#39;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&#39;t fit your needs.</div><div><br></div><div>-Krutika</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div></div><div><br></div><div>Bricks in my case are over an xfs filesystem. I&#39;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.</div><div><br></div><div>Very thanks for the warning, message received! :-)</div><div><br></div><div>Best Regards,</div><div><br></div><div>Cristian<br></div><div><br></div><div></div><div><i></i></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno gio 20 giu 2019 alle ore 22:13 Strahil Nikolov &lt;<a href="mailto:hunter86_bg@yahoo.com" target="_blank">hunter86_bg@yahoo.com</a>&gt; ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp678665a5yahoo-style-wrap" style="font-family:courier new,courier,monaco,monospace,sans-serif;font-size:16px"><div></div>
        <div>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.</div><div>RHV &amp; oVirt use a default shard size of 4M which is the exact size of the default PE in LVM.</div><div><br></div><div>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.</div><div>It is not a coincidence that RHV and oVirt use sharding by default.</div><div><br></div><div>Just a warning.</div><div>NEVER, EVER, DISABLE SHARDING!!! ONCE ENABLED - STAYS ENABLED!</div><div>Don&#39;t ask how I learnGrazie dell&#39;avviso, messaggio ricevuto!t that :)</div><div><br></div><div>Best Regards,</div><div>Strahil Nikolov</div><div><br></div><div><br></div><div><br></div>
        
        </div><div id="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yahoo_quoted_1362385886" class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yahoo_quoted">
            <div style="font-family:&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif;font-size:13px;color:rgb(38,40,42)">
                
                <div>
                    В четвъртък, 20 юни 2019 г., 18:32:00 ч. Гринуич+3, Cristian Del Carlo &lt;<a href="mailto:cristian.delcarlo@targetsolutions.it" target="_blank">cristian.delcarlo@targetsolutions.it</a>&gt; написа:
                </div>
                <div><br></div>
                <div><br></div>
                <div><div id="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799"><div><div dir="ltr"><div>Hi,</div><div><br clear="none"></div><div>thanks for your help.</div><div><br clear="none"></div><div>I am planing to use libvirtd with plain KVM.</div><div><br clear="none"></div><div>Ok i will use libgfapi. <br clear="none"></div><div><br clear="none"></div><div>I&#39;m confused about the use of sharding is it useful in this configuration? Doesn&#39;t sharding help limit the bandwidth in the event of a rebalancing?</div><div><br clear="none"></div><div>In the vm setting so i need to use directsync to avoid corruption.</div><div><br clear="none"></div><div>Thanks again,<br clear="none"> </div></div><br clear="none"><div class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799gmail_quote"><div class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799gmail_attr" dir="ltr">Il giorno gio 20 giu 2019 alle ore 12:25 Strahil &lt;<a shape="rect" href="mailto:hunter86_bg@yahoo.com" rel="nofollow" target="_blank">hunter86_bg@yahoo.com</a>&gt; ha scritto:<br clear="none"></div><div class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799yqt4291059422" id="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799yqt39338"><blockquote class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><p dir="ltr">Hi,</p>
<p dir="ltr">Are you planing to use oVirt or plain KVM or openstack?</p>
<p dir="ltr">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.</p>
<p dir="ltr">Fuse vs libgfapi - use the latter as it has better performance and less overhead on the host.oVirt does supports both libgfapi and fuse.</p>
<p dir="ltr">Also, use replica 3 because you will have better read performance compared to replica 2 arbiter 1.</p>
<p dir="ltr">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).</p>
<p dir="ltr">If you will do live migration -  you do not want to cache in order to avoid  corruption.<br clear="none">
Thus oVirt is using direct I/O.<br clear="none">
Still, you can check the gluster settings mentioned in Red Hat documentation for Virt/openStack .</p>
<p dir="ltr">Best Regards,<br clear="none">
Strahil Nikolov</p>
<div class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799gmail-m_1444675035890430144quote">On Jun 20, 2019 13:12, Cristian Del Carlo &lt;<a shape="rect" href="mailto:cristian.delcarlo@targetsolutions.it" rel="nofollow" target="_blank">cristian.delcarlo@targetsolutions.it</a>&gt; wrote:<br clear="none"><blockquote class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799gmail-m_1444675035890430144quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi,</div><br clear="none">I&#39;m testing glusterfs before using it in production, it should be used to store vm for nodes with libvirtd.<br clear="none"><br clear="none"><div>In production I will have 4 nodes connected with a dedicated 20gbit/s network.</div><div><br clear="none"></div><div>Which version to use in production on a centos 7.x? Should I use Gluster version 6?</div><div><br clear="none"></div><div>To make the volume available to libvirtd the best method is to use FUSE?</div><div><br clear="none"></div><div>I see that stripped is deprecated. Is it reasonable to use the volume with 3 replicas on 4 nodes and  sharding enabled? <br clear="none"></div><div></div><div>Is there convenience to use sharding volume in this context? I think could positive inpact in read performance or rebalance. Is it true?<br clear="none"></div><div><br clear="none"></div>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?<div><br clear="none">Thanks in advance for your patience and answers.</div><div><br clear="none"></div><div>Thanks,<br clear="none"></div><div><div dir="ltr"><div dir="ltr"><div><br clear="none"></div><div><b><font color="#990000"><i><br clear="none"></i></font></b></div><div><b><font color="#990000"><i>Cristian Del Carlo</i></font></b><br clear="none"></div><div></div></div></div></div></div>
</blockquote></div></blockquote></div></div><br clear="all"><br clear="none">-- <br clear="none"><div class="gmail-m_-1175703377238968109gmail-m_-6718989892495721822gmail-m_-4360627142264084429ydp93be247yiv2327294799gmail_signature" dir="ltr"><div dir="ltr"><div><span></span><span></span><br clear="none"></div><div><font><b><font color="#990000"><i><br clear="none"></i></font></b></font></div><div><font><b><font color="#990000"><i>Cristian Del Carlo</i></font></b><br clear="none"></font></div><div></div><div><i><font>Target Solutions s.r.l.<br clear="none"></font></i></div><div><i><font><br clear="none"></font></i></div>

<div><font><span><b><font color="#ff0000">T</font></b><b> </b>+</span>39 0583 1905621</font></div><div><font><font color="#ff0000"><b>F</b></font> <a shape="rect">+39 0583 1905675</a></font></div><div>
<font><a shape="rect"></a></font></div><div><font><font color="#ff0000"><b>@</b></font> </font><font><a shape="rect" href="mailto:cristian.delcarlo@targetsolutions.it" rel="nofollow" target="_blank">cristian.delcarlo@targetsolutions.it</a></font><br clear="none"></div>

<div><br clear="none"><a shape="rect" href="http://www.targetsolutions.it/" rel="nofollow" target="_blank"><font>http://www.targetsolutions.it</font></a><br clear="none"><font>P.IVA e C.Fiscale: 01815270465  Reg. Imp. di Lucca<br clear="none">Capitale Sociale:  €11.000,00 iv - REA n° 173227<br clear="none">
<br clear="none"></font><font size="1">Il
 testo e gli eventuali documenti trasmessi contengono informazioni 
riservate al destinatario indicato. La seguente e-mail e&#39; confidenziale e
 la sua riservatezza e&#39; 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.</font></div></div></div></div></div></div>
            </div>
        </div></div></blockquote></div><br clear="all"><br><br></div>
_______________________________________________<br>
Gluster-users mailing list<br>
<a href="mailto:Gluster-users@gluster.org" target="_blank">Gluster-users@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-users</a></blockquote></div></div>
</blockquote></div>