<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

How to Achieve High Availability With Small Lync Pools

microsoft exchange 20132 Since the release of Lync 2013 I have been dealing with customers who fall under a certain amount of seats (for simplicity reasons let’s call it 1000 users) and still continue to today. In Lync 2010 designing a small pool with two front end servers for high availability was much easier because it was a supported design by Microsoft. However, this has now changed with Lync 2013 (which I will describe later on).
During the 2014 Lync Conference I attended the session, “Planning for virtualizing Lync 2013” and noticed the trend in people struggling to present their customers with a descent solution.
Therefore the answer to what the best practices for Lync pools with a small amount of users are all while ensuring high availability is… well, it depends…
Let’s take a look at the facts for designing a high available infrastructure with Lync 2013:

  1. One Single Front End with the stated HW on Technet (http://technet.microsoft.com/en-us/library/gg398835.aspx) can host up to 6,660 users (Less than Lync 2010 as a lot of database features such as the presence state are now handled on the FE). – http://technet.microsoft.com/en-us/library/gg615015.aspx
    1. This is true for the user profile that is stated on Technet and can highly differ from your company’s user profile. -> http://technet.microsoft.com/en-us/library/gg398811.aspx
    2. You should never run a FE on its own in a pool due to high availability reasons but first and foremost to achieve a quorum  - http://technet.microsoft.com/en-us/library/gg412996.aspx
    3. Running two FE in a pool is also not a good idea. Microsoft states there are a lot of caveats when running this and most importantly the SQL Server/ Mirror will come in to the quorum which isn’t a good idea. -> http://blogs.technet.com/b/rischwen/archive/2014/02/24/lync-2013-high-availability-deep-dive-architecture.aspx
    4. So what you will want is a pool with at least three FE Servers to have full high availability. But if you only have less than 1000 users, why would you need a pool that could potentially support over 10,000 users and risk wasting a lot of HW resources and money?!
  2. Microsoft states that for pools with a small amount of users, use two Standard Edition Servers in a backup relationship -> http://technet.microsoft.com/en-us/library/gg398095.aspx

What that means: No real high availability solution, since you have to manually shift whenever a server comes down!
So what are the options left here? Scale down the (three) servers!
With a virtualized environment that shouldn’t be a big of deal right? Wait! Let’s see what Microsoft states concerning virtualization -> http://www.microsoft.com/en-us/download/confirmation.aspx?id=41936
Here are the best practices when planning your virtualized environment:

These are the DON’TS:

  • Don’t oversubscribe CPU usage (physical to virtual CPU ratio must be 1:1)
  • Don’t use live or quick migration, or check points as dynamic user and conference data will break
  • Do not dynamically subscribe RAM, HDD space, NICs etc.
  • Do not use Windows Server 2008 (R2) as a Hypervisor (as it cannot address enough CPUs for the guest system), use Windows Server 2012 (R2)
  • Do not use different hardware within one pool
  • Do not make a linear size downs such as: 6,660 users need 16 CPU cores so 1000 users need about 3. (The SQL Express database on every FE for example can only address the first 4 CPU cores and will sometimes utilize these completely. You do not want to run the Lync application with only one core left! This a limitation of SQL Express).

Therefore if all of this is taken care of, the following is left to size your environment correctly.

Here are the DOs:

  1. Build up your servers (in a test environment) with the help of the capacity calculator (this will only give a rough estimation of HW that you need and will most likely be oversized) to have a good start. -> http://www.microsoft.com/en-us/download/details.aspx?id=36828
  2. Use the Stresstest & Performance Tool to test the hardware you need for you customer/ enterprise. This tool will create load on your system according to your input. This will require a profile on the usage of Lync by your users! Are they using a lot of conferencing or enterprise voice? This will enormously affect your server sizing, so make sure you get the best information out of your users as you can (for example, by starting a survey or by looking at older statistic from your conferencing or telephony system).

              Here is the Guide: http://www.microsoft.com/en-us/download/confirmation.aspx?id=41935
              Here you can find the tool: http://www.microsoft.com/en-us/download/details.aspx?id=36819
Here is a good guideline to start with from Thomas: http://lyncuc.blogspot.de/2014/06/lync-stress-test-key-helath-indicators.html

  1. Microsoft has determined 10 Key Health Indicators (KHIs) you need to look at that will help you determine whether the system will be healthy under the future user load or not:

              http://www.microsoft.com/en-us/download/confirmation.aspx?id=41697

After you have run the stresstest, looked at the KHI and have adjusted your hardware (down scaled or up scaled it), it’s important to perform another run to see if the system best fits your costumer/ enterprise needs.

So what’s the conclusion here? If a full automatic, high available solution is a must to meet your requirements to guarantee a certain service level, there is no way around to deploy an enterprise pool of Lync servers. The only way you can save resources and money here with a smaller amount of users is by down scaling the servers as described. If you do not have such a high demand on service availability and you can cushion a server or service outage by manually shifting to another server (which takes some minutes after you have to realize it!), you can also have a look at the recommendation from Microsoft by deploying two standard edition Lync servers in a backup relationship!

BUT, do not lay back yet because monitoring your systems is an ongoing and continual process for maintaining good service quality for your users! You can start by looking at the Call Quality Methodology from Microsoft:
http://blogs.technet.com/b/jenstr/archive/2013/10/23/call-quality-methodology-cqm.aspx
Or simply look for a smart Lync monitoring software such as ENow Uniscope:
http://enowsoftware.com/products-and-solutions/lync-management-tools/uniscope.aspx
Please feel free to share your thoughts on how you determine your server hardware for smaller Lync environments!