Some thoughts on enhancing High Availability in oVirt

[Ayal Baron]

----- Original Message -----
> > I think we first need to look at the larger question of policy
> > engine at
> > ovirt-engine. the two main candidates are pacemaker and drools
> > (jboss
> > rules).
> > pacemaker for having logic in the area.
> > drools for having easier java integration and integrated UI to
> > create
> > policies by users.
> 
> Agreed, as I mentioned in my email they're interrelated

I'm not sure I agree.
This entire thread assumes that the way to do this is to have the engine continuously monitor all services on all (HA) guests and according to varying policies reschedule VMs (services within VMs?)
I don't think this is scalable (and wrt drools/pacemaker, assuming what Andrew says is correct, drools doesn't even remotely come close to supporting even relatively small scales)

Engine should decide on policy, the hosts should enforce it.
What this would translate to is a more distributed way of monitoring and moving around of VMs/services.  E.g. for each service, engine would run the VM on host A and let host B know that it is the failover node for this service.  Node B would be monitoring the heartbeats for the services it is in charge of and take over when needed. In case host B crashes, engine would choose a different host to be the failover node (note that there can be more than 2 nodes with a predefined order of priority).

> 
> i.e. if you're going to use Pacemaker's policy engine then it
> absolutely
> makes sense to just go with Pacemaker Cloud, since that's precisely
> what
> it does (uses the core Pacemaker PE)
> 
> OTOH, if you decide to use drools, then it may make more sense to
> integrate the HA concepts directly into the drools PE and then the
> only
> other thing you can leverage would be the library that does the
> monitoring of services at the end points.
> _______________________________________________
> Arch mailing list
> Arch at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>