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-boun...@redhat.com [mailto:linux-cluster-boun...@redhat.com] On Behalf Of jr Sent: Tuesday, October 27, 2009 3:45 AM To: linux clustering Subject: Re: [Linux-cluster] 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@redhat.com > https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@redhat.com https://www.redhat.com/mailman/listinfo/linux-cluster -- Linux-cluster mailing list Linux-cluster@redhat.com https://www.redhat.com/mailman/listinfo/linux-cluster
