Hi Ilo, haproxy, pound, pen or any other reverse proxy softwares do terminate the incoming connection at the loadbalancer and theoretically could enable that kind of switching at TCP level (by re-creating a new connection from LB to a different realserver).
However, they don't help in your exact inquiry, as they don't implement the requested feature. As elaborated, it's very hard work to get the application of a different real server into the state where this application would be able to continue a connection, which originally has been created with another real server. It also can impose a very severe risk on failure handling, so basically everyone relies on the user hitting the "reload" button, accepting any consequences (e.g. ordering twice). Anders On 23.06.2014, Ilo Lorusso wrote: > > Hi Anders, > > Thank you for your detailed explanation, > > With regards to your statement regarding alternate load balancers , can I ask > the names of these other load balancers ? sounds like they could help. > > > There are different kinds of load balancers available, who do work > > differently than IPVS and in theory may support a scenario like this: > > > -----Original Message----- > From: lvs-users-boun...@linuxvirtualserver.org > [mailto:lvs-users-boun...@linuxvirtualserver.org] On Behalf Of Anders Henke > Sent: Monday, June 23, 2014 12:31 PM > To: lvs-users@linuxvirtualserver.org > Subject: Re: [lvs-users] ldirectord question > > On 19.06.2014, Ilo Lorusso wrote: > > I have a general question of how ldirectord works, I have setup my > > virtual service and real servers > > > > I have an active connection and traffic is flowing through to the real > > server perfectly as shown below > > > > I want to know is it possible to move an established connection between the > > real servers without resetting or reestablishing the TCP connection ? > > > > [root@lbmaster ~]# ipvsadm -Ln > > IP Virtual Server version 1.2.1 (size=32768) Prot LocalAddress:Port > > Scheduler Flags > > -> RemoteAddress:Port Forward Weight ActiveConn InActConn > > TCP 172.16.162.190:40054 wlc persistent 300 > > -> 172.16.162.199:40054 Masq 100 1 0 > > -> 172.16.162.200:40054 Masq 99 0 0 > > Short answer: no way. > > Long answer: it's much more complicated than you think. > > ldirectord does "only" configure IPVS, so you're looking for the way IPVS and > TCP do work, ldirectord isn't much of an issue for you. > And once you've mastered IPVS and TCP, your application will most likely be > in the way. > > You're using IPVS in masquerading/NAT mode. In this mode, your balancer > receives an IP packet for the VIP address, replaces the VIP by the real > server's IP and sends the packet back onto your local network. Your real > server routes any replies back via your loadbalancer, who in turn does > "reverse" the NAT operation by replaceing your realserver's IP address by the > VIP address. > > So in the end, any phase of the tcp connection establishing (3way handshake, > maximum segment size, exchange of sequence and acknowledgement numbers, ...) > is performed between your real server and the connecting client: only they > are aware of the mutually exchanged information and agreed conditions. > Especially it's only them who are aware of the current sequence number and > acknowledgement numbers. Technically, the loadbalancer is aware of those > numbers as well - but the loadbalancer doesn't know how to inform another > realserver to expect a connection with a given host and configuration. > > If you're trying to move that running connection to a different real server, > this other server would require to expect a connection with those sequence > numbers. > > If the balancer is just forwarding the established tcp connection to a > different realserver (no matter, if you're doing this in > masquerading/gatewaying or tunneling), the real server wouldn't be aware of > it: it doesn't expect this connection, doesn't know which application is > expected to know about it, even if expected it doesn't know the current tcp > sequence number or expected acknowledgement numbers. If your tcp connection > does transport an SSL session, you'd also need many other information to be > available at the "other" real server - most of which is written to prevent > any tampering or replay attacks. Your application may also need to be aware > of some information from the same tcp session (e.g. a > http-basic-authentication header being sent earlier) or may need to be aware > of some local state. > > So in the end: it doesn't work that way, and it's certainly not the > balancer's fault. TCP is not written around the idea of what you're probably > trying to achieve. > > > > If the connection from loadbalancer to realserver breaks down, the "client" > happens to be the loadbalancer and may chose to re-connect with a different > realserver. The connection with the actual client (connecting to the > balancer) doesn't necessarily need to be aware of this. > > In order to continue where the broken real server did quit, the loadbalancer > may need to replay any payload traffic from the broken tcp connection, so the > connected application on the realserver can be brought into the same state > and may continue processing as usual. For example, a tcp session with a SQL > server may require re-login, a series of BEGIN, SELECT, UPDATE, SELECT, ..." > to get into the same state where the original connection broke down. > > This in turn brings up a series of new questions: if the SQL server uses > Challenge-Response-based authentication (e.g. MySQL does), a simple replay > won't work for logging in the load balancer. Your loadbalancer would need to > be aware of the exact password and need to know how to log onto your database. > > If every issued command is an transaction on its own (e.g. HTTP POST), > replaying those transactions will risk the loadbalancer to be ordering the > same product twice on behalf of the customer: one time "really" by the > customer, but on the real server who just broke down when trying to display > the "order successful" page. And another time for replaying application data > to successfully re-display the "order successful" page. > > So in order to support the kind of scenario your're expecting, your > loadbalancer needs to be aware of the exact application, and may need to > decide to take different paths. Which in the end maks this kind of > loadbalancer a very specific and complex thing, built exactly around your > application and trying to mimic your clients. > > > > Anders > -- > 1&1 Internet AG Expert Systems Architect (IT Operations) > Brauerstrasse 50 v://49.721.91374.0 > D-76135 Karlsruhe f://49.721.91374.225 > > Amtsgericht Montabaur HRB 6484 > Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas > Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, Christian > Würst > Aufsichtsratsvorsitzender: Michael Scheeren > > _______________________________________________ > Please read the documentation before posting - it's available at: > http://www.linuxvirtualserver.org/ > > LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org Send > requests to lvs-users-requ...@linuxvirtualserver.org > or go to http://lists.graemef.net/mailman/listinfo/lvs-users > > BankservAfrica is a BBBEE level 4 procurement contributor > > This e-mail and its attachments, if any, are subject to BankservAfrica's > e-mail disclaimer which is available on > http://www.bankservafrica.com/Contactus/EmailDisclaimer.aspx > > Please consider the environment before printing this e-mail! > _______________________________________________ > Please read the documentation before posting - it's available at: > http://www.linuxvirtualserver.org/ > > LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org > Send requests to lvs-users-requ...@linuxvirtualserver.org > or go to http://lists.graemef.net/mailman/listinfo/lvs-users -- 1&1 Internet AG Expert Systems Architect (IT Operations) Brauerstrasse 50 v://49.721.91374.0 D-76135 Karlsruhe f://49.721.91374.225 Amtsgericht Montabaur HRB 6484 Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, Christian Würst Aufsichtsratsvorsitzender: Michael Scheeren _______________________________________________ Please read the documentation before posting - it's available at: http://www.linuxvirtualserver.org/ LinuxVirtualServer.org mailing list - lvs-users@LinuxVirtualServer.org Send requests to lvs-users-requ...@linuxvirtualserver.org or go to http://lists.graemef.net/mailman/listinfo/lvs-users
