Chapter 2. Understanding Front End Pool Pairing
In this chapter we will talk about Front End pool pairing, a new form of continuity introduced by Lync 2013. This solution is really important in order to go beyond a few limits that were present in previous solutions for high availability and disaster recovery. The aforementioned are critical aspects of a Lync deployment, especially if we are offering Enterprise Voice services.
In Lync 2010, we had high availability with Enterprise pools (so that it was possible to have up to 10 Front End Servers tied together), and a clustered SQL database as Lync Back End. In the preceding scenario, often a weak point was the SQL 2008 cluster, which is clearly a bottleneck from a continuity point of view, requiring a shared storage and posing a heavy limit to geographically dispersed solutions.
A basic form of disaster recovery was named Backup Registrar, and was based on the "pairing" of one or more Enterprise Edition pools / Standard Edition servers with another Enterprise pool / Standard Edition server installed on a different Lync site. The features made available to a user homed on a failed pool (or a Standard Edition server) were limited to Enterprise Voice (not all the services were available anyway), and a limited subset of other services, such as intra-site instant messaging (IM) and audio/video (A/V).
Note
The aforementioned settings require an introduction to the concept of a site. In Lync, a site is a logical object created through the Topology Builder. We may consider a Lync site as a set of Lync servers linked with a high-speed data connection (LAN or campus with a fiber optic connection) and low latency (with a maximum around 150 milliseconds end to end). Please remember that there is no direct association with other logical objects used by other Microsoft software that have the same name, such as the sites used by Active Directory.