Cyrus, clusters, GFS - HA yet again

Janne Peltonen janne.peltonen at helsinki.fi
Tue Oct 31 10:34:32 EST 2006


Hi!

Thanks for the good points about the benefits of a Murder setup.

On Mon, Oct 30, 2006 at 09:47:07AM -0500, Robert Banz wrote:
> On the other hand, there's some benefit to a "murder" style cluster  
> as well.  You've got multiple isolated systems, limiting your risk if  
> "something horrible" happens.

Very true. On the other hand, we are already trusting quite a lot on the
functionality of our SAN. (With redundat storage (far away from each
other), redundant data paths, long-term backups and whatnot.) Of course,
if the backend servers are separate as in a Murder, one server running
amok wouldn't corrupt all mailboxes... and we wouldn't have to rollback
to the previous backup with consistent spool areas for all mailboxes,
only those on the affected server.

> Then there are upgrades, especially if  
> they have database updates -- in a murder, you can do software  
> upgrades on 'chunks' of users' mailboxes at a time -- either by  
> "moving" users almost-live to an upgraded server, or taking only a  
> portion of your users offline for the task.

Another very good point. If a backend server communicates only via
standard protocols, it can be any version it wants to, internally.

Mm. Maybe I should follow Martin's lead and use MUPDATE to synchronize
dbs (instead of having them on shared storage). This raises other
questions, though: the shared storage is consistent "all the time", but
what abt mailbox lists? And other dbs? Martin?

> That's not saying the "true" cluster isn't totally cool and doesn't  
> have it's benefits. ;)

I gathered as much ;)

Another thing. We have really quite a lot of mailbox data. And terabytes
aren't that cheap on a SAN. And the SAN already gives us redundancy. So
application-level replication wouldn't seem that useful.


Thanks, all, for all the good advice.
--Janne


More information about the Info-cyrus mailing list