[Pacemaker] Migrating VMs that depend on other VMs

[David Vossel]

----- Original Message -----
> From: "Vladislav Bogdanov" <bubble at hoster-ok.com>
> To: pacemaker at oss.clusterlabs.org
> Sent: Monday, May 13, 2013 2:19:07 PM
> Subject: Re: [Pacemaker] Migrating VMs that depend on other VMs
> 
> 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.

I'm doubtful whitebox containers will help improve migration behavior at all.  I've actually held off on officially announcing the feature until I understand fully how migrations will be handled with the whitebox containers.

Migrating resources with dependencies involved is unfortunately very complex.

-- Vossel

> 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
>