|
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-bounces@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:lvs-users-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Anders Henke
> Sent: Monday, June 23, 2014 12:31 PM
> To: lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxx Send
> requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxx
Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
or go to http://lists.graemef.net/mailman/listinfo/lvs-users
|
