Highly available and scalable Cyrus configurations

Ben Carter cecropia+ at pitt.edu
Tue Oct 7 19:44:55 EDT 2003



--On Tuesday, October 07, 2003 6:43 PM -0400 Rob Siemborski 
<rjs3 at andrew.cmu.edu> wrote:r

> On Tue, 7 Oct 2003, Ben Carter wrote:
>
>> and an MTA on each cluster member, because with the murder
>> configuration, you probably have to end up with a load-balancing switch
>> in front of murder front-end machines which in turn are in front of the
>
> This is not the case.  Simple DNS round-robining is sufficient.
>

How is simple DNS round-robin sufficient?  More than one MUA caches the DNS 
lookups for its mail servers.  I know that at least one version of 
Netscape Communicator used to.  It probably still does.  Also, some webmail 
clients do.  So if a front-end is down or has not network connectivity, one 
gets hung MUAs.

>> design, backend machines would have to be clustered anyway (2-node
>> clusters probably) to eliminate the back-end machines as SPOFs.
>
> Well, the aggregator isn't solving the HA problem.  It is doing its best
> to mitigate it however (via partial failure modes).
>

I know.  The aggregator is better for us for at least one other reason: we 
can use our existing SCSI storage arrays.  Veritas does not support 
clustering with SCSI (changing the host SCSI initiator IDs to be different).

>> And my second question is: is there something I'm missing with regard to
>> the Veritas cluster being a much simpler configuration to troubleshoot
>> and operate and a much stronger configuration in terms of availability?
>
> Well its simpler unless it breaks or has poor performance.
>

OK.  I thought so.

> I'm not familiar with the Veritas cluster (we have had good experience
> with vxfs on our backends however).  You also probably want to be sure
> you're not replaceing one single point of failure (a backend) with another
> (the cluster).
>
> The key about the usability of the filesystem is that file locks need to
> be obeyed throughout the entire cluster, and mmap() needs to be efficient
> (and able to deal with read()  and write() being called on that file at
> the same time).
>

That the locking needs to work is clear.  I did not think of the mmap() vs 
read/write issues.  Thanks.

> Also, the murder does get you one performance advantage that the veritas
> cluster (even correctly implemented) does not: it provides a large number
> of read-only copies of the mailbox list that clients can use for LIST
> operations, and not interfere with updates of the master copy.  With the
> size of mailbox lists on systems that are considering HA options, or
> moving to an aggregator configuration, this is, in fact, a serious concern
> to think about.
>

That's another good point.  However, is this still an issue if one does not 
select the flat file format for the mailboxes file?

Has anyone implemented Cyrus IMAP with any type of clustering softwarethat 
you know of?

Thanks,

Ben

> -Rob
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
> Research Systems Programmer * /usr/contributed Gatekeeper
>

Ben Carter
Computing Services & System Development
University of Pittsburgh
bhc at pitt.edu
412-624-6470




More information about the Info-cyrus mailing list