<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#0050d0">
Sent: Wed Jan 12 2011 09:25:39 GMT-0700 (Mountain Standard Time)<br>
From: Patrick H. <a class="moz-txt-link-rfc2396E" href="mailto:pacemaker@feystorm.net"><pacemaker@feystorm.net></a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:pacemaker@oss.clusterlabs.org">pacemaker@oss.clusterlabs.org</a> <br>
Subject: Re: [Pacemaker] Speed up resource failover?
<blockquote cite="mid:4D2DD603.8070105@feystorm.net" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
Sent: Wed Jan 12 2011 01:56:31 GMT-0700 (Mountain Standard Time)<br>
From: Lars Ellenberg <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E" href="mailto:lars.ellenberg@linbit.com"><lars.ellenberg@linbit.com></a><br>
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:pacemaker@oss.clusterlabs.org">pacemaker@oss.clusterlabs.org</a>
<br>
Subject: Re: [Pacemaker] Speed up resource failover?
<blockquote cite="mid:20110112085631.GA25975@barkeeper1-xen.linbit"
type="cite">
<pre wrap="">On Wed, Jan 12, 2011 at 09:30:41AM +0100, Robert van Leeuwen wrote:
</pre>
<blockquote type="cite">
<pre wrap="">-----Original message-----
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:pacemaker@oss.clusterlabs.org">pacemaker@oss.clusterlabs.org</a>;
From: Patrick H. <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"
href="mailto:pacemaker@feystorm.net"><pacemaker@feystorm.net></a>
Sent: Wed 12-01-2011 00:06
Subject: [Pacemaker] Speed up resource failover?
Attachment: inline.txt
</pre>
<blockquote type="cite">
<pre wrap="">As it is right now, pacemaker seems to take a long time (in computer terms) to
fail over resources from one node to the other. Right now, I have 477 IPaddr2
resources evenly distributed among 2 nodes. When I put one node in standby, it
takes approximately 5 minutes to move the half of those from one node to the
other. And before you ask, theyre because of SSL http virtual hosting. I have
no order rules, colocations or anything on those resources, so it should be
able migrate the entire list simultaneously, but it seems to do them
sequentially. Is there any way to make it migrate the resources in parallel? Or
at the very least speed it up?
</pre>
</blockquote>
<pre wrap="">Patrick,
It's probably not so much the cluster suite but is has to do with the specific resource script.
For a proper takeover of a IP you have to do an arp "deregister/register".
This will take a few seconds.
</pre>
</blockquote>
</blockquote>
This is apparently not true :-/<br>
I have attached a portion of the lrmd log showing an example of this.
Notice that the very first line it starts the vip_55.63 resource, and
then immediately on the next line it exits successfully.<br>
Another point of note is that somehow after the script already exited,
lrmd logs the stderr output from it. I'm not sure if its just delayed
logging or what. However, even if the script is still running, notice
that there is a huge time gap between 16:11:01 and 16:11:25 where its
just sitting there doing nothing.<br>
I even did a series of `ps` commands to watch for the processes, and it
starts up a bunch of them, and then they all exit, and it sits there
for a long period before starting up more. So it is definitely not the
resource script slowing it down.<br>
<br>
Also, in the log, notice that its only starting up a few scripts every
second. It should be able to fire off every single script at the exact
same time.<br>
<br>
<blockquote cite="mid:20110112085631.GA25975@barkeeper1-xen.linbit"
type="cite">
<blockquote type="cite">
<pre wrap="">As long as a resource script is busy the cluster suite will not start the next action.
Parallel execution is not possible in the cluster suite as far as I know.
(without being a programmer myself I would expect it is pretty tricky to implement parallelization "code-wise" and making 100% sure the cluster does not break)
You could consider to edit the IPaddr2 resource script so it does not wait for the arp commands.
At you're own risk of course ;-)
</pre>
</blockquote>
<pre wrap=""><!---->
There is the cluster option "batch-limit" (in the cib), see
"configuration explained".
and there is lrmd "max-children" (can be set in some /etc/defaults/ or
/etc/sysconfig file, should be set by the init script).
you can set it manually with lrmadmin -p max-children $some_number
That should help you a bit.
But don't overdo. Raise them slowly ;-)
</pre>
</blockquote>
<br>
batch-limit it says defaults to 30 which seems like a sane value. I
tried playing with the max-children and upped it to 30 as well, but to
no effect. It does seem to be launching 30 instances of the IPaddr2
script at a time (as can be seen from the attached log), but the
problem is apparently that its sitting there for long periods of time
before starting up the next batch. I would think that when one of the
30 completes, it would launch another to take its place. But instead it
launches 30, then sits there for a while, then launches another 30.<br>
</blockquote>
Oh, and its not waiting for the resource to stop on the other node
before it starts it up either.<br>
Here's the lrmd log for resource vip_55.63 from the 'ha02' node (the
node I put into standby)<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Jan 12 16:10:24 ha02 lrmd: [5180]: info:
rsc:vip_55.63:1444: stop<br>
Jan 12 16:10:24 ha02 lrmd: [5180]: info: Managed vip_55.63:stop process
19063 exited with return code 0.</td>
</tr>
</tbody>
</table>
<br>
And here's the lrmd log for the same resource on 'ha01'<br>
<table border="1" cellpadding="2" cellspacing="2" width="100%">
<tbody>
<tr>
<td valign="top">Jan 12 16:10:50 ha01 lrmd: [4707]: info:
rsc:vip_55.63:1390: start<br>
Jan 12 16:10:50 ha01 lrmd: [4707]: info: Managed vip_55.63:start
process 8826 exited with return code 0.<br>
</td>
</tr>
</tbody>
</table>
<br>
Notice that it stopped it a full 36 seconds before it tried to start it
on the other node. The times on both boxes are in sync, so its not that
either.<br>
</body>
</html>