From: Grant Taylor <gtaylor@riverviewtech.net>
To: Mail List - Netfilter <netfilter@vger.kernel.org>
Subject: Re: Load Balance
Date: Tue, 17 May 2011 13:07:48 -0500 [thread overview]
Message-ID: <4DD2B974.7060105@riverviewtech.net> (raw)
In-Reply-To: <BANLkTi=gB609MZNzuJ-277B23wCiB5EhOQ@mail.gmail.com>
On 05/17/11 12:00, Usuário do Sistema wrote:
> but I still wonder what is the metric used to do the load balance I
> guess that the point is in line below
(I'd have to go back and re-read to know for sure what the "metric" is
that you are referring to and how it effects things.)
> iptables -t mangle -A PREROUTING -p tcp -m state --state NEW -m
> statistic --mode nth --every 2 --packet 0 -j CONNMARK1
> iptables -t mangle -A PREROUTING -p tcp -m state --state NEW -m
> statistic --mode nth --every 2 --packet 1 -j CONNMARK2
>
> I understand that each two new connections the third go out to next
> link making the load balance.
>
> right ??
In (basic) theory, yes.
If we limit the scope to be just new connections (that will match the
above rules), yes, they will alternate between the connections (via
marks) thus hypothetically equalizing the load on the connections.
The thing that this does not take in to account is what type of traffic
a given connection is nor how long lived and active it is.
Let's say that I have the following (new) connections in the following
sequence.
1) Simple SMTP test email.
2) HTTP download of kernel source.
3) Simple DNS query.
4) VPN connection.
You will find that connections #1 and #3 are marked with CONNMARK1 and
that connections #2 and #4 are marked with CONNMARK2. So what you end
up with is two very ""light connections on CONNMARK1 and two much
heavier connections on CONNMARK2.
The connections did end up "load balanced" (in a manner of speaking), or
"distributed" (is probably a better way to describe it) across the
multiple CONNMARKs. However, if you look at the utilization of the two
CONNMARKs or the physical connections they represent, you will find that
one is way under utilized and the other is probably saturated.
However, with out doing some relatively nasty things (i.e. spoofing
which requires support upstream) there is little that you can do about this.
So, you do end up distributing the connections, but not necessarily load
balancing.
> thank!
You are welcome.
Grant. . . .
next prev parent reply other threads:[~2011-05-17 18:07 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-17 23:22 Load Balance Usuário do Sistema
2011-05-15 17:23 ` Andrew Beverley
2011-05-16 20:24 ` Usuário do Sistema
2011-05-16 21:38 ` Andrew Beverley
2011-05-16 22:42 ` Usuário do Sistema
2011-05-17 0:45 ` Grant Taylor
2011-05-17 17:00 ` Usuário do Sistema
2011-05-17 18:07 ` Grant Taylor [this message]
2011-05-17 20:06 ` Usuário do Sistema
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=4DD2B974.7060105@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--cc=netfilter@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).