Replication design, configuration, and bandwidth

[Anthony Chavez]

Hello, info-cyrus!

I administer a network consisting of 8 nodes that are physically
separated over long distances.  Each of the 7 slave nodes is connected
to the master node via a VPN tunnel that flows over the global
Internet.

We are investigating mechanisms to provide high availability IMAP on
the slave nodes, and found Cyrus imapd's "rolling" replication to be a
good fit for this, based solely on the claims made in Cyrus'
documentation (we have not experimented yet).  Our primary goal is the
ability for users on slave nodes to access their mailstores if the
master node is down, with a secondary goal of failover for inbound
SMTP.

The design we have seems straightforward: enable inbound SMTP to be
delivered to the local (replicated) backend on each node (which is
then propaged to the master and/or other repicas).

One alternative to this design would be to only replicate the backend
on a subset of the nodes and just deploy frontends on the rest.

We are certainly open to other designs, but this is all that we've
come up with so far, and we're interested to know if anyone has
successfully implemented either of these designs.

We're also interested in knowing exactly how to configure replication
for multiple backends.  So far, we've only been able to come up with
{cyrus,imapd}.conf settings for 2 node replication.

We are operating under the assumption that replication in such a
scenario would require k*(n-1) times the bandwidth that the original
delivery required, where k is a compression factor and n is the total
number of replicas.  We've only scratched the surface on verifying
this, but I thought I'd take the opportunity to see if anyone more
familiar with this sort of deployment (or the source code) could
verify this.  Bandwidth is a big concern, since most of these nodes
are using T1s.

FWIW, we are aware of the potential problems with backup MXes, and to
combat this, spam filtering would be enforced on these backup MXes,
and since our LDAP DIT is replicated to each node, rejecting mail to
nonexistent recipients would be a possibility.

Thanks! ;-)

-- 
Anthony Chavez                                 http://anthonychavez.org/
mailto:acc at anthonychavez.org         jabber:acc at jabber.anthonychavez.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20070411/91159f85/attachment.bin