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-bounces@linuxvirtualserver.org [mailto:lvs-users-bounces@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-request@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!
114061917430002602 (18.0 KB)