Multiple Datasync Mobility Pack server for redundancy?

Question

Would it be possible to have multiple Data Synchronizer Mobility Pack servers (behind a load balancer) service the same users/groups if I make sure all settings are the same on all servers and all users/groups are on all servers? If not, what option/s are available to provide failover / redundancy for this product?

Answer 1

Hi,
There are two entirely different things being discussed in this thread, one is scaling and the other is HA, survivability, DR, etc.
In terms of scaling, each newer version of DS supports more users than the prior releases, so you can comfortably get hundreds of users per DS server instance. The way to scale both in terms of users, or to optimize performance, is to add more server instances with a different fraction of your users provisions into each of them. So this does not drive the need for a load balancer or an active-active cluster of data sync servers. You have N servers each with 1/Nth of the accounts. If you want super-duper performance for certain people, prop up an instance just for them. Less people = faster response, mostly.
In terms of DR. If you have a virtualization infrastructure, just keep a recently cloned copy of the server handy. There is a process that can be used to force a resync of the users and that will "freshen" the missing messages that came in while the system is sleeping. AND use LDAP groups to provision users, rather than by hand. This means that during a recovery / rebuild situation you install DS fresh, point it at the LDAP group, sit back and watch it re-sync... No need to manually add 470 users. And don't forget about the features of your virtualization infrastructure, if the VM hardware dies, set the VM to migrate to another host. It will reboot and 3 minute later be moving mail again.
But in summary, there is no HA clustering of Data Sync ( yet - or ever - who knows? ) and you do not want to put a load balancer or use rotating DNS or other tricks to try to do that. If your desire is to reduce the impact of a physical server failure, then do that. Or put another way, if you are worried about a failure of the data sync server, and have no ability to get it back fast - what would you do for GroupWise itself?
If you have difficulty with the data sync services dying on you, that can be managed via scripting and cron jobs. You can use curl and a test account to determine the liveliness of the data sync services, and then stop and restart them - automatically. One implementation of this is the nagios activesync health check script. Alll you need do is change the version of ActiveSync requested to 2.5 rather than 12.0 or 14.0 and specify '' ( single quote, single quote ) as the domain on the command line. If it fails, then DS may be hosed up and may need restarting.
Barring a HW failure scenerio, this is usually as good as service migration on a cluster. We do this and while the data sync service have been very stable for us, when it does die, or we manually kill it, the system restart it in 2 minutes - and nobody notices or cares.
So I guess we need to know what scenario you are trying to hedge against?
-- Bob
So