Today I have the pleasure of publishing a blog written by one of my colleagues at EMC, Drew Tonnesen. Drew works as a Senior Consultant Systems Engineer in EMC VMAX Engineering focusing on VMware and other virtualization technologies. He has been employed by EMC since 2006. When he isn’t guest blogging, he maintains his own blog about VMAX and VMware integration at https://drewtonnesen.wordpress.com.
This week at VMworld Barcelona, EMC has announced the upcoming support for VMware vSphere Virtual Volumes on VMAX3. In this post I am going take the opportunity to present the highlights of the integration, along with the step-by-step configuration required on the VMAX3 and VMware vCenter.
As the vVols framework has been covered in numerous VMware articles (great post by Ken here: https://blogs.vmware.com/virtualblocks/2015/04/13/virtual-volumes-and-the-sddc), I am going to assume a base understanding by the reader and move right into the VMAX3 implementation. Starting off with storage containers, these are created on the VMAX3 through Unisphere for VMAX 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.
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 + DSS, Silver, etc. The VMware Admin creates VM Storage Policies using Storage Policy-Based Management (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 vVols.
Unlike traditional devices, ESXi has no direct access to virtual volumes 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 that is mapped and masked to the ESXi hosts. It is much like a Gatekeeper device. When virtual volumes 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 virtual volumes, only one is required per host/cluster.
Figure 1 shows a graphical representation of vVols on VMAX3.
Figure 1. vVols architecture on VMAX3
Below I’ve highlighted a few important considerations about the VMAX3 implementation of vVols before going into the detail steps.
Scalability
VMAX3 supports 64,000 devices on an array. In a traditional VMFS environment, each ESXi host is limited to 256 devices, and as the hosts are usually grouped into clusters and share those devices (VMFS), there is little chance VMware will threaten the 64k array limit. vVols, on the other hand, are not limited by that 256 number and there is no sharing of vVols across hosts. Therefore the number of devices in a vVols environment will be far greater than a VMFS environment. It is important to remember, therefore, that both traditional devices (TDEVs) and vVols count toward that 64,000 device limit on the VMAX3.
Replication
An important thing to note about VMware’s first release of vVols is that it has no support for remote replication. There is no Site Recovery Manager nor any vendor replication such as SRDF. EMC, however, supports local replication through VM snapshots, which utilize the underlying VMAX3 TimeFinder SnapVX software, taking full advantage of the performance benefits of that technology. This means no additional virtual volumes are required when taking a VM snapshot, unless including the machine’s virtual memory which will produce 1 additional virtual volume. When a snapshot is restored, the VMAX3 creates and then deletes the necessary virtual volumes for the process.
Security
One last item to ease some EMC VMAX3 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, and as such there is a desire for bifurcation of tasks when it comes to virtualization and storage. 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 actual objects, he/she can only create them on datastores and using SLOs provided by the SA.
With the housekeeping complete, I’m now going to run through the basic steps for deploying vVols on VMAX3 which involves Unisphere for VMAX and the vSphere Web Client. For the sake of brevity, I’m assuming the VASA Provider vApp is already deployed. All Unisphere for VMAX activities are driven from a new vVols dashboard in Figure 2.
Figure 2. vVols Dashboard
Step 1: Provision the Protocol Endpoint from Unisphere for VMAX
We start by deploying a PE to our ESXi host. Under Common Tasks in Figure 1 we select “Provision Protocol Endpoint to Host”. The wizard has 2 steps: Select the initiator group and then select the port group (or create it on the fly). The VMAX3 will create both the PE device and masking view.
Figure 3. Provision PE
Step 2: Create Storage Container
Our second step (though step 1 and 2 could be reversed) is to create the Storage Container (SC). Using the Common Tasks in Figure 1 we select “Create Storage Container”. Again, there are just two steps here: Name the Storage Container and then add Storage Resources to the container. Each storage resource is an SLO with an amount of storage associated with it. You can add a resource for every SLO on the array. In Figure 4 I have added three resources.
Figure 4. Storage Container
Step 3: Register the VASA Provider
With the container created, we can move to the vSphere Web Client. Step 3 is to register the VASA Provider (VP). This can be accessed in the Storage Providers sub-menu of the Manage Storage tab. The URL is copied directly from the VP vApp home page and along with admin credentials, the VP is registered.
Figure 5. Register the VASA Provider
Step 4: Create a VVol datastore
After the VP is registered, the containers will be visible within the vSphere Web Client. Simply proceed to create a datastore in the usual manner, selecting the new “VVol” option as in Figure 6. Note I have also included in the screenshots the capability sets (SLO profile) that the datastore can provide. These are the very storage resources previously added to our container.
Figure 6. vVols datastore creation
Step 5: Storage Profiles
The final setup step for vVols is the creation of Storage Profiles. As shown in the previous step, the vVols datastore inherits the capabilities assigned to it in the container (storage resources). In order to ensure a VM is created with the proper SLO, Storage Profiles are used which are associated with the capability set. On the VMAX3, the Storage Profiles allow the user to associate the datastore capabilities with the SLO and workload (if applicable). Figure 7 demonstrates the rules available, Performance Index or SLO, and Workload Hints or Workload. Once the SLO and Workload are chosen, VMware will list the compatible datastores, if any. In this example, one of the capability sets is Gold with an OLTP workload so the datastore, VVol_VMAX3_Datastore, is seen as compatible.
Figure 7. VM Storage Policy
That’s it. You can now create a VM and by selecting the desired Storage Policy, it will be created with the correct SLO using storage from the proper storage resource in the container.
VMAX3 and vVols, the new storage paradigm is here!
