[Pacemaker] First confused (then enlightened ? :)

[Andrew Beekhof]

On Mon, Feb 14, 2011 at 4:06 PM, Carlos G Mendioroz <tron at huapi.ba.ar> wrote:
> Thank you for all your comments.
>
> Andrew Beekhof @ 14/02/2011 05:44 -0300 dixit:
>>
>> On Sun, Feb 13, 2011 at 12:56 PM, Carlos G Mendioroz <tron at huapi.ba.ar>
>> wrote:
>>>
>>> Hi,
>>> I'm trying to understand how to best implement a HA EE service.
>>> Searching for linux + HA induced me to go linux-HA way (heartbeat?)
>>> and that showed the path to pacemaker, and that open the way to corosync
>>> and OpenAIS. No news for you I guess.
>>>
>>> Is there a searchable repository of the list content so I may find
>>> if some of my doubts are already explained ?
>
> Answering myself, I found that this (and some related lists) are archived
> and indexed at GossamerThreads,
>        http://www.gossamer-threads.com/lists/linuxha
> I usually find that indexing a list like this is an invaluable tool, so
> here for the record.
>
>>>
>>> I have otherwise some specific questions:
>>>
>>> -Is still the case that Heartbeat is not to be considered for new
>>> deployments ? (I read something along that line)
>>
>> pretty much
>
> Ok, assuming there is no bias here. Noted.
>
>>
>>
>> http://www.clusterlabs.org/wiki/FAQ#Should_I_Run_Pacemaker_on_Heartbeat_or_Coroysnc.3F
>>
>>> -All IBM docs (RedBooks) point to Heartbeat. Is that because they are old
>>> ?
>>
>> yes
>>
>>> -I'm looking to implement Active + hot standby, and given my present
>>> state of understanding, I was targetting something like VRRP + cluster
>>> aware service. As I have a networking background, implementing VRRP
>>> sounds sweet, but not migrating the MAC is kind of bitter.
>>>
>>> Is it ok to discuss such details here ?
>>
>> sure
>>
>> also have a look at clusters from scratch:
>>   http://www.clusterlabs.org/doc
>>
> I will be reading this, and will be back for sure.
> 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.
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.

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

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

>
> Thanks again,
> -Carlos
>
>
>
> --
> 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
>