[ previous ] [ next ] [ threads ]
 
 From:  "Eric Shorkey" <eshorkey at commonpointservices dot com>
 To:  "David Rodgers" <david dot rodgers at kdsi dot net>, "Mark Spieth" <mspieth at neod dot net>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Load Balancing Again...
 Date:  Fri, 28 May 2004 20:35:54 -0400
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. 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.

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 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. 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.

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.

-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
>
>