Dirty Little VDI Secrets
Posted Thursday, February 24, 2011 in 0 comments
If you’re just starting to think about a VDI deployment, there are a few dirty little secrets that I hope I can help you get in front of. For an issue to qualify as a dirty little secret, I’d say it’s something that isn’t readily predictable up front, and has some real negative consequences down the line. After having gone through the process of VDI deployments vicariously through some of our customers, here’s what I’ve seen on the storage side that seems to meet that definition.
Each desktop that you’re virtualizing may have less than 25GB of data on it, but when you’re virtualizing 500 or 1000 of them, that can be a lot of data that you are now centralizing in one place. On physical desktops, that storage capacity was probably sitting in some pretty inexpensive IDE drives. Most of these desktop systems come with a pretty good size drive (for individual user purposes) and I note that on frys.com I can buy 1TB of this class of storage capacity for a little more than $100. But when you centralize all that storage in the data center, because of a lot of other considerations (performance, high availability, recoverability, etc.) you’re probably putting it on a much higher cost class of networked storage. So I could go from paying ten cents a gig to paying more like $4 - $8 a gig for raw capacity. Maybe this is a surprise, and maybe it’s not, but this next one probably is.
So let’s say you’ve gotten past this first issue, and have gone forward with your VDI project. You’ve bought server virtualization software, chosen hosts and storage, and obtained the necessary VDI software. Presumably you did some planning to determine what sort of storage configuration you would need, using the same general approach you’ve used on physical servers in the past. Profiling the workload (IOPS, MBPS, latency), understanding avg and peak requirements, then looking at availability, performance, and capacity requirements, and coming up with what you need from there.
Well, here’s the surprise. Because of the way type 1 hypervisors like ESX, Hyper-V, and XenServer work, your storage is going to run a lot slower in the average virtual environment than it does in the average physical environment, and here’s why. Multiple VMs running on a single physical host create an I/O pattern that is very write intensive and extremely random, and this is exactly the pattern that will get you the worst performance out of your disks, regardless of what class of device they are. Seek times and rotational latencies really start to dominate, and what we’ve seen in most customer environments is that storage performance can easily take a 50% hit. And if you’re trying to use thin provisioned disks to save on capacity, you’re going to take even more of a performance hit unless you buy a very high end class of storage array that addresses that problem for you.
If you can afford that kind of high end storage, then you may avoid the performance hit due to thin provisioning, but you’re still going to run into the first problem, and end up having to throw more spindles at your storage config to get the IOPS you need. SSD could be another option, but if your workload is very write intensive, that’s probably not going to help much.
Where I’m headed with all this is that the legacy storage architectures that worked pretty well with the one server/one application model that has been in vogue over much of the last 20 years probably isn’t going to cut it in the virtual world. And virtual is where we’re headed.
There’s another option to consider here. At Virsto Software, we’ve got a software plug in for hypervisors that sets up a storage virtualization layer, compatible with any heterogeneous block-based storage, that turns extremely random I/O patterns into sequential I/O patterns as they hit physical disk, which is how you’ll get the highest performance out of your disks, whatever class they are. This layer is transparent to applications, integrates seamlessly with the hypervisor and its associated management tools, and does two things right off the bat: it increases the number of IOPS you can push through your existing spindles by 3x – 4x, and it reduces your storage capacity consumption (through software-based thin provisioning). There’s no hardware to buy, and you’ll end up needing a lot less than you thought you did.
This is a relatively new technology, but it is running in production in a number of accounts, and it’s just one more option you have in dealing with unexpected surprises for VDI implementations. By the way, this same storage performance issue exists in server (not desktop) virtualization environments as well, and this plug in has the same benefit.
As VDI deployments get bigger, there’ll probably be a few more surprises we as an industry run into. But I hope knowing about two common ones helps you in your planning a bit.
Leave a Comment