I'm going to guess that DBMail isn't yet ready for prime-time. It
doesn't appear to have the benefit (yet) of wide-spread exposure to
Enterprise-scale environments.
It's an approach I had been considering, as a possible solution to the
many issues I find myself facing with a "standard" configuration (which
is inevitably more complex).
I see problems with system load on the database server at high-peak --
without a plan to load balance, in whatever way, this could downspiral
quickly. No single point of failure is a goal I have for my design (as
much as possible).
It would be cool to have GMail's GFS for this project ;-) But I don't
see that happening anytime soon.. ;-)
There are other projects out there - like GFS from RedHat, open-sourced
-- which is more geared toward SAN. One of the goals of my design is to
keep it simple, if possible -- manageability is a desired end-result.
Thanks,
Forrest
Paul J Stevens wrote:
Forrest Aldrich wrote:
o IMAP sort and indexing - the load this would create on the system -
this is a major concern; could this be distributed amoungst different
databases to load-balance?
Sort and search is currently implemented in the database client
(dbmail-imapd), not serverside. This makes searching and sorting at
present very slow when it concerns many messages.
o Distributing the accounts evenly across the backend server(s) and
which filesystem to use
Dbmail doesn't use the filesystem for storage, just the database.
Dbmail currently only uses a single storage database. Using mysql's
replication with automatic fallover is easy, but running a
multi-master setup won't work due to possible overlap in generated
message id's.
o DBmail supports multiple databases - we need some load balancing
with reasonable tcp/ip cutoff points
to avoid any downspiral performance issues - no single point of
failure.
Well, there's been talk of using sqlrelay for something like that. But
at present the sqlrelay driver setup is on the wishlist only.
o Quotas - how granular is DBMail's quota - we'd like to offer x GB
of space per user, and aggregate that amoungst an offering of 8
mailboxes per "master account" - the logical approach to this?
Quota are per mailbox. There is no concept of groups in the code, only
an unused client_id field in the usertable.
o Capacity monitoring
Indeed, wouldn't a snmp driver be nice.
o Deliver to the DB immediately or to a temp mbox file, then to the
db upon login? Concerned about the load on the database server(s)
As said dbmail doesn't do filebased storage. That would directly
conflict with it's distributed nature: the dbmail frontend handling
the delivery may well be a very different machine from the one
handling the imap connect.
Are there any Enterprise-scale implementations of DBMail at this time?
Hmm, Ilja?
Sorry, but dbmail aint gmail just yet :-)
