[prev in list] [next in list] [prev in thread] [next in thread] 

List:       info-cyrus
Subject:    RE: [POLL] virtual domains and Murder
From:       Rob Siemborski <rjs3 () andrew ! cmu ! edu>
Date:       2002-07-25 5:50:47
[Download RAW message or body]

On Thu, 25 Jul 2002, Jon Benson wrote:

> adds another package to the mix.  Playing with DNS is quite simply not at
> all reliable for either load balancing or failover.

If you assume that each domain lives on a single backend (not required at
this point, but not completely unreasonable from a management
perspective), than your loadbalancing is roughly the same as having an
imap.domainname.com point at that particular backend.  The failure mode
that would deny availability (that is, the backend goes down) is the
same-- those mailboxes are inaccessible.

I will note that the potential for automated online moves can be a win,
however.

> As I see it, and maybe I'm wrong, Murder provides a solid basis for
> distributing load amongst servers.  Not to mention, with relatively few
> alterations, limited support for failover.

There are other ways of distributing load to multiple IMAP servers
however (see above about the on-line moves).

The only failover support that exists is for frontends, if a backend falls
out of the murder, all of its mailboxes are off-line until it is restored
to service.  Cyrus High-Availability is not something we've even started
to think about seriously yet (and probably won't without a decent heap of
cash ;)

> > So why do people want the added overhead of maintaining a
> > murder, if the
>
> What added overhead?  Apart from the extra hardware and initial setup it all
> seemed fairly straight forward to me.  Ie our admin system (web/SQL driven)
> creates a mailbox on a backend server by calling various scripts and the
> frontend gets told about it via Murder so that users can then connect via
> it.

Yes, we've worked to make it as similar to a regular IMAP server as
possible (I'm glad you find it straightforward ;).  And day-to-day
administration is generally not significantly more difficult than with a
single server (though upgrades and tuning can of course now
take O(servers) time instead of O(1)).

I'm more worried about admin headaches when things go wrong.  Some of the
failure modes of the murder can look pretty strange to clients (for
example, there are cases where we respond with a NO to an LSUB, not
because the user lacks subscriptions, but because we can't contact the
backend server with their INBOX), and thus can be harder to diagnose then
your traditional imap server.

Additionally, users can find it confusing to get a successful imap
connection and then not be able to read their mail.

Finally, a failed mailbox move currently means a good amount of tedious
by-hand reconstruction.  They are pretty rare, however (we've been doing
bulk moves, and I've been seeing maybe 1 failure in 600 inbox moves.
That translates to about 1 failure per 6000-7000 mailboxes, so they are
relatively rare).  Obviously further development will improve the
administrative tools and the reliability of moves, but I don't see any
revolutionary improvements in the near future ;)

> NOTE: I only have a test setup of Cyrus (as in setup yesterday) and I've
> only read the documentation on Murder so maybe I'm missing a lot.

Well, since the Murder software only became fully functional relatively
recently, we're all sort of new at this.  Though you may be surprised at
just how far you can push Cyrus on a well-tuned single machine before
things start to fall over.

> Maybe I'm way off track but hopefully that's something I'll discover and
> rectify during the coming weeks.  :)

I actually don't think you're too off track.  As I said, I was mostly
wondering what the killer feature was that people were looking for... I'm
guessing at this point it is the online mailbox moves, which is the only
immediate advantage I can see over DNS pointers to a specific backend.

Thanks for your response,

-Rob

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


[prev in list] [next in list] [prev in thread] [next in thread]