[Pacemaker] First confused (then enlightened ? :)

[Carlos G Mendioroz]

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 ?

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