[Pacemaker] Migrating VMs that depend on other VMs

[David Vossel]

----- Original Message -----
> From: "Lindsay Todd" <rltodd.ml1 at gmail.com>
> To: "The Pacemaker cluster resource manager" <pacemaker at oss.clusterlabs.org>
> Sent: Monday, May 13, 2013 4:35:47 PM
> Subject: Re: [Pacemaker] Migrating VMs that depend on other VMs
> 
> 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)...

I've written some walk-throughs that should help quite a bit in setting pacemaker-remote up.  I'll likely be officially announcing the feature on the mailing list soon.  It requires use of 1.1.10rc1 or greater to function correctly though.

http://clusterlabs.org/doc/en-US/Pacemaker/1.1-pcs/html-single/Pacemaker_Remote/index.html

-- Vossel

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