Subject: Re: [vserver] Heartbeat IP Failover
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Fri, 26 Nov 2010 19:16:25 +0100

On Fri, Nov 26, 2010 at 01:40:26PM +0000, Gordan Bobic wrote:
> Adrian Reyer wrote:
> >On Fri, Nov 26, 2010 at 10:28:07AM +0000, Gordan Bobic wrote:
> >>Indeed, I'm aware of all that. The thing I was enquiring about is
> >>the part that integrates with heartbeat. Heartbeat will happily
> >>migrate the IPs from one host to the other, but it won't do the
> >>naddress --add --nid <guestname> --ip <guestip>
> >>part. I was just wondering if there was a pre-cooked resource
> >>management script for heartbeat that handles this already.

> >I am not aware of such a script.
> >Having Heartbeat do the IP-Migration is a good way, as it takes care
> >about ARP-broadcasting. Don't forget to add 'nodev' to the
> >VServer-configuration of that IP.

> I see. So if I touch the nodev file in the interface config, the 
> guest will bind itself to that IP even though it doesn't exist 
> in the host? 

'nodev' just means that util-vserver does not add/remove
that IP on guest start/stop ...

> So when heartbeat fails the IP over to that host, the guest's 
> IP will start to work without any further intervention required?

IP can be added/removed to/from a guest (to some extend)
and IP_ADDR_ANY bindings (0.0.0.0) will always map to
the available IPs in the assigned subset, so yes, the
guest apps binding to * will magically start working one
the IP is configured on the host

best,
Herbert

> >My Heartbeat-Setups migrate the VServer alongside the IP, so I never
> >need to add the IP afterwards. What do the vservers actually do? Just
> >e.g. 10 IPs that some http-requests get distributet amongst without
> >a special meaning of the IP itself? You might save yourself most
> >of the hassle by just adding some DNAT iptables-rule to the host,
> >INPUT-chain. It should not match packets as long as the IP is not
> >actually present on the interface and you state the rule for incoming
> >interface eth0 only.

> I can't really do that in my use-case. I need both the primary and 
> secondary guest to be online at the same time so that the data between 
> them can be replicating. In case of fail-over, I need the secondary to 
> be as up to date as possible. That means I cannot fail over the whole 
> guest. I could use DRBD to make sure the guest FS is mirrored, but 
> that's a bit overkill for what I need, and a slightly less synchronous 
> solution provides better performance.

> The IPs have different "meanings" and they run different websites and 
> other services.

> It looks like the nodev flag is actually exactly what I want. Thanks
> for pointing it out. :)

> Gordan