.png)
Back End Server High Availability
Topic Last Modified: 2013-03-12
To ensure high availability for your Back End Servers, you can deploy two Back End Servers for a single Front End pool, using synchronous SQL mirroring. This topology is optional, but is recommended to maintain your organization's business continuity. In the rest of this document, SQL mirroring means synchronous SQL mirroring, unless otherwise explicitly stated. Asynchronous SQL mirroring is not supported for Back End Server high availability in Lync Server 2013.
When you deploy this high availability solution, all Lync Server databases in the pool are mirrored, including the Central Management store, if it is located in this pool, as well as the Response Group application database and the Call Park application database, if those applications are running in the pool.
With SQL mirroring, you do not need to use shared storage for the servers. Each server keeps its copy of the databases in local storage.
You may choose to deploy SQL mirroring with or without a witness. We recommend using a witness because it enables failover of the Back End Server to be automatic. Otherwise, an administrator must manually invoke failover. Note that even if a witness is deployed, an administrator can manually invoke Back End Server failover, if necessary.
If you use a witness, you can use a single witness for multiple pairs of Back End Servers. There is no strict 1:1 correspondence between witnesses and pairs of Back End Servers. Deployments that use a single witness for multiple pairs of Back End Servers are not quite as resilient as topologies with a separate witness for each Back End Server pair.
For automatic Back End failover, the engineering target for recovery time objective (RTO) is 5 minutes. Because of the synchronous SQL mirroring, we do not anticipate data loss during Back End Server failures except in rare occasions when both the Front End Servers and the Back End Server go down simultaneously while data is being moved between the servers. The engineering target for recovery point objective (RPO) is 5 minutes.
User experience during a failure depends on the nature of the failure, and on your topology.
If you have a witness configured, and the principal fails, Back End Server failover happens automatically and quickly. Active users should not notice much interruption to their ongoing sessions.
If there is no witness configured, it will take some time for the administrator to manually invoke the failover. During that time, active users may be affected. They will continue their sessions as normal for about 30 minutes. If the primary is still not restored, or an administrator has not failed over to the backup, then users are switched to Resiliency mode, meaning that they are unable to perform tasks that require a persistent change on Lync Server (such as adding a contact).
If both the principal and the mirror Back End Servers fail, or if one of those servers and the witness fails, the Back End Server will become unavailable (even if it is the principal that is still working). In this case, active users are switched to Resiliency mode after some time.
SQL clustering topologies are not supported for new Lync Server 2013 deployments. For Back End Server high availability, SQL mirroring is the recommended and supported option.
If you are upgrading from a previous version of Lync Server and you have deployed an Enterprise Edition Front End pool that uses SQL clustering in that existing Lync Server topology, we recommend that you implement SQL Mirroring as a replacement for the existing SQL clustering deployment. However, continuing to use the existing SQL cluster with Lync Server 2013 is supported.
