<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>That really isnt an arbiter issue or for that matter a Gluster
issue. We have seen that with vanilla NAS servers that had some
issue or another.</p>
<p>Arbiter simply makes it less likely to be an issue than replica 2
but in turn arbiter is less 'safe' than replica 3.</p>
<p>However, in regards to Gluster and RO behaviour<br>
</p>
<p>The default timeout for most OS versions is 30 seconds and the
Gluster timeout is 42, so yes you can trigger an RO event.<br>
</p>
<p>
# cat /sys/block/sda/device/timeout<br>
30<br>
</p>
Though it is easy enough to raise as Pavel mentioned<br>
<br>
# echo 90 > /sys/block/sda/device/timeout<br>
<br>
As a purely observational note, we have noticed that EXT3/4
filesystems on VMs will go read-only much easier than XFS systems
(even with the default timeout and irregardless of storage type). We
have always wondered about that, though part of that observation is
biased because we tend to use XFS on newer VMs which mean newer,
better kernels.<br>
<br>
Likewise virtio "disks" don't even have a timeout value that I am
aware of and I don't recall them being extremely sensitive to disk
issues on either Gluster, NFS or DAS. <br>
<br>
All our newer VMs use virtio instead of sata/ide emulation AND XFS
so we rarely see a RO situation and if we do, it was a good thing
the VMs did go RO to protect themselves while the storage system
freaked out.<br>
<br>
<br>
<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 8/23/2017 12:26 PM,
<a class="moz-txt-link-abbreviated" href="mailto:lemonnierk@ulrar.net">lemonnierk@ulrar.net</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20170823192645.GI17785@ciara.ulrar.net">
<pre wrap="">Really ? I can't see why. But I've never used arbiter so you probably
know more about this than I do.
In any case, with replica 3, never had a problem.
On Wed, Aug 23, 2017 at 09:13:28PM +0200, Pavel Szalbot wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi, I believe it is not that simple. Even replica 2 + arbiter volume
with default network.ping-timeout will cause the underlying VM to
remount filesystem as read-only (device error will occur) unless you
tune mount options in VM's fstab.
-ps
On Wed, Aug 23, 2017 at 6:59 PM, <a class="moz-txt-link-rfc2396E" href="mailto:lemonnierk@ulrar.net"><lemonnierk@ulrar.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">What he is saying is that, on a two node volume, upgrading a node will
cause the volume to go down. That's nothing weird, you really should use
3 nodes.
On Wed, Aug 23, 2017 at 06:51:55PM +0200, Gionatan Danti wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Il 23-08-2017 18:14 Pavel Szalbot ha scritto:
</pre>
<blockquote type="cite">
<pre wrap="">Hi, after many VM crashes during upgrades of Gluster, losing network
connectivity on one node etc. I would advise running replica 2 with
arbiter.
</pre>
</blockquote>
<pre wrap="">
Hi Pavel, this is bad news :(
So, in your case at least, Gluster was not stable? Something as simple
as an update would let it crash?
</pre>
<blockquote type="cite">
<pre wrap="">I once even managed to break this setup (with arbiter) due to network
partitioning - one data node never healed and I had to restore from
backups (it was easier and kind of non-production). Be extremely
careful and plan for failure.
</pre>
</blockquote>
<pre wrap="">
I would use VM locking via sanlock or virtlock, so a split brain should
not cause simultaneous changes on both replicas. I am more concerned
about volume heal time: what will happen if the standby node
crashes/reboots? Will *all* data be re-synced from the master, or only
changed bit will be re-synced? As stated above, I would like to avoid
using sharding...
Thanks.
--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - <a class="moz-txt-link-abbreviated" href="http://www.assyoma.it">www.assyoma.it</a>
email: <a class="moz-txt-link-abbreviated" href="mailto:g.danti@assyoma.it">g.danti@assyoma.it</a> - <a class="moz-txt-link-abbreviated" href="mailto:info@assyoma.it">info@assyoma.it</a>
GPG public key ID: FF5F32A8
_______________________________________________
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-users">http://lists.gluster.org/mailman/listinfo/gluster-users</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-users">http://lists.gluster.org/mailman/listinfo/gluster-users</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Gluster-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a>
<a class="moz-txt-link-freetext" href="http://lists.gluster.org/mailman/listinfo/gluster-users">http://lists.gluster.org/mailman/listinfo/gluster-users</a></pre>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>