Re: slurpd vs single data store

[David Wright <ichbin@shadlen.org>]

> I am debating whether to use slurpd to replicate a
> database for redundancy or to run two openLDAP server
> machines, both sharing a mount on the NFS to the same
> data store directory.  Are there known problems with
> doing this?  I would prefer to share the same data
> with both servers through the NFS, but I wonder if
> they will have problems locking files and crashing
> into each other.

Do not do this. You will have problems locking files and crashes.

Because NFS cannot do reliable locking, it is a very bad choice whenever
data is being repidly manipulated by many simultaneous processes. Mail
spools, database storage, anything like that does not mix with NFS.

Even if you used a network filesystem with relaible locking, you should
not do what you describe, because slapd stores information in memory as
well as on the disk, and makes assumptions that the data agree. That is to
say, slapd assumes that another process has not gone and messed with what
is on the disk without telling it. You proposed architecture violates that
assumption.

Even if slapd had been designed to allow what you want, it would still be
a bad idea, because your architecture has two slapd processes sharing the
same storage. That storage is then a single point of failure, as well as a
performance bottleneck. Disk failure is probably the most common mode of
hardware failure (after tripping over the power cord).


If you need performance, just use replication.

If you need reliability for pam-ldap and nss-ldap, just use replication.

If you need reliability for all applications, use a heartbeat failover
system with IP takeover and shared SCSI RAID storage. Very pricey, though.