EMC will be talking about VVols at VMworld this week so for those of us not at the show I thought I would give a bit of a demo preview. I spoke about VVols at EMC World this year in my session, but at that time it was not a topic we were openly discussing and certainly not with any delivery dates. Now as we approach the end of the year, the VMAX3 is moving closer to supporting VVols. I’m not going to get into exact dates (though I think others at VMworld will) but it is coming.
Before I provide a demo of the functionality, let’s just do a high-level of what VVols are. VVols are a new storage paradigm that moves the management from the datastore level to the VM level. VVols map virtual disks, configuration files, swap, clones, and snapshots, directly to virtual volume objects on a storage system. This mapping allows VMware to offload more storage operations to the VMAX3, such as VM snapshots. VVols virtualizes SAN devices by abstracting physical hardware resources into logical pools of storage called Storage Containers. These containers are created on the VMAX3 through Unisphere and are assigned storage capabilities which can be all, or a subset, of the SLOs the particular VMAX3 array supports. These containers are presented to the vCenter when a VASA Provider is registered. The VASA provider is delivered by EMC as a virtual appliance and integrates with vSphere Storage Monitoring Service (SMS) to manage all aspects of the storage in relation to VVols. Here is how the VASA vApp appears:
From the presented Storage Containers, the VMware Admin creates datastores through the datastore wizard, just like a traditional datastore. A datastore has a 1:1 relationship with a storage container and is its logical representation on the ESXi host. A datastore holds VMs and can be browsed like any datastore. Each datastore inherits the capabilities of the container, i.e. SLOs – Bronze, Silver, etc. The VMware Admin creates VM Storage Policies (a.k.a. Storage Policy Based Management or SPBM) that are mapped to these capabilities so when a VM is deployed, the user selects the desired Storage Policy and is presented with compatible datastores in which to deploy the VM. The SLO paradigm of VMAX3 fits in perfectly with SPBM. Rather than have to setup policies for say disk type (e.g. SATA, EFD) and be left with only a basic performance profile (slow, fast), the SLOs are already how the VMAX3 manages performance and storage and we extend that to VMware VVols. I have an image below which demonstrates 8 steps to assign an SLO to a VM Storage Policy and how nicely the VMAX3 and VVols work together.
- Enter a name and description
- Select the VMAX3 VVol Provider to expose the SLOs on the array – all SLOs that the array supports will be available
- Add a Performance Index Rule which will permit you to select the desired SLO
- Select the diamond SLO (or an SLO assigned to the container)
- Add a Workload Hint – for VMAX3 that will be OLTP or DSS
- Select OLTP
- With the SLO and Workload assigned, move to the compatibility screen
- VMware automatically filters compatible datastores so that only the VMAX3 VVol datastore with the diamond SLO is shown
I do cover this in the demo, though as it does move quickly, I think it is important to understand the steps ahead of time.
Unlike traditional devices, ESXi has no direct access to VVols on the VMAX3. Instead, ESXi hosts use a proxy device called a Protocol Endpoint. A Protocol Endpoint (PE) is a special device created on the VMAX3 and mapped and masked to the ESXi hosts. It is much like a Gatekeeper. When VVols are created they are bound to one of these PEs. VMware uses these PEs to communicate with the volumes and the disk files the VVols encapsulate. By utilizing PEs, ESXi establishes data paths from the virtual machines (VM) to the virtual volumes. As a single PE can manage thousands of VMs, only a couple are required.
The image below is a high-level view of the VVol paradigm:
An important thing to note about VMware’s first release of VVols is that it has no support for replication. There is no Site Recovery Manager nor any vendor replication such as SRDF. This functionality is not in the VASA 2 provider and will not become available until VASA 3 which will be part of VMware’s second release of VVols. This of course will limit the first release’s usefulness in many production environments.
One last item before the demo to ease some minds. VVols involve both a storage role and a VMware role. In some companies these two roles are consolidated, but in most large enterprises these are distinct positions. The storage tasks – creating the storage containers, assigning SLOs and storage amounts, and creating and deploying the PEs – provide the storage admin (SA) full control over the type (SLO) and amount of storage presented to the VMware environment. Though the VMware administrator, through normal activities (e.g. deploying a VM), is creating the VVol devices, he/she can only create them on datastores and using SLOs provided by the SA.
I hope all that information makes the demo more coherent as it does have to move quickly sometimes.