<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.6.6">
</HEAD>
<BODY>
Hi,<BR>
<BR>
Currently we have some small server clusters that have only two storage nodes with iSCSI. I would like to use Gluster bricks for them but I'm a bit worried about quorum and split-brain.<BR>
<BR>
Would it be an idea to make ovirt a Gluster quorum arbiter? The ovirt engine is managing the virtual datacenter and could easily be the deciding factor when a 2 brick gluster loses one of the bricks.<BR>
<BR>
<A HREF="http://hekafs.org/index.php/2012/11/different-forms-of-quorum/">http://hekafs.org/index.php/2012/11/different-forms-of-quorum/</A><BR>
<BR>
<I>The second issue is trickier. What </I><I><B>should</B></I><I> we do when N=2? In some cases, allowing a single failure to make a volume read-only (the current behavior) is fine. In others it’s not. One idea would be to “promote” from all bricks/servers in a replica set to all in a volume to all in the cluster. Unfortunately, that gets us nowhere in a two-server two-brick cluster, which is very common especially in the critical case of people trying GlusterFS for the first time and seeing how it responds to failures. The other idea is arbiter nodes, which hold no data but pump up the quorum number for the cluster (or for a volume if that’s how we’re counting). Thus, if we have a volume on two nodes in a cluster with more than two, a third node will be (automatically?) designated as having an interest in that volume so that the effective quorum is two out of three. Since tracking servers’ interests in volumes will already have to be part of the second patch I’ve mentioned, adding an arbiter is just a simple matter of manipulating that information so it should be a pretty straightforward third patch.</I><BR>
<BR>
Kind regards,<BR>
<BR>
Jorick Astrego<BR>
Netbulae
</BODY>
</HTML>