It is no secret that one of the most difficult challenges with virtualization is managing the storage where VMs reside. The problem starts with the fact that VMware has historically known very little about the storage VMs are using. This monolithic approach performs snapshots and other actions to an entire volume just to protect a single VM. VMware is seeking to address both of these challenges with the introduction of the vSphere APIs for Storage (VASA) and Virtual Volumes (VVOLs).
What are VASA and VVOLS?
VASA was introduced in vSphere 5.0, hoping to solve the first problem of VMware being unaware of the storage VMs are using. VASA provides a mechanism by which vSphere can understand the capabilities of a storage array. The first version of VASA just laid the groundwork and was very basic, allowing a VASA Storage Provider (SP) to provide a simple string of the various features it supported. There wasn’t even a standard on what should be in the string. VASA 2.0 was released with vSphere 6.0, and is more sophisticated and standardized. It is the mechanism that vSphere uses to verify that an SP has the specific capabilities necessary to support VVOLs.
Virtual Volumes are an attempt by VMware to solve the issues with a traditionally monolithic approach to providing storage to virtual machines. VMware refers to a VVOL as a container for a VM, however, this has nothing to do with Docker containers. There are three elements in the VVOL architecture: the storage provider, the storage container, and the protocol endpoint. The provider is the storage array that will be storing the VVOL. The container is the VVOL itself, and the protocol endpoint is where the storage device will actually store the VVOL. For example, a protocol endpoint on an iSCSI array is a LUN, and on a NAS server it is a volume. The point of all of this is to create a tighter relationship between your vSphere instance and your storage in order to ease the management burden of storage and increase its data integrity.
The VVOL Problem
The challenge with this is that you probably need to upgrade your storage to VVOL-certified storage to take advantage of this new functionality – and that’s probably not something you were ready to do just yet. In addition, only storage vendors’ newest products are VVOL-certified, which limits options and presents both a high acquisition cost and a high migration cost. This is why many people are pushing their VVOL plans to their next refresh.
Want VVOLS Now?
An alternative, however, is to switch to a product that can bridge your current storage and VMware to present your existing storage as a VASA Storage Provider without the cost of an upgrade. Traditional storage virtualization products can do this, but they do require placing themselves in the data path in order to do their job. Being in the data path means added latency and, more than likely, learning a new set of software features. A different approach is Primary Data’s DataSphere product that – like VASA – separates the control layer from the data layer. This allows DataSphere to add functionality (e.g. VASA, VVOLs), while allowing you to continue using your existing storage. This not only allows you to add VVOLs faster, but also enables all your storage to support your VVOLs.
VVOL technology sounds very promising, and VMware will continue to add functionality to it as time goes on. Those who begin using it now will be able to help shape the future of this promising technology. However, many companies are stuck in a multi-year depreciation cycle that doesn’t allow them to replace their hardware just yet. Primary Data allows innovators to move forward with this new technology while continuing to use their current storage investments, as well as gain a wealth of data mobility features not currently even on the VMware VVOL roadmap.