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 ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
