<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 10 Sep 2020 at 21:53, Gionatan Danti <<a href="mailto:g.danti@assyoma.it">g.danti@assyoma.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">Il 2020-09-09 15:30 Miguel Mascarenhas Filipe ha scritto:<br>
> I'm setting up GlusterFS on 2 hw w/ same configuration, 8 hdds. This<br>
> deployment will grow later on.<br>
<br>
Hi, I really suggest avoiding a replica 2 cluster unless it is for <br>
testing only. Be sure to add an arbiter at least (using a replica 2 <br>
arbiter 1 cluster).<br>
<br>
> I'm undecided between these different configurations and am seeing<br>
> comments or advice from more experienced users of GlusterFS.<br>
> <br>
> Here is the summary of 3 options:<br>
> 1. 1 brick per host, Gluster "distributed" volumes, internal<br>
> redundancy at brick level<br>
<br>
I strongly suggest against it: any server reboot will cause troubles for <br>
mounted clients. I will end with *lower* uptime than a single server.<br>
<br>
> 2. 1 brick per drive, Gluster "distributed replicated" volumes, no<br>
> internal redundancy<br>
<br>
This would increase Gluster performance via multiple bricks; however a <br>
single failed disk will put the entire note out-of-service. Moreover, <br>
Gluster heals are much slower processes than a simple RAID1/ZFS mirror <br>
recover.</blockquote><div dir="auto"><br></div><div dir="auto">can you explain better how a single disk failing would bring a whole node out of service?</div><div dir="auto"><br></div><div dir="auto">from your comments this one sounds the best, but having node outages from single disk failures doesn’t sound acceptable..</div><div dir="auto"><br></div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
> 3. 1 brick per host, Gluster "distributed replicated" volumes, no<br>
> internal redundancy<br>
<br>
Again, a suggest against it: a single failed disk will put the entire <br>
note out-of-service *and* will cause massive heal as all data need to be <br>
copied from the surviving node, which is a long and stressful event for <br>
the other node (and for the sysadmin).<br>
<br>
In short, I would not use Gluster without *both* internal and <br>
brick-level redundancy. For a simple setup, I suggest option #1 but in <br>
replica setup (rather than distributed). You can increase the number of <br>
briks (mountpoint) via multiple zfs datasets, if needed.</blockquote><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><br>
<br>
Regards.<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><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></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Miguel Mascarenhas Filipe</div>