On Dec 12, 2014, at 7:19 AM, Itamar Heim <iheim(a)redhat.com>
wrote:
On 12/10/2014 05:47 PM, Jason Greene wrote:
> Thanks for the suggestions.
>
> Following Maor’s suggestion I was able to add a local domain, but that required
maintenance mode, so I had to failure the engine over to another host to make the change
to the current host.
>
> I like the appliance solution a little better, although I think it’s best if I were
to run it under its own private KVM process unmanaged by ovirt, so that its possible to
edit and cycle the host. Unfortunately it’s still a bit cumbersome as you need to have an
engine appliance per system or shuffle around the image with some sort of disaster
recovery plan.
>
> I also looked into using gluster or cephfs as a way to share state, but noticed the
BZs about the lack of complete atomicity leading to duplicate engines.
>
> This is probably not the right place for dev musings, but IMO it would be great if in
a future release there could be a solution that doesn’t require shared storage, which for
smaller use-cases is often too pricey of a requirement. Ideally, under such a “horizontal”
setup, each host could govern its own management data, and the engine could act more as an
authoritative aggregator, thereby reducing the need for ha (if it fails just reinstall a
clean one and let it reimport everything). It seems like most of the pieces are already
there, with the per host-vdsm instance already containing much of the data. I’m guessing
the missing element is having the engine support pulling that information as opposed to
just pushing it. This is sort of like a capability that an unnamed proprietary competitor
has, so it might have some sort of appeal. Of course such setups do have limitations, like
you still need shared storage for live migrations and so on. So I certainly understand
> the rational behind the existing design. Anyway it’s just some food for thought.
>
before we go so far out... gluster should work with 3 hosts, we are working on improving
the flow for this for 3.6. today it requires quite a few manual steps to do so.
I was looked into that, but I got scared away by:
https://bugzilla.redhat.com/show_bug.cgi?id=1097639
The option I was thinking of trying was drdb to mirror the ovirt appliance copied to a
block store, and then using something like pacemaker to control failover. This would
ensure that the engine always follows its data.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat