<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><span style="font-family:arial">On Sat, Dec 21, 2013 at 11:56 PM, Grégoire Leroy </span><span dir="ltr" style="font-family:arial"><<a href="mailto:gregoire.leroy@retenodus.net" target="_blank">gregoire.leroy@retenodus.net</a>></span><span style="font-family:arial"> wrote:</span><br>
</div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hello,<br>
<div class="im"><br>
> > If you disable quorum then you won't have the issue of "read only" when<br>
> ><br>
> >> you lose a host, but you > won't have protection from split brain (if<br>
> >> your<br>
> >> two hosts lose network connectivity). VMs will<br>
> >> keep writing to the hosts, as you have the gluster server and client on<br>
> >> the same host this is<br>
> >> inevitable.<br>
<br>
> > Ok, I get the problem caused by disabling the quorum. So, what if while<br>
> > I've two hosts the lack of HA is not so dramatic but will be necessary<br>
> > when<br>
><br>
> > I'll have more hosts ? (3 or 4). Here is the scenario I would like to have<br>
:<br>
> Quorum generally requires 3 hosts, I believe the default configuration when<br>
> you press "Optimize for virt store" will require a minimum of 2 bricks<br>
> connected before writing is allowed.<br>
<br>
</div>Ok, if I understand, the quorum thing is very specific to gluster (bricks) and<br>
not to ovirt (hosts). So, maybe what I need is just another gluster server<br>
with very few space on a dummy VM (not hosted by a ovirt host but outside of<br>
my cluster) to add as a brick. It wouldn't be use at all, just to check<br>
connectivity<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
Then, if a host lose connectivity, it can't join neither the real gluster<br>
server nor the "dummy" one and so, doesn't run VM. The other one, which is<br>
able to join the dummy one becomes the SPM (the dummy wouldn't have vdsm<br>
server, so it couldn't become) and runs VM.<br>
<br>
Maybe by this way could I have HA with two hosts, right ? Is there a reason it<br>
shouldn't work ?<span style="font-family:tahoma,sans-serif"></span></blockquote><div> </div><div class="gmail_default" style="font-family:tahoma,sans-serif">I guess this would work as quroum is based on how many peers are in the cluster. Actually quite a good idea and I'd love to hear from you on how it goes. I'd be interested to see how gluster will work with this though, I assume it has to be apart of the volume. If you're doing distribute-replicate I think this "dummy" VM will need to hold hold the full replicated data? </div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"><pre style="font-size:1em;background-color:rgb(238,238,238);border:1px dashed rgb(102,102,102);padding:15px 20px;overflow:auto;color:rgb(0,0,0)"> cluster.server-quorum-ratio - this is % > 50. If the volume is not set with any ratio the equation for quorum is:
active_peer_count > 50% of all peers in cluster. But when the percentage (P)
is specified the equation for quorum is active_peer_count >= P % of all the <span style="font-size:1em;font-family:tahoma,sans-serif">befriended peers in cluster.</span></pre></div><div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> > 1) I have two hosts : HOSTA and HOSTB. They have glusterfs bricks<br>
> > configured as Distribute Replicated and data is replicated.<br>
> > => For now, I'm totally ok with the fact that if a node fails, then VM on<br>
> > this hosts are stopped and unreachable. However, I would like that if a<br>
> > node fails, the DC keeps running so that VM on the other hosts are not<br>
> > stopped and a human intervention make possible to start the VM on the<br>
> > other<br>
> > host. Would it be possible without disabling the quorum ?<br>
><br>
> For the 2 host scenario, disable quorum will allow you to do this.<br>
<br>
</div>Unfortunately, not for all cases. If the network interface used by glusterfs<br>
to reach each other falls, I get the following behaviour :<br>
<br>
1) HOSTB, on which the VM run, detect that HOSTA's brick is unreachable. So it<br>
keeps running. Fine.<br>
2) HOSTA detects that HOSTB's brick is unreachable. So it starts to run the VM<br>
=> Split brain. If the network interfaces not used for management of the<br>
cluster but for VM are OK, I'm going to have a split network.<br>
3) Conclusion, the fall of HOSTA has impact on the VM of HOSTB<br>
<br>
Does this scenario seem correct to you, or have I miss something ? Maybe power<br>
management could avoid this issue.<br></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif">Yes you'll need the power management which they call "fencing", so it will ensure that the host which has dropped from the cluster is sent for a reboot thus making any VMs running on it be shut off immediately and ready to be brought up on another ovirt host.</div>
<div class="gmail_default" style="font-family:tahoma,sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> > 2) In few months, I'll add two other hosts to the glusterfs volum. Their<br>
> > bricks will be replicated.<br>
> > => At that time, I would like to be able to make evolve my architecture<br>
> > (without shut my VM and export/import them on a new cluster) so that if a<br>
> > node fails, VM on this host start to run on the other host of the same<br>
> > brick (without manual intervention).<br>
><br>
> Later on you just enable quorum, it's only a setting in the gluster volume.<br>
> gluster volume set DATA cluster.quorum-type auto<br>
<br>
</div>Thanks you,<br>
Regards,<br>
Grégoire Leroy<br><br></blockquote></div><br></div></div>