All of lore.kernel.org
 help / color / mirror / Atom feed
From: christian.benvenuti@libero.it
To: lartc@vger.kernel.org
Subject: [LARTC] HOWTO: 'auto loadbalancing' page created
Date: Tue, 17 Jul 2001 08:05:48 +0000	[thread overview]
Message-ID: <marc-lartc-99535718508565@msgid-missing> (raw)
In-Reply-To: <marc-lartc-99521701717042@msgid-missing>

If I understood it correctly, what you are trying to do is CPU/IO load
balancing instead of network-bandwidth load balancing.
Unless the servers are in different physical networks (ie reacheble with
different and not overlapping paths), the only load balancing that makes
sense is only CPU/IO load balancing since the "common and/or
overlapping" path would be the bottleneck already.
I probably did not understand your point.

Anyway, here are a few things you may consider:

- If the server are higly loaded (but you say that's not the case) it is
never a good idea to turn a switch into an hub. Even if the switch is
not loaded, it may be running the spanning tree and it may be a bad and
dangerous idea to switch it off (=turn into an hub).

- If with this "I was having some disturbing ideas last week about doing
loadbalancing without a distributing agent - the nodes take care of it
themselves." you mean that the solution should be plug&play, I do not
think yours is such. 
REASONS:
-You must be able to recover in case one of the servers fails, which
means that if all the traffic going to server X because of the last N
bits values is not handled by the failed server, no one else is going to
take care of them. You should introduce a sort of hello mechanism to
find out who else is in your "group" and try to mantain and adapt the
traffic distribution rules accordingly. Moreover, load balancing based
on the source IP addr is not really the best choice for a CPU/IO load
balancing (is is not for others criteria either). Of course, whether it
would be good or not depends on the type of CPU/IO operations, but I
think on average they are not (I agree that it would be better than
nothing ...).

Question:
What is the difference between having all the servers receiving the
packets and only one accepting it because of the rules you explained,
and having the traffic directly forwarded to the only one that will not
discard it? If you do not use any "transparent" mechanism such as the
one I suggested above, I think there would not be any difference.

Possible problem.
Supposing you use the dynamic mechanism, since the same "virtual" server
could be responsable for different ranges of IP addresses in different
moments (even if they are not supposed to change frequently), this may
mean that if one virtual server is holding some "session" information
(es. cookie), the new guy that will be in charge for the same session
will not have those information and you may have problems at higher
layers.

There are many other small issues to consider, but since I am not sure I
understood your point, I stop the mail here :-)

/Christian



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

      reply	other threads:[~2001-07-17  8:05 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-15 17:06 [LARTC] HOWTO: 'auto loadbalancing' page created bert hubert
2001-07-17  8:05 ` christian.benvenuti [this message]

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-99535718508565@msgid-missing \
    --to=christian.benvenuti@libero.it \
    --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.