[Pacemaker] First confused (then enlightened ? :)

Dan Frincu df.cluster at gmail.com
Wed Feb 16 07:32:40 UTC 2011


On Tue, Feb 15, 2011 at 1:02 PM, Carlos G Mendioroz <tron at 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  <tron at huapi.ba.ar>  LW7 EQI  Argentina
>
> _______________________________________________
> 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://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>



-- 
Dan Frincu
CCNA, RHCE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110216/c680ebf1/attachment-0002.htm>


More information about the Pacemaker mailing list