Date: Wed, 25 Jul 2001 15:17:45 +0100 From: Paul Robinson <paul@akita.co.uk> To: Gabriel Ambuehl <gabriel_ambuehl@buz.ch> Cc: freebsd-isp@freebsd.org Subject: Re: Redundant setup on a budget?? Message-ID: <20010725151745.A36223@jake.akitanet.co.uk> In-Reply-To: <2411019395.20010725142313@buz.ch>; from gabriel_ambuehl@buz.ch on Wed, Jul 25, 2001 at 02:23:13PM %2B0200 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 25, Gabriel Ambuehl <gabriel_ambuehl@buz.ch> 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. </flambait>
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010725151745.A36223>