VDI storage needs and how to optimise SANs for virtual desktops

Virtual desktop environments throw up big challenges to storage with lots of random I/O, so how best do you assess VDI storage needs and optimise a SAN for virtual desktops?

Storage is a key consideration when embarking on a virtual desktop infrastructure (VDI) project. Putting large numbers of virtual desktops in a few physical hosts can produce large and random patterns of reads and writes to VDI storage so it’s important to plan carefully and optimise your SAN storage to take account of this.

In this interview, SearchStorage.co.UK Bureau Chief Antony Adshead speaks with Mike Laverick, an author, blogger and podcaster, about how to determine VDI storage needs and how to optimise VDI storage.

Play now:
Download for later:

VDI storage and optimising SANs for virtual desktops

  • Internet Explorer: Right Click > Save Target As
  • Firefox: Right Click > Save Link As

SearchStorage.co.UK: How can I determine the storage needs of my planned VDI implementation?

Laverick: I think initially when VDI came on the horizon a lot of people focussed on the space virtual desktops would take up and how long it would take to clone them.

Now, in fairness, most of those issues have been addressed by what’s called linked clones. This is where you have one parent VM [virtual machine] and as you start to spin out further desktops what you get is a delta, or difference, VM, which massively reduces deployment time and also space.

It’s worth saying that the major VDI vendors usually offer some sort of linked-clone feature. But if you’re a storage guy living in the storage world and you have a close relationship with a storage vendor, you should know about a lot of the mainstream vendors like EMC, NetApp and Dell now have plug-ins that allow you to very rapidly produce lots and lots of virtual desktops. And, in many respects, that’s a more efficient way of doing it, both from a capacity and cloning time perspective.

But putting space and cloning times to one side, the focus really should be on IOPS generated by virtual desktops. So, we have such things as Boot storms, [which is] when lots of virtual desktops are powered on, and logins and logoffs by virtual desktops have been shown to produce an awful lot of disk activity.

So, before you begin on your journey into VDI, you really need to look at the IOPS that each VM creates, on boot-up, when it’s idle and when it’s actively being used by an end user. It’s incredibly difficult to size and scale a virtual desktop environment without real users connecting and using the desktop.

Listeners should be aware that … there’s a new VMware planner that allows you to spin up lots of virtual desktops and actually have activity taking place inside -- people opening up Word and Excel, and so on -- to generate real activity within the desktops that you can then measure.

The main thing to say on this particular topic is that things do not scale linearly. A lot of people have got burned by doing proof of concepts that only have, say, 50 or 100 or 200 desktops, but as they start to add more and more desktops to the pool they begin to see the IOPS grow and grow to the point that they become a real pain point in terms of scalability.

SearchStorage.co.UK: How can I optimise my storage to meet the needs of a VDI implementation?

Laverick: Well, the first thing is to split the virtual desktops into a series of different virtual disks, and a lot of VDI management tools force you or point you in this direction to begin with: a disk for the boot OS and potentially a disk separately for the user’s user profile and a separate virtual disk for temporary files such as the Internet cache, page files or any other temporary files that are created.

The other thing we’re now looking at is trying to take the spindle out of the equation when it comes to VDI, and this can take many forms. Some vendors offer flash cache, or solid-state memory, on the array to reduce the IOPS generated [to spinning disk]. Many vendors have a portion of the disk architecture marked out for use with SSD … in an effort to take out the IOPS.

The critical thing to focus on here is that some [vendors’] onboard cache is read-only and not read/writeable, and that can be significant for logins and logoffs, which have been shown to be read- and write-intensive.

The third option is some sort of internal I/O card that sits inside the physical server. A good example of this is Fusion-io. The only thing I would say about these internal cards is [that] they can be a little bit pricey when compared to adding a better kind of infrastructure for disk I/O to the existing array.

So, there’s a little bit of intelligent placement that needs to take place when you’re actually putting together the virtual desktops. As I was saying a moment ago, things like linked clones … come in two formats: the parent VM and the deltas. The parent VMs should be on super-fast storage like SSD because it’s a read-intensive component. The deltas don’t tend to generate that much IOPS, so they could reside on generic spindles.

As ever, with this particular equation, you’ve got to balance the number of spindles you have against the cost of SSD, so if you have a large SAN environment with lots of spinning disk currently, you might be able to absorb the penalty of the IOPS generated by virtual desktops. But if you don’t, you might find SSD is a faster route to reducing the pain point generated by lots of virtual desktops. 

Read more on SAN, NAS, solid state, RAID