[Users] oVirt/RHEV fencing; a single point of failure
xrx
xrx-ovirt at xrx.me
Sat Mar 3 16:52:06 UTC 2012
Hello,
I was worried about the high availability approach taken by RHEV/oVirt.
I had read the thread titled "Some thoughts on enhancing High
Availability in oVirt" but couldn't help but feel that oVirt is missing
basic HA while it's developers are considering adding (and in my opinion
unneeded) complexity with service monitoring.
It all comes down to fencing. Picture this: 3 HP hypervisors running
RHEV/oVirt with iLO fencing. Say hypervisor A runs 10 VMs, all of which
are set to be highly available. Now suppose that hypervisor A has a
power failure or an iLO failure (I've seen it happen more than once with
a batch of HP DL380 G6s). Because RHEV would not be able to fence the
hypervisor as it's iLO is unresponsive; those 10 HA VMs that were halted
are NOT moved to other hypervisors automatically.
I suggest that oVirt concentrates on having support for multiple fencing
devices as a development priority. SCSI persistent reservation based
fencing would be an ideal secondary, if not primary, fencing device; it
would be easy to set up for users as SANs generally support it and is
proven to work well, as seen on Red Hat clusters.
I have brought up this point about fencing being a single point of
failure in RHEV with a Red Hat employee (Mark Wagner) during the RHEV
virtual event; but he said that it is not. I don't see how it isn't; one
single loose iLO cable and the VMs are stuck until there is manual
intervention.
Any thoughts?
-xrx
More information about the Users
mailing list