On Thu, 21 Mar 2013 11:00:37 +0100 in <[email protected]>, Lukas Tribus Lukas Tribus <[email protected]> wrote:
>
> > It's a point in time dump and restore of the in flight packets.
>
> Can't dump the details and in flight content of a TCP session if
> the host is already dead.
You're right. Its primary goal is system update without service
interruption.
> So either this will work only for manual switchovers (but not for
> sudden hardware/software failure; also at this point TCP connection
> repair would probably be a solution) or you sync everything in realtime
> with the other proxy, but to do that, you will need a huge uplink
> between them.
You're right in the sense that the requirement for layer 4 LB
two nodes synchronization is not just synchronization of some IP
headers like in the firewalling case, so the synchronization flow
need to transport the whole packets contents.
It's tricky to implement : you need to get only the packets
from the sockets used inside HAProxy and I'm not familiar with the code
in HAProxy : are SOCKET_RAW used and are packets written to a file
descriptor ?
>
> Also, suppose you can implement this through netfilter/pfsync (I've my
> doubts about that) and by patching haproxy, how do you avoid that the
> "standby" TCP session on proxy 2 interferes with the TCP session prior
> to a switchover/failover? I guess you would need additional
> kernel hacks.
After some sleep and thoughts, the API for netfilter/pfsync will just
be an overcomplicated implementation of a packet mirroring system.
>
> In the end, you will end up spending so much cpu and memory
> for standby tcp session and the syncing, that the solution will be
> as performant as an active/standby solution and it will increase
> the complexity in your load-balancer.
Agree for the code complexity and memory usage, not agree for the CPU
usage.
If HAProxy code already make an extensive usage of raw sockets and
write packets to a fd, you just pipeline the fd to the socket
especially created for syncing purpose and let the current code handle
the fd as it's used to (but I do not know the HAProxy internals). The
network load is really a pb then to achieve that. The syncing
protocol is then a real headache to minimise race condition and/or
out-of-sync case and maintain only the non closed connexion in
memory of the backup HAProxy.
>
> > prefer an proper solution to avoid the renegotiation on
> > the client side
>
> Its a huge and complex task to do, which I didn't see anyone
> doing before. If you or your client has the resources to
> implement this, please go ahead and tell us how exactly you
> did it.
Well, I'm going to put in balance the use cases of such a feature and
the overall code complexity and of course if the HAProxy community
want such a feature given the code complexity added.
The first step will be to read the HAProxy code entirely :)
The second to deeply think about an effective packets mirroring
protocol :)
...
>
> But for a "would prefer a stateful solution to avoid a TCP RST
> + a new TCP handshake when a proxy dies" (so to speak; if iptables
> is configured accordingly), I would certainly not do it.
>
> The benefit of it simply doesn't justify the effort, imho.
You're probably right. Time to sleep.
Regards,
--
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
signature.asc
Description: PGP signature
