0

How I Learned to Stop Worrying and Trust the Math

It’s been over a year again since I last posted an update. My bad. Hopefully, today makes up for it.

I’ve got quite a few tools in my toolkit that I have developed over the years designing and building Lync and now Skype for Business deployments. Some of those are things like the documentation script I developed while others are people way smarter than myself willing to answer oddball questions. One of those people is Tim Harrington, who has spent a ton of time working with me on developing, debugging, and tuning this whole thing.

Alright enough of that, let’s get down it. Most anyone that knows me knows that I love automating things, oddly enough it seems I’ve started at the end of the deployment and worked backward. First was the as-built documentation script, followed by the install and deployment bits (not yet publicly released), and then finally actually was the design and planning phase.

Let’s start with some caveats and warnings before we go too far.

  • Microsoft has published reference sizing numbers for Skype for Business deployment on TechNet.
  • Microsoft has created a capacity/sizing tool for Skype for Business you can download for free.
  • I’m not saying there is anything wrong with the info or their tool, just that it didn’t go far enough for me.
  • I accept no responsibility or liability for any outcomes from using my tool. There is no warranty or guarantee of support implied or expressed.

Looking at the Skype for Business Capacity Planning Calculator, there’s not much indication of what the compute capacity or requirements are and how they translate across hardware. This was always a struggle for me in the beginning as sometimes it was a best guess effort when sizing an environment, particularly if it’s virtualized. Thinking back to my days doing Exchange consulting I remembered the old Exchange planning calculator that relied on SPECint scores to translate performance across hardware.

SPECint provides a nice objective way to measure performance from different processors, hardware platforms, etc. With this as a starting place, I started building my own capacity planning tool that could account for these differences and still give me reliable results. No more spit-balling we’re moving up to educated guess territory. I’ve been able to take what I’ve learned and gone back and reviewed the environments I’ve built to see how they’ve performed after going into production. It took some tweaking and some formulas being scrapped and re-written a couple dozen times but I can now confidently say there have been over 1.5 million seats of Lync and Skype for Business deployed based on this design calculator and not a single environment has had performance issues. In fact, in most cases, the CPU utilization estimates have been within about 3% what the actual usage turned out to be.

Over time I have added additional components such as storage calculations for the SQL back-end databases, the file share for user meeting content, and even Persistent Chat storage sizing. The tool itself is not intended to produce a full design of an entire environment, but rather provide some guidance on sizing individual pools based on user counts, workloads, and target hardware.

The Input section shown below has all of the options to define the number of users, type of hardware, and what workloads are needed. Most of its pretty self-explanatory and some of the fields do have notes attached that appear when selected. Also note that it is a macro-enabled workbook, this is used to update the graph automatically when you make changes. You can use it without the macros but you won’t get all the fancy auto-updated chart-y goodness.

  • Two important items to note are the “Virtualization Overhead” and “Additional CPU Overhead”.
  • There is a lot of debate around virtualization with real-time media applications, and I’ve heard estimates of the CPU performance hit range from 0% for native bare metal hypervisors to 20% for older hardware without the new feature sets.
  • I always start with 20% to be safe until I know the platform and the configuration.
  • The “Additional CPU Overhead” increases the overall compute needed to account for third party applications that install onto the Front-End servers (for things like compliance, enhanced security scanning, etc)
  • The file share retention period is 365 days plus whatever term you specify in the field due to changes in SfB Server 2015.
  • All modality usage numbers are based on Microsoft defaults and can be adjusted as needed.
  • There is a link included to the SPECint site where you can search for your target hardware by the manufacturer, model, processor, and several other options.
  • You will need to make sure you update the SPECint Result, Baseline, and the Total CPU Cores.

Input

And now the results, shown in the images below. There are a few things to be aware of when looking at the results.

  • If you select N+1 the minimum number of Front-Ends will be 3.
  • The minimum number of CPU cores for any Front-End will never go below 4, and will always be an even number.
  • If you enable Dial-in Conferencing or Enterprise Voice and choose FALSE for the “Collocated Mediation” option you will get separate sizing info for the Mediation servers and the maximum concurrent calls.
  • The graph at the very bottom is intended to provide some flexibility in sizing or designing the environment. Given that Skype for Business is licensed per Front-End, it’s sometimes more cost-effective to create a smaller pool of servers each with more assigned CPU cores.
  • The target for all CPU utilization is below 80% on average to allow for spikes in usage.
  • The chart shows the permutations for using -2, -1, +1, and +2 servers and processors to allow you to see what your impacts are.
  • Anything above not matching to rules above is not shown on the chart. (i.e. 3 cores, 90% CPU Utilization)
  • The Edge server count is based on Microsoft’s published numbers of 12,000 concurrent users per Edge server.

 

Results

CPU Chart

TechNet Gallery Download

Leave a Reply

Your email address will not be published. Required fields are marked *