All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hasenack <andreas@conectiva.com.br>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] many ways to do load balancing (or not?)
Date: Fri, 22 Nov 2002 20:34:52 +0000	[thread overview]
Message-ID: <marc-lartc-103799734131936@msgid-missing> (raw)
In-Reply-To: <marc-lartc-103788125614081@msgid-missing>

Em Fri, Nov 22, 2002 at 10:05:25AM -0800, William L. Thomson Jr. escreveu:
> > So it's more like redundancy/HA with a best effort towards balancing.
> 
> Yes, or in other terms. My need was a single gateway for my servers
> although I have two ISPs. The amount of load balancing you get it about
> the same as the amount of redundancy. You get a partial solution to
> both, but not a complete solution.

I just found this patch, has anybody already played with it?

ftp://sliepen.warande.net/pub/eql/patch-2.4.18-2.gz

Excerpt:

Load balancing needed a slight adjustment to the unpatched linux kernel,
because of the route cache. Multipath is an option already found in the old
2.1.x kernels. However, once a packet arrives, and it matches a multipath
route, a (quasi random) device out of the list of nexthops is taken for its
destination. That's okay, but after that the kernel puts everything into a
hash table, and the next time a packet with the same source/dest/tos arrives,
it finds it is in the hash table, and routes it via the same device as last
time. The adjustment I made is as follows: If the kernel sees that the route
to be taken has got the 'equalize' flag set, it not only selects the random
device, but also tags the packet with the RTCF_EQUALIZE flag. If another
packet of the same kind arrives, it is looked up in the hash table. It then
checks if our flag is set, and if so, it deletes the entry in the cache and
has to recalculate the destination again.

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

  parent reply	other threads:[~2002-11-22 20:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-21 12:19 [LARTC] many ways to do load balancing (or not?) Andreas Hasenack
2002-11-21 17:46 ` Ashok N N
2002-11-21 19:11 ` Andreas Hasenack
2002-11-21 20:00 ` Ramin Alidousti
2002-11-21 22:20 ` William L. Thomson Jr.
2002-11-21 22:55 ` Christoph Simon
2002-11-21 23:41 ` Christoph Simon
2002-11-22  0:06 ` William L. Thomson Jr.
2002-11-22  0:24 ` William L. Thomson Jr.
2002-11-22  1:17 ` Ashok N N
2002-11-22 12:28 ` Andreas Hasenack
2002-11-22 12:30 ` Andreas Hasenack
2002-11-22 12:39 ` Andreas Hasenack
2002-11-22 12:41 ` Andreas Hasenack
2002-11-22 13:00 ` Christoph Simon
2002-11-22 13:26 ` Vincent Jaussaud
2002-11-22 18:05 ` William L. Thomson Jr.
2002-11-22 18:21 ` William L. Thomson Jr.
2002-11-22 18:37 ` William L. Thomson Jr.
2002-11-22 18:47 ` William L. Thomson Jr.
2002-11-22 20:34 ` Andreas Hasenack [this message]
2002-11-25 13:20 ` Vincent Jaussaud

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-103799734131936@msgid-missing \
    --to=andreas@conectiva.com.br \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.