Recent Trends in Storage Acceleration Software - Page 2


Want the latest storage insights?

Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  

"To get the full benefits of vMotioning you need your environment to be as flexible as possible or you just get a backend storage problem again," says Peters. "That means you need a way to manage and share the SSDs."

The way to do this is with storage acceleration software that works with the physical cache (and which is often sold by the physical cache vendor). This type of software is becoming increasingly important.

The Need for Flexibility

This presents an immediate potential problem. If this software is hypervisor-specific, then that puts restrictions on how flexibly the hardware cache can be used. "Any vendor that is not looking to extend their software to other hypervisors is addressing only a part of the market," says Peters. "But the main problem is that most customers will have both VMware and Hyper-V, so if the software vendors don't go down the multiple hypervisor route, they are not offering maximum flexibility," says Peters. That's important because it could prevent you from allocating workloads to physical hosts or allocating physical caches to physical servers in the most efficient way.

Fusion-io is one of the market leaders in storage acceleration software (along with companies like OCZ and SanDisk), so the latest update to its io-Turbine software product, announced in late June, provides clues as to the direction the market is headed.

One notable point is that io-Turbine is still only aimed at users of VMware's hypervisor—this was the case when Fusion-io acquired io-Turbine back in 2011. But Lee Caswell, a vice president of marketing at Fusion-io, hints that the company may diversify. "We are very interested in supporting Hyper-V in the future," he says.

But the latest version introduces some significant improvements in terms of flexibility. For example, it's now possible run the storage cache software at the hypervisor level or at the virtual machine level.

It's more useful to run the software on guest machines because then you can look at the type of I/O activity in that virtual machine and choose what data to cache at the virtual machine, volume, disk or file level. That means you can get the maximum benefit from your hardware cache by filling it with the data that benefits most from being cached on the server.

By contrast, putting the caching software in the hypervisor turns it into something of a blunt instrument, because all the data from all the VMs are cached—even data that is rarely read. There is a need for this capability because in a service provider environment the service provider may not have access to the customers' guest VMs to install a caching agent.

But a bigger change—which seems to indicate that storage caching is getting to a new level of maturity—is in the way that the storage acceleration software handles virtual machine migrations using VMware's vMotion. It's now possible to vMotion between machines with different amounts of cache—or between a machine with a cache and one without—without any direct intervention. Cache is automatically reallocated when a virtual machine is moved off one host and on to another, and this provides just the sort of caching flexibility that Peters mentioned is needed to be able to get the full benefits of live migrations in a virtualized infrastructure.

We've become accustomed to talking about software-defined storage, as well as software-defined networking and even software-defined servers. Now it seems that hardware storage caches are the latest thing to get the benefit from the "software-defined" treatment.

Submit a Comment


People are discussing this article with 0 comment(s)