In the weeks approaching VMworld 2014, I have been sharing more of SanDisk®’s testing results and deployment suggestions, showing the most advantageous impacts of SSDs in virtualized environments. Here are some of my recent blog posts:
- VMware Virtual SAN – Benchmarking VDI workloads using SanDisk SSDs
- VMware Swap to Host Cache Testing Using SanDisk SSDs – Impact on VM Density, TCO and ROI
- VMware VDI Boot Storm Testing Using SanDisk ULLtraDIMM – Impact on VM Availability and End User Experience
These blog posts will be followed by detailed white papers to provide helpful guidelines for how to deploy SSDs to achieve greatest performance benefits and cost efficiencies in virtualized environments.
VMware VDI Pool Creation Experiment Using SanDisk SSDs
In my previous blog, “VMware VDI Boot Storm Testing Using SanDisk ULLtraDIMM – Impact on VM Availability and End User Experience”, I demonstrated the benefits of including SanDisk’s ULLtraDIMM SSD, a memory channel storage block device, to significantly reduce desktop boot time and enable the availability of desktops to end users dramatically faster than in an HDD environment.
In this post, I will demonstrate another VDI Administrator’s pain point, VDI Desktop Pool Creation, and how ULLtraDIMM can help dramatically improve bottlenecks such as in VDI boot storm.
VDI Desktop Pool Creation
VDI Desktop Pool creation is the first step in which VDI administrators create end user desktops with a given set of policies and rules, per the organization requirements. Once the pool creation is completed, desktops become available for use. The final step that the administrator needs to carry out following the pool creation, is to entitle groups and users so that they can access their desktops. At a very high level, the below diagram depicts a typical workflow for desktop creation:
In step 2, when the administrator deploys the VM, a huge amount of storage IOPS is generated. If this IOPS burst is not managed with appropriate storage infrastructure, the VDI pool creation time can be significantly high.
What Happens Behind the Scenes
To better understand the technical challenges (and bottlenecks) of VDI Desktop Pool creation, let us explore how a desktop pool gets created.
To begin the process, the VDI administrator creates one VM (master image) which contains all the applications, anti-virus software, OS patches etc. This master image is then deployed as an end-user desktop. In an organization with 100 employees, VDI administrators will deploy 100 such VMs.
However, the above situation can vary according to the needs of each user group, which often differ. In that case, the VDI administrator will need to create a separate master image for each group and deploy it accordingly.
This deployment can happen two ways:
- A Full Clone (the master image is completely replicated, and for this reason it is less storage efficient)
- A Linked Clone (the master image is linked from all the user data disks enabling it to be more storage efficient)
In the first deployment type, a clone copy of the master image is created and customized for each user. This is full clone (which has ~100% writes) requires very high IOPS when cloning takes place.
For our study, we chose to examine the second deployment strategy (Linked Clone) as this is a more common approach for VDI Desktop deployment.
The below graph shows a Linked Clone VDI Desktop Pool deployment strategy:
Fig 1: Linked Clone Desktop Pool Creation
As you can see in the above diagram, a Linked Clone process can be broken down into two steps:
- The creation of a replica image from the master image (Full clone operation, ~100% write)
- The creation of the data disk based on a number of users that are defined in a pool creation process and links the data disk back to the replica image (in a mix of read and write operations)
Both operations require different IO demands – initially write intensive and followed by a mix of read and write operations.
As mentioned, different user groups will have different needs and the VDI administrator will need to create different pools to support this, hence the storage IO impact will be manifold during creation time. For this reason, it is critical that the right storage sizing is done to address the VDI Desktop Pool creation needs and to simplify the VDI administrator’s work.
We carried out the experiment by creating 50 desktops in a single VDI pool. The Desktop Pool creation time is measured from the time the “Finish” button of the pool creation wizard is pressed until the time when all desktops are shown as “available” in the VMware Horizon View desktop status in administration window. We used VMware Horizon View VM system time to measure this interval.
We executed this same test using HDDs and SanDisk’s ULLtraDIMM SSD to observe the result difference between these two storage platforms.
To carry out the test we created VMware Horizon View Floating pool desktops in which a Windows 7 desktop master template (30 GB) is created and a desktop pool is created using this master. We initially created the pool in the VMware Datastore backed by HDDs (4 HDDs), and then, the same master template desktop pool is created in ULLtraDIMM-backed VMware Datastore (4 ULLtraDIMMs).
ULLtraDIMM SSDs connects flash storage to the memory channel via standard DIMM slots, in order to close the gap between storage devices and system memory. ULLtraDIMM SSDs use SanDisk’s proprietary Guardian Technology™ platform to meet the endurance needs of write-intensive and mixed-use application workloads. ULLtraDIMM™ SSD is also certified as VMware memory channel storage device.
The graph below shows the impact of each storage hardware to create 50 VDI Desktop Pool VMs.
As you can see from the graph, pool creation is 5x faster when the VDI environment is configured to run on ULLtraDIMM – a difference between a process that would take more than 1.5 hours, vs. only 20 minutes. It can also be seen that ULLtraDIMM can drive much more IOPS in comparison to HDDs and hence the pool creation operation is completed much earlier than HDD scenario.
Configuring VMware VDI on ULLtraDIMM is incredibly advantageous in addressing VDI pool creation. One can argue that this is a one-time operation and may not have significant impact on overall deployment strategy.
My answer to such argument is both “yes” and “no”.
This is definitely a one-time setup for a few users and use cases. However, it is an absolute big “NO” when many users, bigger VM sizes and a multitude of pools need to be created. Moreover, there will be further implication when desktop recompose happens (which I will discuss in my next blog).
There are use cases such as training departments, in which pool creation is a regular affair and a VDI administrator needs to go through a very painful process if they need to deploy pools using HDDs. These administrators need to create many more variations of desktop templates based on each training’s needs and deploy and delete them according to the training’s duration. This is a very vast topic in itself considering desktop image management, user accessibility and application provisioning and management. Each has got some implication with storage but hope I could provide some preliminary guidance by citing Desktop Pool creation example. This same argument holds equally strong use cases in healthcare and similar industries e.g. different departments in a hospital will have different desktops for their day to day operation and even within same user base such as doctors, every specialization will have their specific need in addition to general desktop requirements.
From a business perspective, getting things done faster and in an efficient manner is always a big and important advantage.
To learn more about SanDisk solutions for virtualization and VDI workloads visit our website . If you have any questions, you can reach me at firstname.lastname@example.org, or join the conversation on Twitter with @SanDiskDataCtr