<div dir="ltr"><span style="color:rgb(0,0,0)">Hello Gionatan,</span><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)"> Using Gluster brick in a RAID configuration might be safer and require less work from Gluster admins but, it is a waste of disk space.</div><div style="color:rgb(0,0,0)">Gluster bricks are replicated &quot;assuming you&#39;re creating a distributed-replica volume&quot; so when brick went down, it should be easy to recover it and should not affect the client&#39;s IO.</div><div style="color:rgb(0,0,0)">We are using JBOD in all of our Gluster setups, overall, performance is good, and replacing a brick would work &quot;most&quot; of the time without issues.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 21, 2020 at 8:43 PM Gionatan Danti &lt;<a href="mailto:g.danti@assyoma.it">g.danti@assyoma.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">Il 2020-06-21 14:20 Strahil Nikolov ha scritto:<br>
&gt; With  every community project ,  you are in the position  of a Betta<br>
&gt; Tester  - no matter Fedora,  Gluster  or CEPH. So far  ,  I had<br>
&gt; issues with upstream  projects only diring and immediately after<br>
&gt; patching  - but this is properly mitigated  with a  reasonable<br>
&gt; patching strategy (patch  test environment and several months later<br>
&gt; patch prod with the same repos).<br>
&gt; Enterprise  Linux breaks (and alot) having 10-times more  users and<br>
&gt; use  cases,  so you cannot expect to start to use  Gluster  and assume<br>
&gt; that a  free  peoject won&#39;t break at all.<br>
&gt; Our part in this project is to help the devs to create a test case for<br>
&gt; our workload ,  so  regressions will be reduced to minimum.<br>
<br>
Well, this is true, and both devs &amp; community deserve a big thanks for <br>
all the work done.<br>
<br>
&gt; In the past 2  years,  we  got 2  major  issues with VMware VSAN and 1<br>
&gt;  major  issue  with  a Enterprise Storage cluster (both solutions are<br>
&gt; quite  expensive)  - so  I always recommend proper  testing  of your<br>
&gt; software .<br>
<br>
Interesting, I am almost tempted to ask you what issue you had with <br>
vSAN, but this is not the right mailing list ;)<br>
<br>
&gt; From my observations,  almost nobody  is complaining about Ganesha in<br>
&gt; the mailing list -&gt; 50% are  having issues  with geo replication,20%<br>
&gt; are  having issues with small file performance and the rest have<br>
&gt; issues with very old version of gluster  -&gt; v5 or older.<br>
<br>
Mmm, I would swear to have read quite a few posts where the problem was <br>
solved by migrating away from NFS Ganesha. Still, for hyperconverged <br>
setup a problem remains: NFS on loopback/localhost is not 100% supported <br>
(or, at least, RH is not willing to declare it supportable/production <br>
ready [1]). A fuse mount would be the more natural way to access the <br>
underlying data.<br>
<br>
&gt; I  can&#39;t say that a  replace-brick  on a &#39;replica  3&#39; volume is more<br>
&gt; riskier  than a rebuild  of a raid,  but I have noticed that nobody is<br>
&gt;  following Red Hat&#39;s  guide  to use  either:<br>
&gt; -  a  Raid6  of 12  Disks (2-3  TB  big)<br>
&gt; -  a Raid10  of  12  Disks (2-3  TB big)<br>
&gt; -  JBOD disks in &#39;replica  3&#39; mode (i&#39;m not sure about the size  RH<br>
&gt; recommends,  most probably 2-3 TB)<br>
&gt;  So far,  I didn&#39; have the opportunity to run on JBODs.<br>
<br>
For the RAID6/10 setup, I found no issues: simply replace the broken <br>
disk without involing Gluster at all. However, this also means facing <br>
the &quot;iops wall&quot; I described earlier for single-brick node. Going <br>
full-Guster with JBODs would be interesting from a performance <br>
standpoint, but this complicate eventual recovery from bad disks.<br>
<br>
Does someone use Gluster in JBOD mode? If so, can you share your <br>
experience?<br>
Thanks.<br>
<br>
[1] <a href="https://access.redhat.com/solutions/22231" rel="noreferrer" target="_blank">https://access.redhat.com/solutions/22231</a> (accound required)<br>
[2] <a href="https://bugzilla.redhat.com/show_bug.cgi?id=489889" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=489889</a> (old, but I can <br>
not find anything newer)<br>
<br>
-- <br>
Danti Gionatan<br>
Supporto Tecnico<br>
Assyoma S.r.l. - <a href="http://www.assyoma.it" rel="noreferrer" target="_blank">www.assyoma.it</a> [1]<br>
email: <a href="mailto:g.danti@assyoma.it" target="_blank">g.danti@assyoma.it</a> - <a href="mailto:info@assyoma.it" target="_blank">info@assyoma.it</a><br>
GPG public key ID: FF5F32A8<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Respectfully<div>Mahdi</div></div></div>