Stephen Foskett, in his recent three-part blog series on "The I/O Blender" clearly describes the problems and potential solutions for managing storage in virtualized environments. At Tintri, we have been designing and building flash-based storage systems solely for virtualized environments for several years. We have thought a great deal about this problem, and were delighted to see that we are not alone in our thinking.
The basic problem, described Stephen, is that virtualization disrupts the flow of information needed by storage systems to efficiently and effectively manage storage for virtual environments. In a physical world, where an application running on a single-server accesses dedicated LUNs, the storage system can easily infer and optimize for application behavior based on the configuration and access patterns to the LUNs. Virtualization, however, disrupts this entire process by running many applications in virtual machines on a single physical server and blending all the IO requests from these applications into a single IO stream, often to a single LUN.
As a result, storage sees what looks like random IOs and can no longer infer or optimize for each application. More than this, all the storage management operations such as quality-of-service, snapshots, cloning and replication, which operate at the level of LUNs and volumes, can no longer be used to tune and manage virtualized applications. In effect, just like Superman in the face of kryptonite, admins are unable to use the advanced storage management capabilities that make enterprise storage so valuable in virtualized environments.
Server virtualization is a big problem for conventional enterprise storage arrays. It reduces or eliminates the value of the very features customers seek when selecting an array.
Stephen goes on to say that one way out of this bind is to introduce VM-aware storage protocols, such as the vVols protocol proposed by VMware, designed specifically for managing and accessing storage in virtualized environments. We wholeheartedly agree that this is a step in the right direction and are happy to see that VMware is taking steps to address it. In fact, one could consider VAAI (vStorage APIs for Array Integration) as the first step. As Stephen notes, however, VAAI improves the efficiency of storage operations in VMware environments but not the intelligence of storage. That is, storage systems still have no way to demultiplex the blended IO stream into its constituent parts, and you still cannot use basic storage management operations such as snapshots on a per-VM basis: Hence the need for the vVols protocol.
Of course, vVols will not be built in a day. VMware still needs to specify the protocol and get buy-in from storage vendors. Then vendors must implement the protocol in an efficient and effective manner. This will be no simple matter and there will likely be huge differences in the quality of implementation and interoperability between vendors. Stephen notes that not every storage vendor will be able to effectively support the vVol protocol and that "this promises to be a very tricky implementation indeed."
Tintri was early to recognize the severity of storage management problems in virtualized environments. By leveraging existing hypervisor management interfaces, we have implemented VM-aware storage management features without waiting for a VM-aware storage protocol. And although our storage is hypervisor-agnostic , we are looking forward to providing the most efficient and effective implementation of the vVols protocol.
As an industry, we have come a long way without VM-aware storage, but we have now reached a point where storage is the dominant cost in deploying and managing virtual infrastructures, and it is evident that the traditional approach to storage management based on LUNs and volumes is becoming less and less effective. VM-aware storage not only allows us to restore the effectiveness of storage management in virtualized environments, but also makes storage easier to use and more powerful than in physical environments.