On Wed, Mar 04, 2009 at 12:12:21AM +0100, Alexander Staubo wrote: > On Tue, Mar 3, 2009 at 11:44 PM, Martin Karbon <martin.kar...@asbz.it> wrote: > > just wanted to know if anyone knows an opensource solution for a so called > > transparent failover: what I mean with that is, I installed two machines > > with haproxy on it which comunicate with each other via heartbeat. If one > > fails the other one goes from passive to active but all sessions are lost > > and users have to reconnect. > > We use Heartbeat (http://www.keepalived.org/) for this. Heartbeat lets > us set up virtual service IPs which are reassigned to another box if > the box goes down. Works like a charm. Current connections are lost, > but new ones go to the new IP. > > Note that there are two current versions of Heartbeat. There's the old > 1.x series, which is simple and stable, but which has certain > limitations such as only supporting two nodes, if I remember > correctly. Then there's 2.x, which is much more complex and less > stable. > > We run 2.0.7 today, and we have had some situations where the > Heartbeat processes have run wild. It's been running quietly for over > a year now, so recent patches may have fixed the issues. I would still > recommend sticking with 1.x if at all possible.
I still don't understand why people stick to heartbeat for things as simple as moving an IP address. Heartbeat is more of a clustering solution, with abilities to perform complex tasks. When it comes to just move an IP address between two machines an do nothing else, the VRRP protocol is really better. It's what is implemented in keepalived. Simple, efficient and very reliable. I've been told that ucarp was good at that too, though I've never tried it yet. > While there are solutions out there that preserve connections on > failover, my gut feeling is that they introduce a level of complexity > and computational overhead that is necessarily puts a restraint on > performance. In fact it's useless to synchronise TCP sessions between load-balancers for fast-moving connections (eg: HTTP traffic). Some people require that for long sessions (terminal server, ...) but this cannot be achieved in a standard OS, you need to synchronise every minor progress of the TCP stack with the peer. And that also prevents true randomness from being used at TCP and IP levels. It also causes trouble when some packets are lost between the peers, because they can quickly get out of sync. In practise, in order to synchronise TCP between two hosts, you need more bandwidth than that of the traffic you want to forward. There are intermediate solutions which synchronise at layer 4 only, without taking into account the data nor the sequence numbers. Those present the advantage of being able to take over a connection without too much overhead, but no layer 7 processing can be done there, and those cannot be system sockets. That's typically what you find in some firewalls or layer4 load balancers which just forward packets between two sides and maintain a vague context. Regards, Willy
