Mindlink operation guide
Here we discuss failover strategies for each tier in the MindLink stack, in terms of complete failure of an entire pool in an active/passive DR configuration.
MindLink (Anywhere, SharePoint, Mobile)
In an active/passive DR deployment, the MindLink Server is deployed with an identical standby pool in another location. In the event of failover of the primary pool, requests from user devices and browsers should be directed to the standby pool.
The configuration of the two pools should be equivalent. For Anywhere, SharePoint and Mobile there is no data that needs to be synchronized between pools.
For the API, the provisioned data files (Agents.xml, Users.xml and Throttle.xml) should be periodically copied between sites. A scheduled copy job is sufficient to copy the files between the installation directories of each pool.
The frequency at which this synchronization occurs depends on how frequently changes are made to the provisioned agents, channels, users and throttles. If regular changes are made, synchronization should occur at least once per day.
Scenario: The MindLink pool becomes unavailable
- Administrative actions: - Redirect client requests to the new pool. - This can be achieved via DNS, load balancer configuration, or otherwise. - The load balanced pool name should be redirected to connect to the new pool. - For mobile, the individual names of each server should also be redirected to their equivalent nodes on the failover pool. - Anywhere/SharePoint user experience: - The user will be notified that they have been disconnected from their session and reconnection will be attempted. - After failure to reconnect for longer than the configured session timeout interval, the user will be instructed to re-logon. - If connections are redirected to the failover pool within the session timeout interval, then the user will be instructed to re-logon immediately. - When connections have been redirected to the failover pool, users will be able to re-logon. - Mobile user experience: - The user will be notified that they have become disconnected. - The app will continue to attempt to reconnect periodically. - The user may close and restart the app, at which point they will be given the choice to continue attempting reconnection to their old session or to re-logon. - When connections have been redirected to the new pool, the user will be immediately informed that their session ended and instructed to re-logon. - Failback - Connections should be redirected to the primary pool. - Users will be notified immediately that their session has ended and they should re-logon.