LVS
lvs-users
Google
 
Web LinuxVirtualServer.org

Re: SV: SV: SV: Introduction and LVS/DR 2.4 realserver questions

To: Johan Isacsson <johan@xxxxxxxx>
Subject: Re: SV: SV: SV: Introduction and LVS/DR 2.4 realserver questions
Cc: Lvs-Users <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
From: Michael E Brown <michael_e_brown@xxxxxxxx>
Date: Thu, 1 Mar 2001 09:24:59 -0600 (CST)
On Thu, 1 Mar 2001, Johan Isacsson wrote:

> Hey Michael,
>
> > You are using 4mbit of throughput not only on the secondary site, you are
> > using 8mbit on your primary site. Waste of bandwidth. (4mbit coming into
> > the primary site, being redirected back out to secondary site.) Also, your
> > latency will be quite high with all of those hops.
>
> ....
>
> > I think the latency will be much higher if you let LVS redirect every
> > packet of every connection over a slow link. DNS lets the clients connect
> > directly to each server.
>
> I though that LVS/TUN worked worked the same way as LVS/DR, where the LVS
> forwards the request on to a realserver which answers back directly to the
> client?
> If that's true then only the initial request will go to the primary site,
> then out and in to the secondary site.
> After that the client will communicate directly with the realserver at the
> secondary location.
> Or am i completely wrong here?

Ok, I am slightly wrong, and you are slightly wrong :-)
In LVS/TUN the packet flow is asymetric. Traffic from the client to the
server will _always_ go through the LVS server. Return traffic will not.

In your case actual data from the server will go directly to the client,
but the periodic 'acks' that the client sends will go through the LVS
server.

So, you will experience latency in the connection. The ratio of
(Server-to-client-bytes) to (client-to-server-bytes) is very high, but if
you look at the (server-to-client-packets) to (client-to-server-packets)
you will see a very close to 1-1 ratio. This will have a major impact on
your latency. This is because the server has to wait for an 'ack' before
transmitting any more data, and the 'ack' has to travel the long way to
get there.

>
> All files serverd at the secondary location are big ones (downloads of demos
> etc) so the request is a very small part of the whole transfer.
> We're wasting some bandwidth here but i imagine it can't be that much?

Why not have them listed as separate servers (demos.yourdomain.com) and
have the href point there
(http:/demos.yourdomain.com/images/somebigfile.mpg). Then you can setup an
LVS server at the secondary site that pretends to be demos.yourdomain.com.
You won't have the difficulty of setting up DNS, and you wont have the
traffic problems of trying to route there from your primary LVS.

--
Michael Brown



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