Lync Server 2013: Brick Model

The Microsoft Lync Server 2013 architecture has changed in a way that increases the hardware requirements for Front End servers going forward. Two words for you: Brick Model. The Lync Server 2013 Brick Model deployment is incorporated out of the box when you deploy Lync Server 2013 Enterprise Edition servers. This technology alone removes the need for back-end Microsoft SQL Server instances in your environment for presence, subscriptions, dynamic conferencing writes, and other transactions. Let's take a look at Lync's Front End server architecture for Lync 2010 and Lync 2013 and see how the Brick Model will assist with server performance and end-user feature availability with the Lync client going forward.

Lync Server 2010 Architecture

Lync Server 2010 Front End pool architecture was a centralized design with a SQL Server database back end doing a lot of heavy lifting for the Front End servers. Front End servers were required not only to handle the core workloads of Lync, such as IM/presence, application sharing, conferencing, and Enterprise Voice, but also were responsible for publishing users' current presence status for other users (known as publishing and subscribing of presence), subscriptions of contacts, and dynamic updates for conferences.

Each Lync Server Front End server was tightly coupled to the back end and in constant communication with the SQL Server database for presence updates and subscriptions, as well as all business logic. Figure 1 shows a sample Lync Server 2010 Front End server architecture. Table 1 shows Microsoft's hardware recommendations for Lync Server 2010.

Figure 1: Lync Server 2010 Front End server architecture

The tight coupling between the Front End server and the back end server as well as potential bottlenecks in areas such as high processor or I/O load led to many customers not leveraging virtualization and relying more on physical hardware for the Lync and SQL Server deployment. In addition, this architecture also contributed to the hard limit of Lync 2010 Front End servers in a pool to a maximum of 10 servers -- SQL Server is the bottleneck that prevents larger pools from being deployed that could otherwise contain over 100,000 users. In the end, the constraint was on SQL Server and not the Lync Front End servers.

Lync Server 2013 Brick Model Architecture

The Lync Server 2013 Front End pool architecture has moved to a Brick Model approach, where each Front End server contains the presence database that before resided on the SQL Server back end. In Lync Server 2010, the Front End servers communicate to the SQL Server back end to update users' presence status. If the SQL Server instance isn't sized adequately from a hardware point of view or network issues prevent or delay the Front End servers from communicating with the SQL Server back end, the result could be presence not updating in a timely manner or being unavailable for users.

The Lync 2013 Front End servers and back end database are now loosely coupled. As a result of this change in architecture, Front End servers now submit changes that are written to the SQL Server back end database in order to keep the database updated with processes that are taking place on the Lync Front End servers; this process is known as lazy writes. These lazy writes update the SQL Server database with any transactions or changes such as simultaneous ringing or call forwarding; this process is known in Lync 2013 as rehydration.

Moving responsibility for the presence database from the SQL Server back end to the Front End server is one factor in the increased hardware recommendations. This change has resulted in simpler requirements for the SQL Server back end, greater scalability of the Front End pool, and a much improved user experience for Front End server failover. Figure 2 shows a sample of Lync Server 2013 architecture, and Table 2 lists Microsoft's hardware recommendations.

Figure 2: Lync Server 2013 Front End server architecture

Brick Model architecture introduces two new concepts for Lync administrators: User Groups and quorums. Lync users are now partitioned into User Groups automatically, and each User Group is assigned to three Front End servers (primary, secondary, and tertiary). If you don’t have at least three Front End servers, User Groups are still created; however, you'll see just a primary or a primary and secondary. With three Front End servers being deployed, which is a Microsoft best practice, three copies of each user's data are stored on Front End servers through replication called Windows Fabric (a topic that I'll dedicate a separate article to). If you have fewer than three Front End servers in a pool, the number of data copies is reduced accordingly.

When you have fewer than three Front End servers in a pool, Lync 2013 pools must have a quorum in order to serve users. Therefore, there must be a minimum number of healthy servers before starting a Lync 2013 pool's services. Any Lync 2013 Front End server that is able to start Lync-related services is considered healthy for the purposes of quorum.

Final Thoughts

I have nothing but good things to say about the architecture changes in Lync Server 2013 that focus on the Front End servers and their relationship with the SQL Server back end. This change has been a long time coming. It takes stress and dependencies away from the SQL Server back end, particularly for some of the more dynamic end-user-facing features such as presence status. The fact that these improvements are available out of the box makes the enhancements that much better and worth the migration to Lync 2013.