<div class="gmail_quote">On Tue, Feb 15, 2011 at 1:02 PM, Carlos G Mendioroz <span dir="ltr"><<a href="mailto:tron@huapi.ba.ar">tron@huapi.ba.ar</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Andrew Beekhof @ 15/02/2011 04:25 -0300 dixit:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For what I understand, you want the brains of the action at pacemaker,<br>
so VRRP, HSRP or (U)CARP seem more a trouble than a solution.<br>
(i.e. twin head) right ?<br>
<br>
In other words, it seems to better align with the solution idea to<br>
have pacemaker decide and some script-set do the changing.<br>
</blockquote>
<br>
What you typically want to avoid is having two isolated entities<br>
trying to make decisions in the cluster - pulling it to pieces in the<br>
process.<br>
</blockquote></div>
Right, makes a lot of sense, only one boss in the office and one place<br>
to define policy.<br>
But to integrate with other protocols thought as independent, like VRRP<br>
or (U)CARP, the "dependency" has to be implemented.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Something like DRBD solves this by using crm_master to tell Pacemaker<br>
which instance it would like promoted, but not actually doing the<br>
promotion itself.<br>
<br>
I don't know if this is feasible for your application.<br>
<br>
</blockquote></div>
In my case, it seems better to get rid of VRRP and use a more<br>
comprehensive look of pacemaker.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Nevertheless, I don't see the concerns of MAC mutation being addressed<br>
anywhere. And I have my suspocious at ARP caches too.<br>
</blockquote>
<br>
Both would be properties of the RA itself rather than Pacemaker or Heartbeat.<br>
So if you can script MAC mutation, you can also create an RA for it<br>
(or add it to an existing one).<br>
</blockquote>
<br></div>
Is there a "guide to implemented RAs" ?<br>
I've seen that the shell can list them. Are they embedded or just<br>
showing a directory of entities found in some predefined places ?</blockquote><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://www.linux-ha.org/doc/dev-guides/ra-dev-guide.html">http://www.linux-ha.org/doc/dev-guides/ra-dev-guide.html</a> - The OCF Resource Agent Developer's Guide</div>
<div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://www.linux-ha.org/wiki/Resource_Agents">http://www.linux-ha.org/wiki/Resource_Agents</a> - Resource Agents</div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://www.linux-ha.org/wiki/OCF_Resource_Agents">http://www.linux-ha.org/wiki/OCF_Resource_Agents</a> - OCF Resource Agents</div>
<div><meta http-equiv="content-type" content="text/html; charset=utf-8"><a href="http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html#ap-ocf">http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Pacemaker_Explained/index.html#ap-ocf</a> - OCF Resource Agents</div>
<div><a href="http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/index.html#id2281146">http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html-single/Clusters_from_Scratch/index.html#id2281146</a> - Listing Resource Agents</div>
<div><br></div><div>HTH</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm currently thinking about a couple of ideas:<br>
-using mac-vlan to move an active mac from one server to another<br>
-using bonding to have something like a MEC, multichasis ether channel.<br>
(i.e. a way to not only migrate the MAC but also to signal the migration<br>
to the attachment switch using 802.1ad)<br>
<br>
Are there any statistics on how much time does it take to migrate<br>
an IP address by current resource ? (IPAddr2 I guess)<br>
I'm looking for a subsecond delay since failure detection,<br>
and I guess it's obvious, an active-standby setup.<br>
</blockquote>
<br>
I've not done any measurements lately.<br>
Mostly its dependent on how long the RA takes.<br>
</blockquote>
<br></div>
Ok, now I'm getting into RA arena I guess.<br>
For speedy failover, I would need a hot standby approach. Is that a pacemaker known state ?<br><font color="#888888">
<br>
-- <br></font><div><div></div><div class="h5">
Carlos G Mendioroz  <<a href="mailto:tron@huapi.ba.ar" target="_blank">tron@huapi.ba.ar</a>>  LW7 EQI  Argentina<br>
<br>
_______________________________________________<br>
Pacemaker mailing list: <a href="mailto:Pacemaker@oss.clusterlabs.org" target="_blank">Pacemaker@oss.clusterlabs.org</a><br>
<a href="http://oss.clusterlabs.org/mailman/listinfo/pacemaker" target="_blank">http://oss.clusterlabs.org/mailman/listinfo/pacemaker</a><br>
<br>
Project Home: <a href="http://www.clusterlabs.org" target="_blank">http://www.clusterlabs.org</a><br>
Getting started: <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
Bugs: <a href="http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker" target="_blank">http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Dan Frincu<div>CCNA, RHCE</div><br>