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