Alex Borges wrote:
While youre considering proprietary solutions and naturally, would like
to pay for them, perhaps you should consider redhat's GFS thingie. Its
GPL but redhat offers it with their AS for an extra $$
Ive seen it work and it seems like quite a scalable solution and
tipically cheaper than buying a SAN.
We have GFS (6.0).
Its performance is mediocre - and horrible for some things (like doing
du(1) on a GFS-directory)
Also, I hate generating (well, trying to) packages for RHEL, where I
could use the FreeBSD-port and have all the necessary patches and tuning
included. Of the 1400 or so RPMs delivered by RHEL, I can barely use a
handful for my toasters (some libraries, maybe).
IMO, RHEL et.al. don't make any sense at all for this type of work.
You're paying to have a supported linux-kernel + sshd updated regularly
(because that's all that is left of the original after 5 years). And
you've got more work adapting your software to your OS than elsewhere.
Just try to get an equally modularized PHP4 or PHP5-RPM for RHEL that
has support for as many modules as the FreeBSD-port.
However, sans do offer plenty advantages on some environments (wann have
the winboxes and linboxes scsi-plugged into the same san), if this is
just for email, this can be a cheaper solution.
We have a SAN (HP EVA 3000 with 6 TB raw cap.), it's nice.
But it costs a lot of money all together (HBAs, FC-switches, FC-ports,
cables etc.pp.) and my gut-feeling is that I can deliver the same
performance and scalability (or even much more, in our case) with about
the same level of reliability when going with a "high-end" NAS - and
even save money in the end.
Also, email is not "just email" unfortunately.
Left without their email, our customers would just go to another ISP...
With this kind of thing, what you get to do is plug three or more boxes
with whatever storage they have and then store on all of them. This
thing works with LVM2 so you can partition, snapshot and share it to
your hearts content. Put a solid GB net on it with separate NICS (from
the NICS youll be using to actually provide service) for best results.
That's the theory, yes.
In pratice, though, it seems that GFS6.0 (no tests with 6.1, yet) is not
suitable for workloads where a lot of transactions occur in one
directory (like mail-delivery).
It creates a lock-file, everytime a file is changed in a maildir,
doubling (at least) the I/Os of maildir-maildelivery).
That's useless in this case because IMO qmail itself takes care that no
locking-issues are race-conditions occur.
cheers,
Rainer
