[imp] High Availability / Load Balancing

[Dominic Ijichi]

Hi,

> I am already doing it with 3 servers.  The problem does come in with the sql
> server as being the single point of failure unless you are able to
> continuously
> sync the horde database over all servers in the pool of imp servers.  We use
> a
> single server not in the imp pool for the sql database.

correctamundo.  there's two ways you can think/go here:

1) why create a pool of frontend servers that just handle http/php?  mysql at
least has builtin replication that is good/solid/lightweight enough to justify
policy of having sql server on each http server.  if you have n=2 then you can
use bidirectional replication for true failover, if you have n+1 then choose
between a circular chain or master/multislave arrangement, the latter probably
needing some code to handle master downage.

2) why bother replicating the sql database when you've still got a single point
of failure on the imap server?  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!!).  so you put the sql db on the same server/tier
as the mailstore and accept two single points of failure, both catastrophic.

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 if
any service/server fails, the failure is isolated to a small chunk of users. 
noah silver also said this in a seperate reply and suggested using ldap to
determine the end server - I've tried this in the past by taking using the
mailHost attribute normally used for smtp delivery.

ok, that's 3.  i can't count.

> Lee wrote:
> 
> > The more i think about it, the more worried I get about the SQL sessions
> > implementation. Not only does it require an additional dependancy for
> > horde (we use ldap for prefs), but it more importantly introduces a
> > single point of failure. Ive been giving this some thought and I think I
> > have a far more elegant solutions. I'm not an expert on horde's APIs,
> > but the following seems like it should work:

much as I like LDAP, it is currently far less robust than SQL.  openldap
implementation is slow and buggy, although improving all the time, and
multimaster is not yet stable, hence even if you replicate the DIT for reading
(as you should really for each http frontend), you've still always got a single
point of failure for writing, as well as a performance bottleneck.  iplanet
handles multimaster and is extremely fast and robust, but commercial!

> > Get around the sessions problem:
> >
> > We use DNS round robins to distribute load equally based on DNS
> > sequentially resolving each of the servers in the round-robin. Although
> > this continuous round-robin is nice, we could approximate the same
> > distribution by choosing a server only once (when you first load
> > http://webmail.myorg.com). When a user then hits the target horde
> > implementation, horde would rely on the actual server name:
> > http://webmail1.myorg.com, http://webmail2.myorg.com, or
> > http://webmail3.myorg.com.

you cannot guarantee equal load distribution using RR DNS - although the
authoritative server usually circulates IPs sequentially, you've then got
recursive servers in the way of the end clients - hence unless you set very low
(ie 0) TTLs on the A records concerned the recursive DNS servers of large ISPs
are likely to skew the balance towards particular servers.  additionally,
different browsers handle multiple IPs differently - some of them used to just
take the first and ignore the rest - does anyone know how recent browsers handle RR?

what are you trying to say for your alternative?  are you saying the client hits
a frontend server which then chooses another frontend at random and throws the
client that way?  (in which case you've still got a single point of failure on
the front)

to provide true load balancing, you could potentially emulate the work proper
load balancers do, by using DNS RR to vaguely spread out the initial queries,
then each frontend then has a second round of RR (similar to what I think you've
suggested above) by doing a load/user test of each server and redirecting to the
least used, or by using weights or somesuch.  possibly session stickiness could
be also implemented somehow along the way.

> > Get around the attachments problem:
> >
> > Theoretically, when a user adds an attachment (uploads it), horde could
> > create an array called attachments[1] = "path/to/file/uploaded" (like
> > wise for a 2nd, 3rd etc... attachments). When the use then clicks the
> > send button, the send funtion(s) try to attach the files that are store
> > on the server. If the files are not there, horde just uses its
> > attachments array to re-upload the files and attach them.

?? so you've got quite a good chance the client has to upload attachments again,
unnecessarily?  I'm sure people uploading xMb attachments over dialup would take
issue with that!

dom

> > I'm really not an expert on horde's APIs, but the above seems like it
> > should both be easy to implement and provide for 100% load balancing
> > capability. If you guys agree, I might start taking a stab at
> > implementing it this week.
> >
> > Sincerely,
> > Lee
> >
> >
> > On Sunday, December 15, 2002, at 11:01 AM, Chuck Hagenbuch wrote:
> >
> >> Quoting Dominic Ijichi <dom@ijichi.org>:
> >>
> >>> auto_prepend_file = "/opt/data/htdocs/sessionlib/adodb-session.php"
> >>
> >>
> >> FYI, you'll probably get better performance using Horde's SQL session
> >> handler implementation; as it is, you're loading *two* database
> >> abstraction
> >> libraries all the time...
> >>
> >> -chuck
> >>
> >> --
> >> Charles Hagenbuch, <chuck@horde.org>
> >> "People ask me all the time what it will be like living without otters."
> >>  - Google, thanks to Harpers
> >>
> >> --
> >> IMP mailing list
> >> Frequently Asked Questions: http://horde.org/faq/
> >> To unsubscribe, mail: imp-unsubscribe@lists.horde.org
> >
> >
> >
> 
> 
> --
> Robert Sand.
> mailto:rsand@d.umn.edu
> University of Minnesota, Duluth
> Information Technology Systems and Services
> 144 MWAH
> 218-726-6122        fax 218-726-7674
> 
> "Walk behind me I may not lead, Walk in front of me I may not follow,
>   Walk beside me and we walk together"  UTE Tribal proverb.
> 
> 
> --
> IMP mailing list
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: imp-unsubscribe@lists.horde.org


------------------------------------------
This message was penned by the hand of Dom