Przemyslaw Wegrzyn wrote:

> Of course ! I considered several scenarios so far:
>  - using db-file driven delivery, like for example vmailmgr does, and
>    sharing that file over NFS together with maildirs
>   pros: easy to implement
>   cons: any changes to user database requires locking this file. I want to
>         avoid locking over NFS

And it's not likely to scale nicely.

>  - custom qmail-users and auth mdules which asks Postgres directly (no
>    matter what I choose for qmail, I need postgres database too)
>    The modification: custom proxy daemon on every server holding
>    persistent connection to database, to avoid postgres reauthentication
>    on every query

SQL databases are significantly slower than LDAP.

>  - using qmail-ldap - but I don't know yet anything about LDAP's
>    performance/scalability/replication
> 
>    not-this-list, but maybe someone will answer: how OpenLDAP handles
>    replication ? How it handles locking ? Does updating data requires
>    whole database lock ?

What you need to do is go off and learn all about LDAP and how it works
first - especially before implementing a system as big as the one you're
proposing. LDAP is specifically designed to be high performance, highly
scalable, and can replicate very well.

How LDAP replicates is all part of the LDAP protocol. Full featured LDAP
servers like OpenLDAP and iPlanet Directory server can replicate data
from master LDAP servers to many slave LDAP servers, having your entire
database served by multiple machines similtaneously. This is good
because if one of your servers goes down, others can take over. All of
this functionality is handled out the box, it just needs to be laid out
and configured correctly.

> Hmm, a friend of mine is using LDAP for his not so big mail/web server. He
> uses just nss/pam. He said recently that NSS performs poor on high load.

He isn't using LDAP - he's using NSS/PAM that gates through to an LDAP
backend, which is different.

qmail-ldap uses an LDAP server directly, which is significantly faster
and easier to configure. It's also more secure - as NSS effectively
gives people shell access if the right data is in the LDAP server (which
is the point behind NSS).

> Well, but, given the same hardware, some technology performs better, some
> worse.

This only comes into play when your machines are almost overloaded. An
LDAP server's typical use of system resources is pretty modest - you
just need to have enough RAM. You won't know until you test this though.

> I've just looked through qmail-ldap FAQ - I can see that its clustering
> support is done by assigning particular account to particular server. Will
> it balance well, if some accounts reciver large amount of mail, while
> others just one mail a week ?

Statistically as you get more mailboxes everything will even out. It is
statistically highly unlikely that one box will get fuller significantly
faster than another one - if it does, something is most likely wrong.

There are two ways to do load balancing though:

- Allocate mailboxes to specific servers, and have qmail do the delivery
through either clustering or normal relaying of mail.
- Allocate mailboxes out of one huge NFS tree, which is mounted on many
load balanced servers - every mailserver can just deliver the mail
locally, it doesn't matter which one does it - clustering is
unnecessary. This is how you've said you're going to do it (with NFS).

In short - ignore the stuff about clustering, you won't need it if you
use NFS.

Regards,
Graham
-- 
-----------------------------------------
[EMAIL PROTECTED]                "There's a moon
                                        over Bourbon Street
                                                tonight..."

S/MIME Cryptographic Signature

Reply via email to