[ovirt-users] sanlock + gluster recovery -- RFE
giuseppe.ragusa at hotmail.com
Wed May 21 15:15:30 UTC 2014
> ----- Original Message -----
> > From: "Ted Miller" <tmiller at hcjb.org>
> > To: "users" <users at ovirt.org>
> > Sent: Tuesday, May 20, 2014 11:31:42 PM
> > Subject: [ovirt-users] sanlock + gluster recovery -- RFE
> > As you are aware, there is an ongoing split-brain problem with running
> > sanlock on replicated gluster storage. Personally, I believe that this is
> > the 5th time that I have been bitten by this sanlock+gluster problem.
> > I believe that the following are true (if not, my entire request is probably
> > off base).
> > * ovirt uses sanlock in such a way that when the sanlock storage is on a
> > replicated gluster file system, very small storage disruptions can
> > result in a gluster split-brain on the sanlock space
> Although this is possible (at the moment) we are working hard to avoid it.
> The hardest part here is to ensure that the gluster volume is properly
> The suggested configuration for a volume to be used with ovirt is:
> Volume Name: (...)
> Type: Replicate
> Volume ID: (...)
> Status: Started
> Number of Bricks: 1 x 3 = 3
> Transport-type: tcp
> (...three bricks...)
> Options Reconfigured:
> network.ping-timeout: 10
> cluster.quorum-type: auto
> The two options ping-timeout and quorum-type are really important.
> You would also need a build where this bug is fixed in order to avoid any
> chance of a split-brain:
It seems that the aforementioned bug is peculiar to 3-bricks setups.
I understand that a 3-bricks setup can allow proper quorum formation without resorting to "first-configured-brick-has-more-weight" convention used with only 2 bricks and quorum "auto" (which makes one node "special", so not properly any-single-fault tolerant).
But, since we are on ovirt-users, is there a similar suggested configuration for a 2-hosts setup oVirt+GlusterFS with oVirt-side power management properly configured and tested-working?
I mean a configuration where "any" host can go south and oVirt (through the other one) fences it (forcibly powering it off with confirmation from IPMI or similar) then restarts HA-marked vms that were running there, all the while keeping the underlying GlusterFS-based storage domains responsive and readable/writeable (maybe apart from a lapse between detected other-node unresposiveness and confirmed fencing)?
Furthermore: is such a suggested configuration possible in a self-hosted-engine scenario?
> > How did I get into this mess?
> > ...
> > What I would like to see in ovirt to help me (and others like me). Alternates
> > listed in order from most desirable (automatic) to least desirable (set of
> > commands to type, with lots of variables to figure out).
> The real solution is to avoid the split-brain altogether. At the moment it
> seems that using the suggested configurations and the bug fix we shouldn't
> hit a split-brain.
> > 1. automagic recovery
> > 2. recovery subcommand
> > 3. script
> > 4. commands
> I think that the commands to resolve a split-brain should be documented.
> I just started a page here:
> Could you add your documentation there? Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users