Hi, Luis, William, Steve, Noel, Kurt, Andris and all others who
responded off-list,
many thanks for answering my mail. Apologies for my late reply, I've
been quite busy trying to pinpoint a mail server/storage problem, see below.
Steve wrote:
In this situation NFS is more of a delivery method than anything to do with
high availability, as it has no requirement to do any more than share a single
copy of the data.
Maybe a clustered file system - glusterfs for example - is what you're looking
for.
Correct, I used the term 'NFS' but what I meant to say was NFS to access
the message store, where the backend for this message store has a HA
architecture.
On 28-09-17 02:57, W Kern wrote:
We are huge GlusterFS fans. It is easy to setup, trivial to admin and
very reliable if you don't get too fancy. Biggest issue is 'growing'
it as you have to be precise in how you add additional bricks.
However, historically the small-file performance on Gluster has not
been very good, though they are working on it.
Thus a Maildir based system would not (yet) be a good fit on Gluster,
especially with lots of customers who leave tens of thousands of
individual messages in a particular Folder.
Other OpenSource 'white box' HA options are
1) Ceph
2) MooseFS/LizardFS
3) A big NFS server with DRBD as a failover.
Each of those would have its challenges as you get into the millions
of busy accounts stage, but there are work arounds for each.
The mail server for which I was looking for this storage solution has a
maildir based format. Actually, we used GlusterFS with the FUSE client
but got some serious problems with GlusterFS, where index files (and
some other files) got lost due to some problem in GFS. Redhat claimed
there was 'some client process' removing these files. But we were able
to reproduce the problem in a test environment and we could demonstrate
that the problem was solved, when replacing the FUSE client with the
plain vanilla NFS client that comes with Redhat (against the NFS
interface of GFS). However, GFS does not provide a HA NFS solution
without Ganesha and we didn't like to build another layer of complexity
on top of GFS to solve the problems in GFS. Hence my question on this
list. Redhat warned us that GFS is not ideal for handling lots of small
files (where they mentioned everything under 1 Mbyte as being small),
but we had to use GFS as that was the only HA shared storage service
available at this customer; no NAS was present nor any intention to
purchase a NAS for this purpose. But things may change now.
Noel Butler wrote:
FFS, do NOT use virtual machines :)
I think I fully agree with you :-) but as I need figures and facts I'd
like to ask you: can you elaborate on why not? Of course physical
hardware has major advantages re. speed etc., but as everything these
days get virtualized, virtualizing shared storage (as we did with GFS)
has it's advantages too (scaling, provisioning etc.)
Regards,
/rolf
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
