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