Date: Fri, 19 Mar 1999 16:03:29 -0500 From: Christopher Sedore <cmsedore@maxwell.syr.edu> To: "'freebsd-net@freebsd.org'" <freebsd-net@freebsd.org> Subject: RE: clustering/load balancing Message-ID: <262C3DA9BE0CD211971700A0C9B413A1CBDA@exchange.maxwell.syr.edu>
next in thread | raw e-mail | index | archive | help
> From: Julian Elischer [SMTP:julian@whistle.com] > > Christopher Sedore wrote: > > [...] > > > > > It should work, though the fwd localhost would have to imply that we > > should accept A's address as our own (not sure if that is implied or > > not, or if I'm just missing something). > > That's what ipfw fwd does if the fwd address is local. > BUT it doesn't cahnge the destination on the packet to be local, > rather, > it changes the socket to think it's somewhere else.. > > > The difference is that you are > > solely dependant on machine A. If A croaks, you're done. That is, > > you've got a single machine depenancy--fine for load sharing, but > > perhaps not optimal for clustering with fault tolerance. If you > have to > > have aliases for A's address, I think that B, C, and D would need > > separate links back to A to eliminate IP address conflict issues, or > > you'd need mods similar to mine. > > No that's the thing about IPFW fwd.. > The addressed on the packets being sent out of B,C,D will look as if > the > packets > have come from A, but they will have physical layer addresses that > will > make them > be accepted by A and forwarded. > > > There are no IP address conflicts. > > The socket that catches the packet on B,C,D will actually think it is > on > A > > Amazingly this works.. Netstat will even report that you have a > foreign socket on your system :-) > That is quite cool. I didn't notice the glue for that when messing with ip_input. I'm going to have a look at it. > You'll need an up-to date ip_input.c for this to work.. there's a bug > in > 3.1-RELEASE. > > > > You may have additional problems with high load on A. I know that > our > > (admittedly behind the times) PP200 FreeBSD firewall can get a bit > busy > > when we pass the 4000pps (that is 4000pps on the in and the out > > interfaces simultaneously) mark. > > Sure then just dedicate one machine to do the diversion and such. > > > This means that you'd need additional > > metrics to determine how much loading A should get vs the rest, > > recognizing that you may increase application latency on A as the > load > > on B, C, and D increase. Of course, if you were using FreeBSD for A > > anyway my methodology would leave excess CPU cycles for waste on > that > > box. (Also, I don't have any code for differential load control > either, > > and it could certainly happen in my scenario though the effects > would > > probably not be as dramatic). > > > > -Chris > > You should be able to throw a P60 in there as 'A' > from the junk heap and get away with it... > Not if you're doing 100mbit links. I had a P90 in for our firewall (probably more rules than you'd need for a dispatch though) and it couldn't handle more than 3000 or so packets per second passing through it. For small configurations it should be fine. All of the above still does not resolve the single machine dependancy of this scheme, which is a non-trivial fault IMHO. I may think about writing a daemon to do monitorig and distribution for the above scheme, though. -Chris > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?262C3DA9BE0CD211971700A0C9B413A1CBDA>