LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: [lvs-users] ldirectord question

To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [lvs-users] ldirectord question
From: Anders Henke <anders.henke@xxxxxxxx>
Date: Mon, 23 Jun 2014 12:31:27 +0200
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.


There are different kinds of load balancers available, who do work differently 
than IPVS and in theory may support a scenario like this:

The loadbalancer accepts the client connection, terminates it locally on the 
load balancer and creates a new connection from the load balancer to the real 
server. 

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@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users

<Prev in Thread] Current Thread [Next in Thread>