Date: Wed, 25 Jul 2001 11:22:50 +0100 From: Paul Robinson <paul@akita.co.uk> To: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> Cc: Enriko Groen <enriko.groen@netivity.nl>, 'Tony Saign' <tony@saignon.net>, freebsd-isp@freebsd.org Subject: Re: Redundant setup on a budget?? Message-ID: <20010725112250.N83511@jake.akitanet.co.uk> In-Reply-To: <1241681557.20010725114735@buz.ch>; from gabriel_ambuehl@buz.ch on Wed, Jul 25, 2001 at 11:47:35AM %2B0200 References: <510EAC2065C0D311929200A0247252622F7A7B@NETIVITY-FS> <20010724154211.C34017@jake.akitanet.co.uk> <1241681557.20010725114735@buz.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 25, Gabriel Ambuehl <gabriel_ambuehl@buz.ch> wrote: > Actually, there is, sort of at least. Look into the ipfilter package > (shipped with FreeBSD 4.3 or on http://coombs.anu.edu.au/ipfilter/) > and especially its l4check tool. I'll look into this. Thanks for the tip. We're evaluating ipfilter for another project, so I'm sure I would have stumbled over this eventually. > Basically, the load balancing part is easy enough (look ipfilter and > natd, both do it). Harder but still doable with a reasonable amount > of work is fail over (l4check might be good enough for your uses, for > us it was too limited). What's really hard is to mirror the servers > in near realtime (and here are WE searching for a solution). While > databases > bring their own replication features, filesystems do not (with the > possible exception of coda but that beast did neither work on my > systems nor does it look like it's being maintained). That's why I wanted to know when FBSD clients were going to be able to create NFS locks with rpc.lockd - this is now fixed in -current which means you can just wack your FS on one NFS system, and all the boxes you want can come off that one filesystem. Far easier to implement than mirroring, and providing the locking is in place (and I'm going to get around to pestering for this to be MFC'ed), you're not going to have problems with atomic transactions and the like at an FS level. No mirroring required - you are only using one FS. Of course, the flip-side to this is slightly slower performance, but then you can always look at multiple NICs and trying to get trunking working. ;-) > Another solution, which I could also agree on using it, would be to > have http://people.freebsd.org/~abial (Spy) to log all writes to the > filesystem and simply copy all the modified files over the LAN (using > rsync, scp or even NFS). What definitely doesn't work on most This is bad. There is no locking in place, so atomic actions get trashed. > webservers (not on shared ones, anyway), is offline replication like > standard rsync or cpdup as those take about 1h to simply check and > update the twin of a 5 GB server which is not what I consider to be > realtime (basically, I could agree on using any solution that doesn't > create more than a 10 to 15min lag, even on big mailservers with > hundred of thousands of files and dirs). It really depends on what you intend doing. By the sounds of it, you appear to be talking about a read-only environment with very little/occasional writing. I, however, am talking about getting MySQL servers to cluster, and maintain the new transactional support in there. > [1] Having spend serious time looking into all available load > balancing and fail over systems, I found that only NAT is a > practicable way for a whole server farm. If you just need to have > fail > over for two servers, some IP takeover method is fine (if you can > implement it properly which isn't as easy as it looks in first place, > BTW). If you don't really need redundancy, you could simply > use round robin DNS. Yeah, I had looked at NAT approaches. The free chapter of the new O'Reilley book on SLB is the one about NAT which I had a quick scour of, and it looks quite suitable for some of the things I'm planning. I really don't want to do primary/backup work for some of my projects - I'd much rather have half a dozen servers all working at the same time, and allow for one or two of the boxes to fail. -- Paul Robinson ,--------------------------------------- Technical Director @ Akita | A computer lets you make more mistakes PO Box 604, Manchester, M60 3PR | than any other invention with the T: +44 (0) 161 228 6388 (F:6389)| possible exceptions of handguns and | Tequila - Mitch Ratcliffe `----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-isp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010725112250.N83511>