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
