[Pacemaker] First confused (then enlightened ? :)

[Dan Frincu]

On Wed, Feb 16, 2011 at 9:32 AM, Dan Frincu <df.cluster at gmail.com> wrote:

> 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
>
>
And not to forget

http://www.linux-ha.org/doc/users-guide/users-guide.html - The Linux-HA
User’s Guide
and
http://www.linux-ha.org/doc/man-pages/man-pages.html - Linux-HA Manual Pages


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


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