One of the key benefits of Virtual Volumes is the ability to control provisioning and data services at a VM-level. Why is VM-centricity so important and how does Virtual Volumes enable VMs to consume resources efficiently?
Essentially, with VM-centricity, Virtual Volumes eliminates a costly tradeoff that our customers have faced with traditional storage for many years. More specifically, as new applications are deployed, many of our customers have been required to either underprovision and fail to meet SLAs or overprovision and waste valuable resources (compute, storage, and network). Obviously, customers would choose to meet SLAs at the expense of overprovisioning and not consuming resources efficiently.
For instance, consider a three-tier application composed of VMs with different SLA requirements – gold, silver, and bronze. However, as its common in many customer environments, the storage resources available do match one-to-one with the VM requirements. In this case, there are only 2 LUNs available – gold and bronze. Therefore, customers would provision the gold VM in the gold LUN and the bronze VM in the bronze LUN. Now, when it comes to provisioning the silver VM, this is when customers must face a costly tradeoff. Do I provision the silver VM in the bronze LUN and fail to meet SLA or do I provision the silver VM in the gold LUN and waste resources? Naturally, the costly choice is to provision the silver VM in the gold LUN. So, if the gold LUN has replication turned on and even if the silver VM does not need to be replicated, it would be replicated because in traditional storage the operations are done at the LUN/Volume level.
However, with Virtual Volumes the costly tradeoff described above is eliminated because provisioning and data operations are performed at the VM level. Through the use of Storage Policy-Based Management (SPBM), vSphere Administrators can ensure that when a policy is assigned to a VM, the VM will be provisioned in the storage that will meet its requirements. Additionally, any data service operations such as replication, snapshot, etc would also be performed at the VM level. In the scenario of the three-tier application, vSphere Administrators would assign the required policy to each of the three VMs.
An analogy I like to use with customers to describe how Virtual Volumes changes the storage consumption model is to consider a fixed menu and an a la carte menu. Traditional storage is like a fixed menu – either you consume everything or nothing. In contrast, Virtual Volumes enables an a la carte consumption model. The Storage Administrator defines the menu (replication, backup, encryption, etc) and the vSphere Administrator then uses the elements in the menu to create policies and assign to VMs.
With Virtual Volumes, each VM will consume the exact resources needed – nothing less, nothing more.
