Some thoughts moving DBMail from SMB to E.
Think of *input* load balancing and failover as a job to be handled by the
MTA. Postfix for one is abundantly capable in this.
The *post office* side of things is handled just like any other post office
setup. Distribute.
Millions mailboxes (mailboxes not users):
Multiple connections on IMAP and POP3 (only offer IMAP on a special request
basis) I handle with multiple front-end servers, even on different subnets
but connected to the same back end. I have tried different permutations of
circular replication of MySQL and found I liked better a quasi file-server
architecture -- huge db server on a fast pipe -- to each his own. I took a
page from my school's Beowulf experience and used Tyan/Intel MPX technology
with AMD SMP2800 CPUs for clusters. When the better Opteron 64s came along I
tested them and there was only a modest connection handling speed gain but
with the 8-way 64-bit CPUs and huge memory management capability (tried
40gig) there was a significantly larger connection throughput over the
powerful 32bit cluster -- very good. We ran some quick tests on a Sun Fire
server which was destined for other purposes and it was amazing. Here's my
trick to handling mass connections == no back-end connection ever waits &&
always store and forward somewere no matter what so that if a connection
fails, your threads don't break, go linear, push infinitely into swap and
lose every d*** thing :o).
Some people like SQL proxies but without underlying security issues I have
yet to find a supporting cause; but someday might. It's a matter of
architecture preference.
With IMAP the actual database size never gets as big as we once thought it
would back in 2003 when Gig-per-user storage emerged -- the user acceptance
never materialized. Even though the end user is given the space, only a tiny
percentage actually use it. Instead of using mail as MP3/digital picture
storage, it seems people might be storing their stuff on thumb/stick drives,
in their cameras, and in their music appliances however you call them
wherever you are.
Another thing we have done is split off exceptional virtual domains to their
own smaller RDBMS server and DBMail front end as they grew. This has been
done to future-proof entities showing outgrowth potential. That concept may
not suit your situation but does point to an available predetermined
alternate plan of scaling.
You might inquire of anyone having a million mailboxes on a PostgreSQL
setup. I once used a PostgreSQL system to interimly store a major system's
mail and it was unbelievably fast, robust and scalable -- the bigger it got
the better it got. Once stabilized, a PostgreSQL option might be a stron
contender depending on you corporate inventory of RDBMS skills. I have a
number of small systems on PostgreSQL and a suspicion that pgsql is the
candidate for a big leap from SMB to E. (Small-Medium-Business to
Enterprise)
Anyway, I use Redhat Enterprise for some things too and suggest you *hand
build* everything related to your mail system. Build up everything
mail-related outside of the RedHat regime and let the Update Regime support
the OS only. Then it can be a good front end.
best...
Mike
----- Original Message -----
From: "Paul J Stevens" <[EMAIL PROTECTED]>
To: "DBMail mailinglist" <[email protected]>
Sent: Monday, January 09, 2006 3:56 AM
Subject: Re: [Dbmail] DBmail & Redhat AS
Dbmail will run on pretty much any platform that supports GCC,
autotools, and libtool. So yes, redhat whatever is/should be supported
without any trouble.
Loadbalancing is more tricky. There are two main bottlenecks in the
current setup:
- concurrent connections; the total sum of running dbmail processes and
hence concurrent client connections is determined by the sum of
connections your database cluster will support. There is at present no
mechanism for connection pooling. This is planned for the 2.3
developement cycle.
- multi-master sql backend replication; the size of your database
cluster is limited by the fact that limitations in the imap protocol
will not allow multi-master replication out-of-the box. Insertion of new
messages will have to be done in order of arrival acros the whole
installation. The algorithme to remedy this has been discussed in depth,
but implementation is not planned at the moment.
Both issues are documented on the wiki pages.
Probably the best route for scalability and loadbalancing is by
distribution of mailboxes accros several database clusters, and by
redirecting imap clients to the correct cluster by using imapproxy.
Of course, insertion will also have to be redirected and shared
mailboxes are limited to a single database cluster.
Fatemeh Taj wrote:
Hi dear All
I am looking for a database driven mailserver for a
big environment which will serve webhosting service
and would have more than 5 millions of mailboxes in
future. As I found out DBmail supports virtual
domains. My question is that if DBmail works with
Redhat AS 4 edition. Also if I can implement a load
balancing scenario and have a horizontal scale out for
this email service with dbmail.
Any idea is appriciated in advance
Fatemeh T.
__________________________________________
Yahoo! DSL – Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
