[ previous ] [ next ] [ threads ]
 
 From:  "Eric Shorkey" <eshorkey at commonpointservices dot com>
 To:  "David Rodgers" <david dot rodgers at kdsi dot net>
 Cc:  "Mark Spieth" <mspieth at neod dot net>, <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Load Balancing Again...
 Date:  Fri, 28 May 2004 22:24:43 -0400
Well, I'll have to give you this much. A very basic RR load balancer is
better than nothing at all. I would never use it, and I don't believe that
it is really worth the effort of m0n0wall's primary developers to waste
their time on it. But there seems to be some measure of a demand for it. If
they do, great. If not, oh well. Either way it doesn't affect my use of
m0n0wall.

You're probably quite right on the processing power of a soekris. They are
pretty weak compared to today's average computer. But they have a very
specific market they are catering to. These little guys would be pretty good
for a load balancer though.
http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=146907&Sku=S452-1001
It's not a soekris, but I don't believe that any project should limit itself
just because a certain hardware platform can't push the bits fast enough to
keep up. And at $30, you really can't complain.

And actually, Alteons do a surprisingly good job at performing image host
redirection, you just have to know how to configure them correctly. If
you've had problems with Alteons screwing this relatively basic task up,
then whoever configured it screwed it up.

Round robin dns does do a pretty poor job of distributing connections.
Mainly because the result gets cached by some isp's name servers and
suddenly everyone from that isp is using the same server. If it's a big isp,
then one server is going to get hit a lot more than the others. Performing
rr on the connection level as you're pushing for would, indeed, be a large
improvement over this. As I'm sure you've noticed by now, I'm more inclined
to use a high availability balancer, but that doesn't necessarily mean
that's the best way in any given situation. I just prefer the high
availability balancers because you can always dumb down their actions do
that it performs as a simple rr balancer if the situation calls for it.

Thanks for the tip on Cacti. I checked it out and was thus far very
impressed. So far I've been using shell scripts to snmp poll my systems, and
it's a pain in the rear to add new ones. Cacti should make life a lot easier
in that respect.

----- Original Message ----- 
From: "David Rodgers" <david dot rodgers at kdsi dot net>
To: "Eric Shorkey" <eshorkey at commonpointservices dot com>
Cc: "Mark Spieth" <mspieth at neod dot net>; <m0n0wall at lists dot m0n0 dot ch>
Sent: Friday, May 28, 2004 9:26 PM
Subject: Re: [m0n0wall] Load Balancing Again...


> On Fri, 2004-05-28 at 19:35, Eric Shorkey wrote:
> > Seems like a nice idea, but I don't think you realize how much work it
takes
> > to make a truly useful load balancer. You want more of a proxy than a
simple
> > ipf rule. The reason being, load balancing is nice, but load balancing
with
> > high availability is much more useful.
>
> Yes but load balancing with high availability isn't what is being asked
> for. It would be nice but a simple rr load balancing is much better than
> nothing.
>
> >  If one of your pop3 daemons dies and
> > is no longer accepting connections on port 110, then you'd want your
load
> > balancer to notice this when a new guest tries to connect, and
automatically
> > try another server. Guests that are already connected are out of luck.
(Too
> > bad, so sad.) But new SYNs shouldn't be allowed to come back with an
RSET
> > unless all of the servers are down. To implement this, you'll want a
more
> > sofisticated traffic proxy. Something that holds the connection's hand
until
> > it finds a live host, and then it can fall back on the simple ipf
ruleset to
> > keep the packets going to the same host.
>
> Point taken ..... the problem (as so many people on the list pointed out
> before) is a real proxy type load balancer might end up taking much more
> cpu that the fastest soekris could provide.
>
> > Even then, this is still a pretty basic load balancer. When you stop
talking
> > about pop3 and start talking about http, things gets different. Real
> > different. For example, a lot of web providers like to have image
servers
> > separate from the script running servers, purely to keep the load down
on
> > the busy scripting servers.
>
> This is definitely the exception rather than the rule.
>
> > This means you have to start examining the
> > application layer (ie truly proxying) to see what object the browser is
> > trying to retrieve, and then redirect it to a server within a server
group
> > that is responsible for serving that object.
>
> even most expensive load balancers like localdirector or an alteon don't
> accomplish this well.
>
> >  I would really love to see a
> > m0n0wall style load balancer, but I believe that this is a whole new
project
> > all together.
> > You'd be surprised how much of a beating load balancers take
> > when you bring http to the table. I don't think you could really expect
a
> > system to perform both stateful packet inspection with over 100 rules
AND be
> > an effective load balancer at the same time.
>
> Agreed that a full on load balancer is better as a seperate device but
> even load asside a simple round robin inbound nat is THE BEST solution
> for a load balancer built into a firewall because you would NOT want
> ports on your firewall open to the public with a daemon listening even
> if it is just to establish a connection and be proxied.
>
> My interest in this service isn't to provide high availability at all
> but to provide a simple solution to divide load across multiple servers
> that would distribute connections better than rrdns
>
> > Oh, and since you use mrtg, I highly suggest looking into rrdtool if you
> > haven't already done so. Same purpose as mrtg, but you don't have to
babysit
> > the data store to prevent it from growing too large. I use rrdtool here,
and
> > haven't looked back to mrtg yet.
>
> RRDTool rocks and there are many good front ends to it like cacti
> http://www.raxnet.net that make it a joy to work with. My technicians
> can now add/delete/manage their own devices withought shell access to
> any of my devices.
>
> David
> >
> > -Eric
> >
> > ----- Original Message ----- 
> > From: "David Rodgers" <david dot rodgers at kdsi dot net>
> > To: "Mark Spieth" <mspieth at neod dot net>
> > Cc: <m0n0wall at lists dot m0n0 dot ch>
> > Sent: Friday, May 28, 2004 7:47 PM
> > Subject: Re: [m0n0wall] Load Balancing Again...
> >
> >
> > > After my little incident last week it's pretty much a no brainer that
I
> > > think this is a great idea as well. Especially if it's that simple.
> > >
> > > David
> > >
> > >
> > > On Fri, 2004-05-28 at 17:23, Mark Spieth wrote:
> > > > The subject of load balancing inbound nat connections to several
boxes..
> > > >
> > > >
> > > > eg. 1 external IP that round robins traffic to 2 internal hosts...
> > > >
> > > > Has been brought up quite a few times.. Now, I am a openbsd and
linux
> > > > person, and my monowall development box is current;y down so I had
no
> > > > way to look into this, However it seems to me that freebsd (ipf)
allows
> > > > for the round-robin flag which allows you to setup 2 or more rules
to
> > > > round robin inbound connections to various machines.. See Below from
my
> > > > openbsd box
> > > >
> > > > rdr ng0 0.0.0.0/0 port 110 -> 192.168.2.29 port 110 tcp round-robin
> > > > rdr ng0 0.0.0.0/0 port 110 -> 192.168.2.30 port 110 tcp round-robin
> > > > rdr ng0 0.0.0.0/0 port 110 -> 192.168.2.31 port 110 tcp round-robin
> > > >
> > > >
> > > > This seems to balance things out fairly well. In may case if you
look at
> > > > my mrtg stats on the site below for pop3 it does a decient job of
> > > > balancing traffic between the servers.
> > > >
> > > > http://sm1.neod.net/
> > > >
> > > > Of course this does not take into consideration individual server
load
> > > > of if the server is even up, But it should be an easy thing to
implement
> > > > into monowall.
> > > >
> > > > Just my .02
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> > For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch
> >
> >
>
>