Sounds nice, but it also appears if you lose a backend server, then half your users can't access their mailbox. With the 2/2b, the vip would float to a healthy node and mail would still be available, expect during that moment in time where it floats. What's the end users experience at that moment? Do you failback/not failback immediately (say it got fenced)? I guess it boils down to what's acceptable. -----Original Message----- From: linux-cluster-bounces@xxxxxxxxxx [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of jr Sent: Tuesday, October 27, 2009 3:45 AM To: linux clustering Subject: Re: High availability mail server The good news is that the Cyrus IMAP Server already has a solution for that, it's called "Murder" and "Aggregator": http://cyrusimap.web.cmu.edu/ag.html regards, Johannes > what about using a combination of 3 and 2b: > 3b- split your users in a set of servers which use ext3 FS but are part of a cluster, the servers are really services of a cluster (IP and FS are resources of a CLuster Service) so, if a server fail its service can be migrated to another node of the cluster > > let say for example > users starting with letter 'a' to users starting with letter 'h' will "assigned" to MailA , users from 'i' to 'z' will be assigned to MailB. > MAilA --> ipA and filesystemA > MAilB --> ipB and filesystemB > > Cluster ServiceA will have resource ipA and filesystemA > Cluster ServiceB will have resource ipB and filesystemB > > and ServiceA will be configured to run in nodeA, while ServiceB will be set to run in nodeB of the cluster, but will be set to failover to nodeC (standby server) > > the hard part of this is how to balance the users between MailA and MailB (and MailC , D, E). Changing the value of "mail_host" in user attr (if using a Directory Service) and moving user's email from one filesystem to another > > this is just food for the brain, the scenario could be as complex as you like :-), but definitely is no good idea to have GFS for mail servers if the clients can connected from multiple sources and dont have a "proxy" to tunnel all request for same user to same backend server. > > thanks > roger > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
