[ previous ] [ next ] [ threads ]
 
 From:  "Christian Nyegaard" <christian at nyegaard dot net>
 To:  "'Eric Shorkey'" <eshorkey at commonpointservices dot com>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  RE: [m0n0wall] Load Balancing Again...
 Date:  Sat, 29 May 2004 10:00:46 +0200
This is a bit over my head to be perfectly honest, but wouldn't it be
Relativly simple to write a bash or perl or whatever suits your bowlingball
bag
Script that'll ping hosts 192.168.1.30, .31, .32 etc and if one of them
doesn't
Reply as intended, modify the RR rule in the ruleset ?

Seems to me this would help on the "what if one of the boxes goes down"
scenario.

As said in the beginning, this is over my head and out of my league but I'm
a huge
Fan of people in my field suggesting things to me that may or may not be
based on
True knowledge or competence but simply something that seems like a
worthwhile idea
Or at least a suggestion.. :-]

Mvh.,
Christian Nyegaard mailto:christian at nyegaard dot net
 

> -----Original Message-----
> From: Eric Shorkey [mailto:eshorkey at commonpointservices dot com] 
> Sent: 29. mai 2004 04:25
> To: David Rodgers
> Cc: Mark Spieth; m0n0wall at lists dot m0n0 dot ch
> Subject: Re: [m0n0wall] Load Balancing Again...
> 
> 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-detai
> ls.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
> > >
> > >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> 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
>