[Pacemaker] Migrating VMs that depend on other VMs

[Lindsay Todd]

The "whitebox container implementation", is that the ability to manage
resources inside the VMs from the same ha-cluster that is managing the VM
instances, i.e., the pacemaker-remote agent?  I've not tried that; so far
I've stuck to the stock SL6.4 RPMs...  But that could help help some --
dependencies would be on services, not VMs, and location preferences tie
services to VMs.  But in some cases, like my db0 instance, I'll not have
another VM to take over the service.  Presumably restarting services on
already-running VMs would be faster, though.

Are people successfully using pacemaker-remote in production?
 Documentation seems a bit sparse (though I think enough to set it up)...

/Lindsay



On Mon, May 13, 2013 at 3:19 PM, Vladislav Bogdanov <bubble at hoster-ok.com>wrote:

> 13.05.2013 19:28, Lindsay Todd wrote:
> > Folks: On my cluster built on SL6.4, I need to deploy some VMs that
> > depend on other VMs:
> >
> >   * db0 has no dependendencies
> >   * ldap01,ldap02 require db0 to be running -- ordering constraint, but
> >     no collocation (other than we'll use a collocation constraint to
> >     recommend ldap01, ldap02 run on different physical hosts)
> >   * bq01, bq02 depend on at least one of ldap01, ldap02 running
> >
> > At this point, I've got a test arrangement corresponding to only the
> > db01 and ldap01 resources being deployed, but it is enough to expose a
> > problem...
> >
> > The constraints themselves are quite simple.  The trouble arises when we
> > try to migrate VMs.  As the "Pacemaker Configuration Explained" manual
> > states: "The resource must not, directly or indirectly, depend on any
> > primitive or group resources."  What is the reason for this restriction?
> > Sure enough, I can't migrate ldap01.  I can migrate db01 successfully,
> > though it does force a stop/start on ldap01 (though that is really
> > unnecessary, since network connections would have been preserved).
> >
> > So is there a way to:
> >
> >   * At least get the bq01, bq02 VMs able to migrate, though they depend
> >     on other VMs?
> >   * Be able to get the ldap01,ldap02 VMs to migrate, without forcing the
> >     bq01,bq02 VMs to stop/start (unless both get stopped the restarted)?
> >   * Be able to get the db01 resource to migrate, without forcing the
> >     other dependents to stop/start, unless it is actually stop/started?
>
> It seems to be exactly what was discussed a year ago here
> (http://www.mail-archive.com/pacemaker@oss.clusterlabs.org/msg12050.html)
> and then on bugtracker (http://bugs.clusterlabs.org/show_bug.cgi?id=5055).
>
> You may look at whitebox container implementation though, that may fit
> your needs. I didn't play with it yet, so that is just a guess.
>
> Alternative way would be to play with tickets as with cluster-wide
> attributes, but they are quite limited for that task I think.
>
> Vladislav
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20130513/d8a7b336/attachment.htm>