From: Cees de G. <cg...@cd...> - 2002-07-11 09:35:07
|
Hi, I'm thinking of a network structure for our server farm that would make it a bit more resistent against hardware failure. One of the things is to have movable UML boxes (movable because they run off NFS-mounted roots so I can boot them on any machine in the network; with fileserver replication, quite a bit of damage needs to be done before they go down) taking up important tasks. Currently, I'm looking at monitoring (dedicating a UML box to netsaint, easy enough) and firewalling/load balancing. The latter two are interesting :-). The idea is to have most machines directly attached to the internet (the machines that you would put in the 'DMZ' in a normal firewall configuration). All of them would have firewall mark + ipvs rules setup so that any packets coming from outside are tunneled to the virtual firewall - a UML box (or better, a pair of UML boxen with heartbeat). All these front-end machines have heartbeat installed with a list of addresses that should be accessible from the outside - with heartbeat, only one of the machines will have the addresses configured and thus will ARP for them, which makes it receive all the traffic (of course, a more messy solution with simply all of the machines ARPing on these addresses would work). The virtual firewall 'detunnels' the packet, processes it according to its own firewall rules, and forwards it. This may involve ipvs load balancing somewhere down the line - probably on the same machine for efficiency. I think technically this should work. The advantage is clear: without having to dedicate machines in a small server farm (I run 14 machines at the moment), you could have increased availability in your firewall. However, before I start solving this big puzzle, I'd like to know whether anyone has done this, and what sort of performance I can expect from UML in processing network traffic. Could a UML box on a reasonable host (say 800-1000MHz PIII class) sustain 10Mbit firewalling load? |
From: David C. <da...@da...> - 2002-07-11 13:28:04
|
Cees de Groot wrote: > The virtual firewall 'detunnels' the packet, processes it according to > its own firewall rules, and forwards it. This may involve ipvs load > balancing somewhere down the line - probably on the same machine for > efficiency. I'm doing something similar, although I'm purely using iptables on UML for firewalls. Rather than tunneling, I used Ethernet bridging, which works very well, since you can include a tap device in a bridge. All of my boxes have 10/8 IPs, and my UMLs ARP for the /28 from my ISP - I then use iptables to NAT packets to the appropriate box. Rather than using heartbeat, I've been looking at using STP with the bridging system to fail-over the network - Heartbeat is probably more appropriate for some networks, but the bridge stuff makes it easy. I've pushed ~90Mbit over UML, and it didn't seem to care (Load of about ~0.20 on a PIII733), although I was not doing NAT for that traffic which uses a little more CPU. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Cees de G. <cg...@cd...> - 2002-07-11 18:11:54
|
David Coulson wrote: > > I've pushed ~90Mbit over UML, and it didn't seem to care (Load of > about ~0.20 on a PIII733), although I was not doing NAT for that > traffic which uses a little more CPU. > That's good enough for me - by the time I'm doing 90 Mbit, I'm going to dump the whole thing on an IBM zServer anyway ;-). Thanks for the performance and configuration info. I don't think I can use the ARPing/Ethernet briding trick, because chances are good that the very host that receives the to-be-firewalled packets also happens to be running a load-balanced webserver on one of these IP addresses; that's why I want to wrap them in tunneling packets to make sure that they arrive where they should arrive. Regards, Cees |
From: David C. <da...@da...> - 2002-07-11 18:19:14
|
Cees de Groot wrote: > That's good enough for me - by the time I'm doing 90 Mbit, I'm going to > dump the whole thing on an IBM zServer anyway ;-). I wish I had your budget ;-) > Thanks for the performance and configuration info. I don't think I can > use the ARPing/Ethernet briding trick, because chances are good that the > very host that receives the to-be-firewalled packets also happens to be > running a load-balanced webserver on one of these IP addresses; that's > why I want to wrap them in tunneling packets to make sure that they > arrive where they should arrive. I'm not sure about IPVS, but with NAT, you can run stuff on the local machine without any problems. As long as the packet heads out through the same box it came in on, then it will work just fine. If you're pushing a lot of traffic, encapsulating packets needlessly will waste a significant amount of bandwidth. David -- David Coulson http://davidcoulson.net/ d...@vi... http://journal.davidcoulson.net/ |
From: Cees de G. <cg...@cd...> - 2002-07-11 18:59:23
|
David Coulson wrote: > Cees de Groot wrote: > >> That's good enough for me - by the time I'm doing 90 Mbit, I'm going >> to dump the whole thing on an IBM zServer anyway ;-). > > > I wish I had your budget ;-) Well, I'm assuming that by that time I'll have that budget ;-) > > I'm not sure about IPVS, but with NAT, you can run stuff on the local > machine without any problems. As long as the packet heads out through > the same box it came in on, then it will work just fine. If you're > pushing a lot of traffic, encapsulating packets needlessly will waste > a significant amount of bandwidth. > Yup, but NAT translation needlessly wastes a lot of CPU and memory on the translating box, plus that you're not free to route packets back as you like. All in all, it'd be a PITA for the sort of setup that I have in my mind (because you just want to kick packets from UML box to UML box if necessary, and the box that finally actually processes the packet should be able to get it out the shortest way, i.e. its default route) |