New improvements in the way cache is managed in virtualized environments may lead to big benefits.
Server refreshes give organizations virtualization hosts with more processor cores and more power than ever before. That means it's possible to pack more virtual machines onto each host, but storage systems often struggle to cope with the resulting increase in I/O operations. The good news is that the software that controls on-server storage caches is becoming more effective in virtualized environments.
The Impact of Virtualization on Storage
The attraction of more powerful processors in virtualization hosts is clear: if you double the processing power, you should be able to run twice as many virtual machines as you did previously. That has important financial implications when it comes to per-processor virtualization software licensing costs.
Unfortunately, server virtualization is not as simple as that. A physical server running twice as many virtual machines produces twice as many I/O operations, and these become random operations rather than sequential ones thanks to the "I/O blender" effect. In fact, the amount of I/O operations is probably more than double as virtual machines are moved around.
The result? Storage systems that struggle to cope and applications that run slowly in their virtual machines.
When it comes to addressing the "write" side of the problem, one solution is to use a storage hypervisor such as VMware's Virsto. The storage hypervisor takes over the handling of I/O traffic from the standard virtualization hypervisor, sending writes to a high-performance staging area which immediately acknowledges them. The staging area then optimizes the writes—essentially making them sequential streams rather than random ones for each virtual machine—and sends them on to a storage pool for final storage.
A storage hypervisor such as VMware's Virsto can be very effective at speeding up virtualized server infrastructures as well as breathing new life into older SANs that are added to the storage pool thanks to increased write speeds.
The problem is that for most companies, I/O activity is very far from balanced. "It very much depends on the applications concerned, but most are biased towards reads," says Mark Peters, a senior analyst at Enterprise Strategy Group. "That means most organizations end up with a 60/40 split or even an 80/20 split in favor or reads."
There are several things you can do to speed up reads, including buying a large number of new disks for your SANs, short stroking and increasing the amount of RAM available. But it's probably more effective to carry out some form of storage tiering by introducing an on-server read cache using SSD storage. "Read caching is a very effective tool," confirms Peters.
Storage Acceleration Software
But there are still problems with adding an on-board SSD cache of the sort sold by companies like Fusion-io, IBM, EMC, OCZ and SanDisk, says Peters. One is the fact that the SSD hardware—often hundreds of gigabytes of cache—does have a cost. That may not be an issue in smaller organizations with a limited number of physical hosts, but in complex virtualized environments where workloads are moved from host to host using technology such as VMware's vMotion, it becomes more important. Unless every single physical host is equipped with an SSD cache, the presence of storage caches on some servers but not others restricts which workloads can be moved to which machine.
"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.