Front End Pool Architecture

In Skype for Business Server 2015, the architecture for Enterprise Edition front-end pools has changed to a distributed systems architecture.

In previous versions of Lync Server, the back-end SQL database was the real-time data store. While this provided a central location for pool members to utilize, it also became a performance bottleneck. In Skype for Business Server 2015, information about a particular user is kept on local SQL instances on the front-end servers (up to three)—one is the Master, and the other two are Replicas.

The Fabric Manager automatically distributes the load across the front-end servers in the pool, improving performance and scalability in the pool, and eliminating a single back-end SQL instance as a single point of failure.

Skype for Business Server 2015 Brick Model Approach

In previous versions, the back-end database was always a bottleneck that prevented more users on a single pool, and more servers per pool. From Lync 2013, the dependency between the pool and the back end is less strict: the front-end servers are managing user states between each other. There are only lazy writes to the back end, which are required to rehydrate a pool (after a pool was shut down completely), and disaster recovery.

User states are copied between the front-end servers in a pool, directly. Each user belongs to a specific user group, and a three-server peer pool holds a copy of the data of each user group. If one of the servers is not online anymore, the secondary (or tertiary) server will automatically take over for this user group.

To always have at least one server per user group available, you require a minimum quorum per pool. This is described later.

Deploying Enterprise Edition Pools

In Skype for Business Server 2015, the recommendation is to deploy a minimum of three front-end servers in a pool. When two servers are involved, the preference is to install two Standard Edition pools, and pair them together, rather than building a front-end pool with only two front-end servers. If such a pool is deployed, use the following guidelines:

  • If one front-end server fails, you should try to recover the failed server as soon as you can. Similarly, if you need to upgrade one of the two servers, bring it back online as soon as the upgrade is completed.
  • If you need to stop both servers at the same time, do the following when the downtime for the pool is finished:
  • The best practice is to restart both front-end servers at the same time.
  • If the two servers cannot be restarted at the same time, you should re-start them in the reverse order of the order in which they were stopped.
  • If you cannot re-start them in that order, run the following cmdlet before starting the pool.

Reset -CsPoolRegistrarState -ResetTypeQuorumLossRecovery -PoolFQDN <FQDN>

Pool Management

When deploying a front-end pool, it is critical that a minimum number of front-end servers are up and running, to ensure that the pool is functional. The following table shows the details of pool size, and the minimum running servers for the pool to be functional.

Total number of front-end servers in the pool / Number of servers that must be running for the pool to be functional
1–2 / 1
3–4 / 2
5–6 / 3
7–8 / 4
9–10 / 5
11–12 / 6

If the number of servers running falls below the functional level as shown in the preceding table, the remaining servers in the pool go into survivability mode, and you will see the following message in the event log: “Local Pool Manager has been disconnected from Pool Fabric Manager. (Id: 32163)”. After five minutes, if the number of running servers is still below the threshold level, the remaining servers in the pool will stop all Skype for Business Server services, and the following messages will appear in the event log: “Pool Manager failed to connect to Fabric Pool Manager (id: 32170) Server is being shut down because fabric pool manager could not be initialized (id: 32173)”.

If servers are added to, or removed from the pool configuration in Topology Builder, and then published successfully, the existing front-end servers must be restarted.

The recommendation is to restart the servers one at a time. In the unlikely event that the entire pool was offline when the configuration change occurred, you will need to run the following cmdlet.

Reset-CsPoolRegistrarState -PoolFQDNPoolFQDN> -ResetTypeServiceReset