|By Eric Burgener||
|February 27, 2012 12:45 PM EST||
There's a new segment emerging in the industry around storage hypervisors. This is a simple idea that makes a lot of sense. We all understand the benefits that server hypervisor technology brought to servers in terms of utilization, flexibility and cost savings. The promise of a storage hypervisor is to do for storage what server hypervisor technology did for servers, providing the same utilization, flexibility, and cost savings benefits.
Keeping with the analogy, a storage hypervisor must meaningfully improve the utilization of existing storage resources to drive lower costs and, second, it must provide the level of virtualization necessary to offer unfettered management flexibility.
Let's face it: we have been over-provisioning storage for years. The wastage this has caused has driven the development of some interesting technologies like storage capacity optimization (the most well-known example of this technology is de-duplication) and thin provisioning, among others. Most enterprises didn't really have a good handle on just how badly they were underutilizing storage resources along the lines of performance and capacity consumption. A "storage resource management" push about a decade ago attempted to help enterprises quantify this but not surprisingly, storage administrators weren't too keen on making it easy for others to see just how underutilized the storage was.
Fast forward to virtual computing. As badly as storage was underutilized on physical servers, it's much worse on virtual servers. The I/O patterns in virtual computing environments are much more random than they ever were on most physical servers, and spinning disks don't handle unpredictability very well. The more randomness in the I/O pattern, the fewer IOPS the drive produces. So you end up with drives that are producing maybe only 65% of the IOPS of which they are theoretically capable, which means you have to buy more drives to meet your performance requirements. If you could just use the drives you have more efficiently, you'd need a lot fewer of them.
Storage capacity isn't used very efficiently in virtual computing environments either. If you're running in production, you're very likely to be using thickly provisioned virtual disks to ensure you get the performance you need. Provisioning this storage is not very efficient; it takes a long time and it wastes storage capacity by pre-allocating a lot of storage that you may not use for months or never actually use. Thin provisioning by itself is not the answer here, because it often doesn't provide the performance you need. What is needed is high performance thin provisioned storage.
If you haven't seen the impact of this conundrum already, as your environment grows you will. You'll find you need 30-50 percent more storage hardware to meet your performance requirements in virtual computing environments.
And what about management? If you're using block-based storage, you are managing storage at the LUN level. But as a hypervisor administrator, what you'd really like to do is have the storage administrator put your configuration together up front, and then thereafter just manage at the virtual disk level (VMDKs on vSphere, VHDs on Hyper-V) so you could handle storage provisioning and de-provisioning yourself. When you perform storage operations like snapshots, live migrations, failover, or replication, you want to perform those operations on a select group of virtual disks, not on every virtual disk that happens to be on the same storage LUN as the ones you care about. And you want to take advantage of rapidly provisioned, high performance, space-efficient storage when you do that. This is where storage virtualization technology comes into play.
Before we sum up, I'd like to comment on SSDs. SSDs have been the industry's response to virtual computing's storage issues, and prices on them are definitely coming down. It's clear that SSD has a place in virtual computing going forward, but just throwing SSD willy-nilly at storage performance issues is somewhat analogous to trying to improve physical server environments by just buying a faster CPU. You already had CPU cycles that you weren't using. The real innovation with server hypervisors was to change server architectures to use existing CPU cycles more efficiently. Then, if you wanted to buy a faster CPU, you'd get even more out of that too.
Think about how this applies to storage. I have drives that theoretically could deliver 180 IOPS, but each is only delivering 135 IOPS on average. I'm allocating storage that I'm not using so I could actually "run out" of storage while I have tens of terabytes of allocated but unused storage sitting in my array. I can spin a VM up very quickly if the storage is already provisioned, but provisioning high performance storage takes a long time - it's not very efficient. If I'm managing at the storage LUN level, then I'm not performing storage operations like snapshots, live migration, failover, or replication very efficiently in terms of time, capacity consumption, or bandwidth utilization. A storage hypervisor changes things so that these pre-existing resources are operating much more efficiently. Then, if you want to add SSD on top of that, you'll be getting a lot more out of that as well.
To sum up, there are four areas that a storage hypervisor needs to address to improve storage resource utilization: performance, capacity consumption, provisioning, and management. The bar on server hypervisors has been set, and the industry is adopting that technology by storm. It's time for a storage hypervisor, and server hypervisor technology provides a great analogy to help define exactly what a storage hypervisor does.