Re: [LARTC] many ways to do load balancing (or not?)

From: "William L. Thomson Jr." <support@obsidian-studios.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] many ways to do load balancing (or not?)
Date: Fri, 22 Nov 2002 00:06:26 +0000	[thread overview]
Message-ID: <marc-lartc-103792368101951@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103788125614081@msgid-missing>

On Thu, 2002-11-21 at 14:55, Christoph Simon wrote:
> On 21 Nov 2002 14:20:57 -0800
> "William L. Thomson Jr." <support@obsidian-studios.com> wrote:
> 
> > Also I do not believe the load balancing is packet based. Usually it's
> > more "connection" based. Meaning that if you request a file, more than
> > likely all parts of that file will be transfered using the same route.
> > If you request it again, it may take the same route or another.
> 
> It is packet based. There is no connection concept in IP.

That's why I put that word in quotes. I meant more like during a file
transfer than with a connection in the true sense.

> >From the IP Command Reference:
> 
> 	equalize: allow packet by packet randomization on multipath
> 	routes.
> 
> My understanding is, that for equalize to work, all lines must go to
> the same point and that must not be the end point. Also, this same
> point must implement the equalize very much the same way.

Not necessarily. I have two lines going in completely different
directions, different private nets, and then via different ISP/Public
IPs.

Now for true load balancing or bonding yes. Both lines would need to be
coming from and going to the same ISP.

> > Now if the request was generated from the inside it would still work
> > some what the same. If I send two emails out at once, the first will use
> > gw1 and the other will use gw2.
> > 
> > All packets for each will travel via the same route and use the same
> > gateway from start to finish.
> 
> Not using equalize.

Yes using equalize, because the path will already be known and used from
catch. Correct that if a further look up occurs the packets will use a
different interface, but that is rare. Most of the time during a
transfer the route is already known and kept in catch from the first
initial lookup.

I have not run into any problems along those lines.

> > If it was more on a packet level, the other end would be confused.
> 
> unless there is a routing cache which will hold the path.

That's the problem. The route cache on the Linux load balancing router
will be correct, but the route cache on the client will not be.

The client will be caching the wrong path. So unless a redirect is sent
the client will site there and expect further communication using the
route in cache. 

When I was experimenting with route cache timing in the Linux kernel, I
had all kinds of problems on the client side. The client's catch
settings would need to be the same as the linux router. Which is pretty
impossible on the Internet. On a lan it would be a different story.

-- 
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios Inc.
439 Amber Way
Petaluma, Ca. 94952
Phone  707.766.9509
Fax    707.766.8989
http://www.obsidian-studios.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/