BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
In the early days of VDI, storage was the target for much of the blame when VDI projects stalled or failed altogether.
In the intervening years we've seen a number of innovative approaches to dealing with storage and VDI, and we're now to the point where our ability to deliver storage resources to VDI desktops is no longer held back by the old-school, "big-iron" offerings that once caused so many problems (and cost so much money).
Still, storage comes up a lot as the reason VDI projects fail. One of the primary reasons is that people tend to forget that desktop storage is different than server storage. The workloads that desktops place on storage are vastly different than those of server, database or file-share workloads. Here are three main differences:
I/O reads and writes are unpredictable.
You may have seen different numbers regarding the mix of virtual desktop reads and writes. Some folks say it's 50/50, but others say it's 30/70 (or 70/30). If you look hard enough, you'll see the number you want to see. That's fine, because it really doesn't matter what the number is. What matters is that you have to plan for both reads and writes.
Server workloads can sometimes be placed into "read-heavy" or "write-heavy" buckets, and then allocated storage is tweaked to support that particular workload. But desktops require both read and write optimizations. If your desktops are reading 70% of the time, you can't ignore the fact that the other 30% of time they're writing and simply "put up with a little lag."
Latency affects users differently
With a file server or application server, what happens when the storage system is over-taxed and slows down, even a tiny bit? It takes slight longer for the user to load a file, pull up a report or save something. The problem -- no matter how noticeable -- is relegated only to that application and specifically that individual operation within that application.
Now take that same slightly overtaxed storage system, and instead of hosting some files or relying on the storage for a single application, apply it to an entire desktop. It's not just one file or one query that's slow -- it's everything. All applications and functions are affected. You might even get keyboard and mouse-click latency. The entire user experience suffers.
Everything is less predictable when users are involved
The best possible thing I can say about users is this: They are a constant source of job security for IT pros. Without users, our jobs would be too easy (if they existed at all). We wouldn't have to deal with kitten mouse cursors, pictures of grandkids on the desktop and locally viral trends sweeping through departments. But there they are, randomizing everything, taking away all that comfy predictability that comes along with servers.
That's the real reason we hear that desktop I/O is 50/50 -- we always have to be prepared for that. It's not a constant split; it's an undulation without a predictable pattern. Adding users into the mix means we have to change the way we plan. We have to pay attention to their tendencies (all the craziness), as well as how they actually use their desktops so we can build the right platform that scales and preserves the user experience all the time, not just when there's spare capacity on one side of the storage system.
Do you need a new storage array?
Important questions about VDI storage
VDI storage considerations for new deployments