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