[imp] High Availability / Load Balancing

[Dominic Ijichi]

Quoting Eric Rostetter <eric.rostetter@physics.utexas.edu>:

> > 2) why bother replicating the sql database when you've still got a single
> > point of failure on the imap server?
> 
> Because you use Horde, not just IMP, and unless you are doing imap-based
> authentication, then there is no reason the imap server should take down
> nag, kronolith, gollem, etc.

ah yes.  good point!
 
> Or, because you have a redundent imap server setup?
> 
> > mailstore is notoriously difficult to replicate
> > in realtime good enough to have a hot failover (if anyone does this
> > successfully, PLEASE speak up and share!!).
> 
> Shared scsi-devices on a cluster.  Only way to go.  Works great.  Been in
> OpenVMS for years, in Tru64 unix, available but rather experimental for
> linux.

doesn't this require physical sharing?  will it go over a network?  i spread
servers over networks and datacentres for redundancy - i've found that ISPs tend
to go bust more frequently than my hard disks!  i appreciate in a
university/large corporate environment nice hardware is the way to go, but i
certainly can't afford that and I suspect a lot of people will run horde/imap
out of colo/hosted.
 
> Can also used shared scsi in a failover setup. That is rather well supported
> in linux (compared to shared access).
> 
> > 3) why bother with replication redundancy?!  split your users -
> > alphabetically/by domain for small installs, hash for larger installs - and
> > have seperate servers for each chunk of users that have an entire
> > mailstore/sql/ldap/php/http install and are self-sufficient.  then at least
> 
> Possible (but makes it harder to maintain users -- think renames for example)
> and maybe harder to track down user problems, keep both machines uptodate,
> etc.  But certainly doable.
> 
> > any service/server fails, the failure is isolated to a small chunk of
> users.
> 
> And how is it better if 1/nth of my users can't get access than if all of
> them
> can't?  1/nth is still a large number of complaints.  The general idea is to
> avoid any downtime, not to limit the number of users who see the downtime.

if you're an isp, for instance with a million users, i'd definitely prefer to
only have a small chunk of them go wrong than the whole lot at one time, both
for reputation and the help desk's sake - if you're well setup you could
probably cope with complaints from a portion of 50,000 users, but a million
irate customers suddenly bearing down would flatten anyone.  granted, if you're
really serious about avoiding downtime you would then put redundancy each chunk.
 it was just an idea.

dom