This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - Choosing storage for VDI: Read more in this section
Explore other sections in this guide:
Implementing virtual desktops puts a strain on your network and storage system, so it's important to get to know some options for VDI storage arrays.
Before deploying virtual desktop infrastructure (VDI), you must consider your VDI storage network, which may be based around the same Ethernet infrastructure from which end users access their desktops. While the network layer is rarely the bottleneck, you shouldn't underestimate the amount of input/output operations per second (IOPS) that virtual desktops generate.
VDI storage stressors
Events such as the simultaneous deployment of a large number of desktops or a surge of end users powering on their desktops in the morning can create bursts of network traffic and IOPS on the data stores that hold the virtual desktop images. That makes it critical to properly test the infrastructure's scalability.
More VDI storage resources
Quiz: VDI storage and backup
Desktop IOPS do not scale linearly, and you might find an unexpected downward tipping point in performance once you reach a range of 400 to 500 virtual desktops. One solution to this is to use solid-state drives (SSDs) to take the spindle out of the equation.
These SSDs hold the parts of the desktop that present the most I/O. There are a couple of ways to approach this -- for example, some storage vendors offer read-only cache memory that can be added to the VDI storage array. This cache can be used to take the read-only components of a virtual desktop environment (often referred to as the "parent" VM) and locate it in memory to avoid the spindle.
Array options for VDI storage
Another alternative is to remove the storage array from the situation altogether. Companies such as Fusion-IO provide solid-state PCI Express cards that can be fitted to each virtualization host in the cluster. With recent advances, virtual desktops can directly access these devices, giving almost native access to the storage.
This setup requires the IT team to build a "nonpersistent" model for virtual desktops so that it doesn't matter which ones users connect to. The storage is local to the virtualization host, and standard features such as vMotion, VMware High Availability and VMware Distributed Resource Scheduler will not work.
Vendors such as Nutanix are allowing customers to use local storage, but it is shared and available across multiple hosts in a cluster using a virtual appliance that sits on each VMware ESX/ESXi host. The vendors are increasingly targeting the VDI market in an effort to reduce the costs associated with storing virtual desktop images on expensive storage area network (SAN) technologies.
IT shops should also compare storage vendor offerings with their own cloning technologies. Most of the big storage vendors such as Dell, EMC and NetApp have recently developed plug-ins to the virtualization management layer that allow for the offloading of virtual desktop provisioning.
For example, NetApp's new version of the Virtual Storage Console (VSC) for VMware vCenter automates the cloning of virtual desktops (Figure 1). VSC imports them into a VDI broker such as VMware View or Citrix XenDesktop.
This close integration has spawned new programs from both virtualization and storage vendors. VMware's application programming interfaces (APIs) for storage, for instance, improve performance between its ESX hypervisor and the storage array. View 5.1 now includes a technology preview that allows for the offloading of the cloning process to the data store without the need for a storage vendor plug-in.
This capability for VDI storage is currently limited to certain versions of firmware on the array and is not fully supported by VMware, but it offers insight into the direction many VDI vendors are heading toward.
In addition, many new versions of VDI brokers allow the administrator to carve out an allocation of physical memory on the virtualization host, which can be used for disk caching (Figure 2). This significantly reduces the read and write IOPS generated by the virtual desktop.