From owner-freebsd-isp Wed Jul 25 7:20:28 2001 Delivered-To: freebsd-isp@freebsd.org Received: from jake.akitanet.co.uk (jake.akitanet.co.uk [212.1.130.131]) by hub.freebsd.org (Postfix) with ESMTP id D0C4737B61F for ; Wed, 25 Jul 2001 07:16:32 -0700 (PDT) (envelope-from wiggy@wopr.akitanet.co.uk) Received: from dsl-212-135-208-201.dsl.easynet.co.uk ([212.135.208.201] helo=wopr.akitanet.co.uk) by jake.akitanet.co.uk with esmtp (Exim 3.13 #3) id 15PPS4-0001m4-00; Wed, 25 Jul 2001 15:15:52 +0100 Received: from wiggy by wopr.akitanet.co.uk with local (Exim 3.21 #2) id 15PPTt-000BcV-00; Wed, 25 Jul 2001 15:17:45 +0100 Date: Wed, 25 Jul 2001 15:17:45 +0100 From: Paul Robinson To: Gabriel Ambuehl Cc: freebsd-isp@freebsd.org Subject: Re: Redundant setup on a budget?? Message-ID: <20010725151745.A36223@jake.akitanet.co.uk> References: <510EAC2065C0D311929200A0247252622F7A7B@NETIVITY-FS> <20010724154211.C34017@jake.akitanet.co.uk> <1241681557.20010725114735@buz.ch> <20010725112250.N83511@jake.akitanet.co.uk> <1996903256.20010725131437@buz.ch> <20010725124353.A6548@jake.akitanet.co.uk> <2411019395.20010725142313@buz.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2411019395.20010725142313@buz.ch>; from gabriel_ambuehl@buz.ch on Wed, Jul 25, 2001 at 02:23:13PM +0200 X-Scanner: exiscan *15PPS4-0001m4-00*$AK$p/VP5SwLNT9k5UCTLc/ep0* Sender: owner-freebsd-isp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Jul 25, Gabriel Ambuehl wrote: > Actually, it's more solarisy ;-). AFAIK, it works on *BSD, Solaris > and HPUX and Linux 2.0.x. But the state stuff is really interesting. Solaris is even worse. Technically ipfw appears to have stateful extensions, but it does them through "dynamic rules" and so people don't think it's stateful. We had an argument here about this a few weeks back. :-) > ACk. But as said, I don't care for them on FS level. FS isn't meant > to > be used as a DB, for that we got DBMS installed. And what if you want multiple MySQL/Postgres servers, writing to the same DB? > Not necessarily. I don't plan to share data among different systems > with different systems writing to it. Data should be saved on two or > more boxes, but only ONE boxes will have write access to it under > normal operation. If that box goes down, it's twin gets the write > rights and so on. And you think NFS is flaky? That sounds pretty dodgy to me as you're describing it, but it's your neck. > > For SQL stuff, we might get concerned if we're doing a lot of > > INSERTs and UPDATEs. > > For DBMS, the only solution I can think of is faster > hardware. Shared DBMS is a big mess. Over lunch, this came up in conversation, and the only real problem anybody could see was detecting dead-locks. Apart from that, it shouldn't be too difficult. > Use the proper MTA. qmail is written to be NFS safe (and despite, it > saves you to worry about the security of your mailservers since it > hasn't been ONE hole in 1.03!). All MTAs are NFS safe these days provding you have locking implemented. On FBSD, that won't be possible unless you're tracking -current. Otherwise, I bet I can break a qmail box in a cluster. Anyway, every admin with any sense is running Exim. > > It'd be nice to have, but it's hard. So, off to see what Gigabit > > cards FBSD is supporting now. :-) > > I'd rather want FreeBSD to support TCP/IP over firewire ;-) Ummmmm.... yeah. that sounds *great*. :-) > Simply don't do it. With MySQL, this cries for trouble (not to Which is why I want to try and fix it. Like I say, I'm doing this because I want to. If it's possible to get working, I personally believe that would be a useful contribution to the community. > mention > the immense performance penalty). If the DB *server* > isn't fast enough, use MySQL's realtime replication and redirect the > selects to a slave, if this isn't enough, get better hardware. But I > somehow doubt that a Athlon MP 1200 isn't fast enough for 95% of all > people out there. The rest probably runs Sun or IBM anyway. We come back to where we started. Replication is not a safe way to deal with atomic transactions, and therefore is useless in anything that is important to your business. MySQL *should*not* be looking after this. Lower-layer transports and architectures should be supporting it. Or at least, that's the way I'm progressing. > > To say file servers shouldn't have atomic locking raises the > > question as to why the hell qpopper puts locks in place. > > Badly written daemon? Because you need to lock spools against multiple popper's being invoked of multiple machines at the same time. If your network is a bit cloggy, last thing you want is more than 1 qopper process trying to fiddle with a user's spool. Transactional support, and particularly atomic action support is critical to the majority of application. It's just transparent to most people (as it should be). At the moment, daemons have to implement it in their own code. My argument is why NFS can't help it in a clustered setup. > Sure. But one can go great way without even needing them. And on low-load systems, you never will. Which is where those tiny figures come from. On the majority of systems, you'll be able to deliver maybe 5,000 mails a day without ever needing locking. But the odd mail will occasionally go missing. Been there, didn't buy the t-shirt because it was a horrid place to be. :-) > If it works, I can see it. And actually, I'm running MySQL in > replicated master/slave mode since the day the replication feature > got > stable enough for production. And I've got my doubts whether I would > want to rely on a multiple master setup with MySQL 3.23. Well, the tech I'm talking about is at a level where MySQL is the most likely to break it, but because I'm talking about FS level, it should benefit mail clusters and suchlike as well. > Sure I can. But I don't see why I should use locking there if my > mailserver was designed to work with NFS without locking. I thought you said qpopper was a badly written daemon? How do you think qmail does it if isn't using big, fat, expensive lock files? I'm guessing here, perhaps it's cluster safe using a different technique I'm not aware of, but the point is that with NFS level locking your daemon (whether it's an MTA or a UberWidget 2001 MultiVibrationAlert or whatever), doesn't need to worry about it. > Oh I see, you follow our business model (lots of cheap servers are > much better for your reliability than one expensive one). I just feel Better for the wallet as well. :-) > it > comes to an end when it comes to loaded DB servers as it's awfully > hard to have two boxes working on the same table. THAT'S MY POINT! THAT is EXACTLY what I want to work on. I want to try and work out what it would take (patching software, whatever, if need be) to make this a relatively trivial exercise. I know we're on -isp here, but this is exactly the sort of conversation we should be having on -cluster and trying to make it happen. > Oh and last but not least, MySQL is probably not the right choice if > you need bomb proof reliability anyway (IIRC, it still isn't ACID > even > with transaction support). I think the current transaction support in the beta relies on Berkley DB transaction support. -- 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