Sunday, June 23, 2013

Lync Server 2013 architecture -Brick Model

We all know Lync Server Front End servers (FE)/Pool used SQL server for the Backend (BE) database to store the user’s contacts lists, presence information and conferencing  data including persistent data about the state of all current conferences and conference scheduling data whilst FE server provided core functionality such as instant Messaging (IM), Web conferencing, application sharing etc.
Lync Server 2010 FE pool architecture was a centralized design with a SQL server’s database back end doing a lot of handle the core workloads of Lync. Each Lync Server FE 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.
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.  An also there is some limitation of this architecture the hard limit of  Lync Server 2010 FE servers in a pool to maximum of 10 servers.

Lync Server 2013 FE Architecture

It was just a matter of time that Microsoft released Lync Server 2013 where the Brick Model architecture of Lync server 2013 comes in to play. The Lync 2013 Front End servers and back end database are now loosely coupled. Lync FE now has given the responsibility of keeping the presence information and other changes within themselves. These changes are written back to the BE database, the process commonly 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. The everything that follows is why hardware requirement for Lync 2013 FE servers spiked. This change has resulted in simpler requirement for the SQL server back end, greater scalability of the FE pool and a much improved user experience for FE server failover.
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 will 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 use’s data are stored on FE server through replication called Windows Fabric. If fewer than three Front End servers in a pool, the number of data copies is reduced accordingly.
When you have fewer than three FE 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 FE servers that are able to start Lync related services are considered healthy for the purposes of quorum.

If any of the FE server fail or taken offline, the user group whose primary copy was stored on machine is failed over to the server that hosts the user groups’ secondary copy and so on.  In the event that all the severs which hosted primary, secondary and tertiary copy of a use group fails, Windows fabric checks for another FE server within the pool. If it finds one, it creates a new user group by retrieving information from the BE SQL database and assigns the users to the new user group.

Do I need 3 servers in a FE pool?

Ideally, yes – to complete the windows fabric cluster architecture of 3 copies of the same database.
As you might have guessed already, three is the magic number – one primary copy and 2 replicas. This is the exact same model we see everywhere – for e.g. SQL Azure, Exchange DAG.

Can I have a Front End pool with 2 servers?

Yes you can, though Microsoft never recommends it. A Front End pool with 2 servers will work perfectly fine, but you remember the following
 1. You have only one replica of the database (primary and secondary) and thus do not satisfy the underlying windows fabric model of 3 database copies.
2. The pool will continue to function normally if only a single server is restarted at any one time.

Even better – can I have a Front End pool with just 1 server?

Yes you can though not recommend as you will have to run the Reset-CsPoolRegistrarState every time you restart the server. This is because, during every restart, the quorum will inform the server that there are no secondary databases available and will then shut down services. But once services are up and running, it will continue to run until the next restart.
Other than getting one foot in the Enterprise Pool world, there is no advantage what so ever in running a single server EE pool and hence a better suggestion / option is to install a standard edition server instead.

No comments:

Post a Comment