FSLogix O365 Container Sizing – The Final Word
By: Leee Jeffries |
Recently I’ve been working with FSLogix on producing some storage sizing metrics for Office 365 VHD containers.
I’m happy to announce that this testing is now complete, and we have produced some conclusions for scalability and sizing.
A white paper is available here:
FSLogix Office 365 Contrainer Scalability and Sizing.pdf
For those interested in the summary results, keep reading.
Testing Environment:
The environment used for testing is depicted below.
This environment was built in an automated fashion using AzureRM Templates which I created in VSCode. These templates are available for re-use and can be found in the FSLogix GitHub Repository.
I won’t go into detail on how these templates are used as there is an introductory document within the repo that explains how the solution works.
The environment utilises Citrix as the delivery method for desktops and LoginVSI for testing purposes.
Running the Tests:
The simple aim of this testing was to determine the necessary storage IOPS required to support an FSLogix Office 365 Container solution.
I performed testing on Task and Knowledge Worker Workloads using LoginVSI with the Search Index Roaming enabled and disabled on the FSLogix side.
3 tests were run in each scenario and an average of the results taken for each test type.
Storage metrics are based on a standard industry formula:
Recommended IOPS = Average IOPS + (Standard Deviation of IOPS * 2)
Testing Results:
Overall testing results across all tests are shown below, these are the figures to use if you are sizing an FSLogix O365 Container solution.
Row Labels | Mean Write IOPS | Mean Read IOPS |
| FSLogix_Caching_Indexing_Off_KnowledgeWorker | 5.1 | 7.8 |
| FSLogix_Caching_Indexing_Off_TaskWorker | 4.8 | 8.3 |
| FSLogix_Caching_Indexing_On_KnowledgeWorker | 5.7 | 8.1 |
| FSLogix_Caching_Indexing_On_TaskWorker | 4.5 | 7.8 |
Examples of Sizing:
The below table shows examples of sizing taking an average of all tests and multiplying that out by the number of users.
| Total Users | Recommended Read IOPS Per User | Recommended Write IOPS Per User | Total Required Read IOPS | Total Required Write IOPS |
| 100 | 8 | 5 | 800 | 500 |
| 200 | 8 | 5 | 1600 | 1000 |
| 300 | 8 | 5 | 2400 | 1500 |
| 400 | 8 | 5 | 3200 | 2000 |
| 500 | 8 | 5 | 4000 | 2500 |
| 600 | 8 | 5 | 4800 | 3000 |
| 700 | 8 | 5 | 5600 | 3500 |
| 800 | 8 | 5 | 6400 | 4000 |
| 900 | 8 | 5 | 7200 | 4500 |
| 1000 | 8 | 5 | 8000 | 5000 |
| 2000 | 8 | 5 | 16000 | 10000 |
Summary:
Read IOPS don’t cost much and Write IOPS of 5 per user is a nice low value. The folks at FSLogix have mentioned that with Cloud cache this could be even lower reducing the IOP load on the backend storage in a similar way to MCS/PVS Disk Caching.
For all the details and full write-up and results please do take a look at the whitepaper - FSLogix Office 365 Contrainer Scalability and Sizing.pdf
About Me
I'm an IT professional with over 15 years of experience in the IT industry, I've worked in many fields in my career. This blog is to share my experience, tips and tricks.