Introduction to Front End pairing
The whole mechanism is based on the approach that Lync 2013 uses to manage the "presence" database (each Front End Server now controls the presence database) and on the Windows Fabric component, which is used to keep user data in sync on all the Front End servers. We will cover the Windows Fabric component later in this chapter.
When a pool hosting the Central Management Store (CMS) is paired with another pool, it creates a backup of the CMS and a Master/Standby relationship between the two database instances.
The aforementioned mechanism explains why, in Lync 2013, the dependency on the Back End Server has been "relaxed" (what happens is named lazy writes —the SQL Server database is updated mainly for the eventuality of a disaster recovery). To manage the new logic of the presence database, the algorithm used in Lync 2010 to determine where a user was homed (also if a failure occurred on one or more Front Ends) has been changed.
Now, we have Lync 2013 automatically creating the so-called user groups (a whole new concept), and distributing the users inside the aforementioned groups. An algorithm is used to select the server where users are homed and the membership in the groups. Each one of the user groups is tied to a primary, secondary, and tertiary Front End Server.
Note
The aforementioned logic based on a minimum of three Front End Servers is the reason why it is recommended to deploy a minimum of three servers in an Enterprise pool.
Deployment with a reduced number of Front End Servers is supported, and we will see only the primary Front End Server, or primary and secondary Front End Servers, for the user groups.
With a configuration such as the one we have just explained, in case of a Front End Server outage, the user groups that have that server as primary will fail over to the secondary server.
If the secondary is not available or fails (and the primary is still not working), the groups will fail over to the tertiary server. Any additional failover will require the election of another Front End, and the creation of a new user group for the users.
In the following screenshot, we see the failover process when two Front End Servers become unavailable:
- Users with a primary group on Front End 3 fail on their secondary group on Front End 1 as soon as Front End 3 is no longer available
- When Front End 2 becomes unavailable too, the users with a primary group located there will also fail to Front End 1
If we add more servers to the pool, the groups will be rebalanced to distribute the load on more nodes.
Note
If we need to know the user group assignment in a 2013 pool, we can use the Get-csuserpoolinfo –identity "user" cmdlet.
Such mechanisms require that we have an underlying service to replicate data between Front End Servers and maintaining up to three copies of the user data on the Front End Servers. Windows Fabric is a service installed during the server setup of Lync Server 2013, and is the technology on which we base the aforementioned synchronization.
The result of moving a part of the data from SQL to the Front End Servers is that we are able to maintain presence and contacts during a Back End service interruption.