It’s all about the Storage!
During our customer engagements, we’re privileged to see multiple deployments utilising differing technologies whether that be for Data Centre or VDI workloads. Storage is a key factor in any deployment and in this article I’m going to look at some of the storage approaches for VDI deployments and discuss their benefits and disadvantages.
Performance
Let’s start with performance, calculating IOPS in a VDI deployment is a hotly debated subject, you can “assume” industry averages for each workload, but these averages leave little room for growth and don’t cater for those peak workloads, such as a logon storms. Taking the maximum figures is a safer bet but you’ll pay a premium for a lot of performance that will go unused most of the time.
So how do we find the correct sizing? One approach is to use the peak average. Using a planning tool to look at the total IOPS hour by hour will show when your largest IO spike occurs, determining how many machines are online during that short period and dividing the IOPS by those machines will give you a “peak average”; This approach can provide more realistic IOPS requirement, but the figures need to be monitored over a long period to ensure key business periods (such as month end; patching; AV scans) are included. This is a more realistic approach than the day long or industry average.
If your planning tools don’t present this in a report, you’ll need to track the data hour by hour to gain the information, which can be labour intensive; some planning tools offer a 95 percentile rule, where the top 5% of IO is not accounted for, this can offer reduced storage requirements, but can actually contribute to a slowdown, as you’re effectively not providing the peak performance when it’s most required.
A final note on performance is make sure you monitor the correct workload; don’t monitor XP machines then deploy Windows 7 machines with completely different agents installed as the figures will be skewed. If this is the only option open to you, update your findings during the proof of concept or pilot deployment when running the final build.
What storage should I use?
Now you have some performance figures what do you do? Get some quotes from some storage vendors, but make sure you’re sitting down as the cost is probably going to be high. Another option is to deploy one of the myriad of storage optimisation technologies that are on the market.
These optimisation technologies offer great potential; increased IOPS, de-duplication and help remove the CapEx barrier to deployment by reducing cost. On the down side there’s potential for the solution to be a little more complex in design, complicate operational tasks and many are still in their infancy frequently updating versions or architecture – so choose carefully and test thoroughly.
Licencing
You’ll need to consider the license model, is it per GB or per user, concurrent user or named user? It can make quite a difference especially when coupled with maintenance.
Sizing
Sizing comes in two flavours. You’ll need to work out how much space you’ll require and this will depend on a number of aspects. Where the user persona is, pooled or dedicated assignments, if you’re using linked clones (Citrix MCS or VMware View Composer) or full clones and what the de-duplication rate is for your selected storage.
When sizing for pooled desktops, you need to size for the peak concurrency, plus room for growth and breathing space. When sizing for dedicated desktops you’ll need to cater for 100% of users and growth, as each user is assigned to a persistent desktop.
The other sizing aspect is the impact on the host if your solution utilises a virtual appliance, you’ll need to account for the CPU and memory requirements when sizing your hosts, or deduct that resource from what’s available for desktop workloads.
Some storage designs can produce additional or surplus space which is a by-product of adding spindles to provide performance; this should not be used for other purposes, or seen as available space as it will impact the performance of your planned workloads – guard it from misuse!
Linked versus Full clones
Linked clones offer a way to reduce storage requirements by storing a single base image and linking multiple “delta” disks to it, you can create massive savings. You’ll need to account for a number of base images, perhaps multiple base images per data store depending on the broker you use.
Linked clones are great for pooled desktops, but not so great for dedicated as you’re tied to the base image / replica and therefore VMFS datastore. As long as you plan your storage for growth and performance they’re a perfectly viable solution, but you’ll lose storage vMotion capability and perhaps vMotion across clusters which can impact maintenance.
Using full clones for dedicated desktops provides less of a tie than linked clones, it gives you full mobility within the data centre, and you’ll just need to leverage a storage solution that can de-dupe the data to a sensible point to make it affordable. Additionally, orchestration toward the build and integration into the broker may be required.
Local or shared storage
Optimising local storage provides the lowest cost storage, but in some cases can introduce increased complexity or loss of key hypervisor features such as VMware’s HA or DRS. HA however, can be provided by other means for pooled desktops, such as by the broker but not for dedicated desktops.
Without DRS you’ll have to be more cautious with your sizing per host and manage the capacity at a host level rather than the cluster, as you’re unable to automatically balance out workloads across the cluster. While desktop workloads may not be as sustained as server workloads, it’s quite easy to find hosts in a cluster may consume excessive CPU while others use less. In certain cases it doesn’t take many guests with runaway CPU processes to put a host under pressure, thankfully you can manage these CPU processes with tools like RES and AppSense.
Maintenance is also complicated with local storage, as you’ll have to manually drain a server of its users before entering maintenance mode rather than moving those workloads off to a standby host, you may even have to wait until out of hours for your maintenance window. With shared storage DRS is possible (and storage DRS if using full clones), dedicated desktops can be hosted and protected by HA without any additional solutions, but it potentially costs more than local storage, it’s a question of balance and what your main requirements are.
Management
Finally, regardless of your virtual infrastructure make sure that you work closely with the storage team so that your management servers have guaranteed / isolated performance. This ensures that you can manage your environment even if your workloads are consuming all the performance for their allocated disks.
If you would like talk to us about assisting your organisation with storage requirements for your data centre, workspace or cloud project, please contact us.