Date: Wed, 25 Jul 2001 13:14:37 +0200 From: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> To: Paul Robinson <paul@akita.co.uk> Cc: Enriko Groen <enriko.groen@netivity.nl>, 'Tony Saign' <tony@saignon.net>, freebsd-isp@freebsd.org Subject: Re[2]: Redundant setup on a budget?? Message-ID: <1996903256.20010725131437@buz.ch> In-Reply-To: <20010725112250.N83511@jake.akitanet.co.uk> References: <510EAC2065C0D311929200A0247252622F7A7B@NETIVITY-FS> <20010724154211.C34017@jake.akitanet.co.uk> <1241681557.20010725114735@buz.ch> <20010725112250.N83511@jake.akitanet.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hello Paul, Wednesday, July 25, 2001, 12:22:50 PM, you wrote: >> 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. It's well hidden in there. Generally, I'd prefer ipfilter over ipfw any time, IMHO it's the much more sophisticated package but it sometimes suffers a bit of it's extrem multi platform approach, which means that you can't always use the newest release on your box. > 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. IMNSHO, this is a flawed approach as this one filesystem which must reside on one box if you don't use distributed RAID, is THE single point of failure. > Far easier to implement than mirroring, That is true. > 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. Some problems with this: rpc.lockd isn't one of the fastest pieces of code I can think of (can't be, it's whole purpose doesn't allow it). Further, if you have one filesystem, then you also got the problem that if one machine is cracked, the cracker can fuck with all of your data. On a decent mirroring scheme, this shouldn't be the case (rather easy if you got different sets of data you can put into their own segments, a bit harder if the data must be available to each and every node of your cluster but this isn't the case for us, as we do webhosting which can very nicely be segmented). > 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. ;-) Trunking isn't supported at all by FreeBSD if I'm not totally mistaken. >> 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. If you got atomic operations on the filesystem, you're doing something wrong, IMO. That's what databases are for. Further, for us, the load balancing aspect isn't as important as the fail over one, our current vision doesn't even do real load balancing on the FS level (simply because the crappy code that most CGI scripts got won't even support really support this on one filesystem). Our approach is to have twins of boxes, of which each serves for half of the domains the twin hosts, if one of them breaks, the other one also serves the half that just went down. If you need real load balancing, use a DBMS, that's what were made for. >> 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. More or less ACK. Mostly FTP uploads by the users and some writes to the FS from some badly implemented scripts which I'm not going to babysit. If you > I, however, am talking about getting MySQL servers to cluster, and > maintain the new transactional support in there. Why do you need NFS locking, then? MySQL does everything that is needed to replicate the data. It gets hairy, though, if one DB server isn't enough to cope with the update/insert statements but then you should probably spend more money on the DB server. > 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. First point to get clear about it is: does your project allow it to be run entirely out of a DB (perhaps with local, non critical FS caches which don't matter if the go down), if it can (and most DB based apps can, problems starts with flatfile based scripts), you're lucky, as you simply need to have some NAT gateway (two would be better, of course, so you haven't got a single point of failure there) and some backend DB servers which do their replication themselves anyway. Best regards, Gabriel Pa“7Ì¿74 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5i iQEVAwUBO16cEsZa2WpymlDxAQGKAgf/TaY6f0ntNnbRAd99qC9gB6+wBEor12Xu ttuvrnge3nrnq0jS8BK+QADGMp8AWOOE1jDbRq8o+pIFgahpxZ+vgrACXDBIfW6e IHHyeYtSwCJrshfi4Rl/cnVgU6UG71SPF7eUY0ZLmQD5I180krX9B6tO4hNeD7vb 39DdAwnC7Dr+Gdd0aRLZdcTanlXJAFBSQNQ3FXrhAst3JYBAdiE0zXWUozb5SHN4 kAbDLaS2YHWfGN40ocU3VF1ywdODXhD39sduD4cZkHq9VXCsbfxLsFeMmhJHvSBj W/9we3tIzTdhr+NpD8ZRtyHkoDEixFCMj2GWNY/3ACQ3KsjAi+ZkxQ== =5HkZ -----END PGP SIGNATURE----- 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?1996903256.20010725131437>