The Problem with Storage for VDI

February 2008 seems like a long time ago, and now that I think about it, it was.

I used my phones to make phone calls.

If I wanted to watch a movie, I went to Blockbuster and rented a DVD.

If I got lost, I asked someone for directions.

And someone told me it was the year of VDI, and I believed it!

The previous September, I’d been out at VMworld in Frisco when I first heard about VMware’s acquisition of Propero, who made VDM, which later evolved into View – although so much of the original code has been re-written over the years that today View bears little resemblance to VDM 1.0.

It seemed like a great idea – take all of a company’s IT policies, applications, data and wrap it up into a bubble that people can access over the network.

In my experience, through 2008 – 2010 a lot of people agreed. I saw a lot of customer interest in desktop virtualization. Or maybe it was just Windows Vista that caused people to look at alternatives.

But I know this - I wore out several pairs of shoes because I spent so much time walking around London talking to customers about VDI.

  

But the problem that customers inevitably ran into was that VDI was too expensive.

And most of that cost was storage.

Here’s a scenario I saw play-out countless times:

• Customer asks Storage Vendor for a quote to support 1000 desktops.
• Storage Vendor asks how much capacity and performance do you need
• Customer says 40GB per desktop & 20 IOPs
• Storage vendor works out one disk gives 200 IOPs so they need 100 disks.
• Customer does a pilot and finds out that during boot and login times, the desktops actually need 100 IOPs
• Storage vendor re-calculates and says they need 500 disks
• Storage vendor prices each disk at $1000*
• Storage vendor gives a quote for $500,000*
• Customer faints

*prices are for illustration only – I don’t deal with pricing and I have no idea what things actually cost.

Since 2008 many storage vendors have worked hard to change this.

One of the first things to come out was deduplication. Unfortunately this never really helped to make a significant difference to the cost of VDI. Take my example above…

Let’s say we went with 300GB Fibre Channel disk drives (Serial Attached SCSI aka SAS was in it’s early days in 2008). 500 of those would give us a raw capacity of 146TB. Now, we’ll loose a bunch of that to disk right sizing, formatting, raid overheads etc. Let’s assume a worst case and we have 50% of the raw capacity available as useable storage – so 73TB.

We have 1000 desktops, which need 40GB each – so 40TB.

That means that we had to put in 33TB more useable capacity than we actually needed – because we needed the spindle count to deliver performance.

So apply dedupe to that…if we achieve 50% space savings then we can shrink our 40TB worth of used space for our desktops down to 20TB. But we still had to put in 73TB of useable space.

Sold State Disks (SSDs) arrived in 2010 and at first glance seemed to be the ideal option to deliver the performance requirements from fewer disks– but they were, and still are, IMHO, very expensive.

After all, if an SSD is 10x faster than a normal disk, then instead of 500 disks you can use 50 SSDs.

But if the SSDs cost $20,000* each then that’s $1,000,000 – double the price of 500 Fibre Channel disks. Think about that – a cool $1m dollars for 1000 users. Suddenly buying them all new laptops looks like a good option.

*again prices are for illustration only. Seriously I don’t even know how much a pint of milk costs these days.

So SSD is too expensive, and normal disks are too slow. Enter Flash-as-a-Cache.

The idea was to use Flash storage (either NAND or SSDs) to serve some of the performance requirement, along with normal disks (Fibre Channel / SAS) to store the data.

It seemed like a great comprise – particularly when you included technology to reduce the amount of capacity you used, whether that be deduplication, or linked clones, or both.

You could use fewer traditional disks – just enough for the capacity you needed. And, a small amount of SSD or Flash – just enough for the performance you needed.

But, this too had problems. Most implementations only used the Flash to handle read I/Os.

This wasn’t too bad when we were dealing with Windows XP, which tended to perform a lot of reads (usually around 60% reads).

But when Windows 7 arrived we saw that it actually tended to perform a lot of writes (sometimes 80% writes).

So when the bulk of your I/O Operations (IOPs) are writes, a very fast read cache doesn’t really help you.

That’s not to say that storage arrays didn’t have methods for handling writes. Almost every array has some kind of write caching, and some even do things like write coalescing to reduce the amount of IOPs that hit the backend disks.

However this still didn’t really make a difference to the cost of storage for VDI.

So what is the answer?

Well, I don’t have one!

What I do know is that, since 2008, a lot of new storage technologies have been introduced to try and make storage cheaper – but in reality these technologies cost about as much, if not more, than they ultimately save.

So I doubt very much that a new piece of storage hardware, or a new storage array feature in the future will make a difference.

What we need to do is make storage a commodity – drive down the price of the hardware by doing more things in software. I think this is the future of storage for VDI – and hopefully it will arrive someday soon!