Raj Chelur Siddalingaiah

Doing more with less – VVols and Simplified Storage Management

Blog Post created by Raj Chelur Siddalingaiah Employee on Aug 26, 2016

A question recently came up from a customer during a demo of the VVols feature in Nimble OS 3.0 release. After a couple of storage admin tasks, and couple of vSphere admin tasks, we got to create Virtual Machines and power them on. At this point, the customer was surprised how we got to this so quickly asked “Wait, where do I setup storage access control, before all this can work?” It was only logical to respond with: “Do you really want to set that up yourself? Wouldn’t you be happy that’s done for you?"

 

This is just one example of how VMware VVols and Nimble Storage implementation helps users do more with less - by automating several mundane tasks and improving the interaction between vSphere admins and storage admins.

 

This blog entry is the first in a series of technical deep dives into the Nimble Storage implementation of VVols. The series aims to highlight the real world benefits of VVols and unique features in the Nimble Storage implementation that realize the benefits. For further details about the architecture, refer to the VMware blogs - VVol primer and SPBM overview.

 

In this blog entry, we’ll cover the three steps required to start using VVols. The initial two steps are addressed using the Nimble Storage UI.  The final step before creating virtual machines is addressed using the vCenter UI. Naturally, which administrator (Storage, Virtualization, or Generalist) completes each of these steps will be specific to your environment.

 

Step 1: VASA Provider and Registration

 

Nimble’s VASA Provider is an implementation of vSphere APIs for Storage Awareness (VASA) specification. The VASA Provider allows vCenter and ESX to understand and manage the storage topology, the capabilities of the storage system and access to each VVol.

 

The VASA Provider is included in the Nimble OS and runs on the group leader. This is a key benefit for multiple reasons:

 

  • Utilizes the service high availability infrastructure of Nimble OS
  • Scales as the datacenter grows
  • Data and metadata is co-located and always available

 

In addition, the VASA Provider registration is centralized in the Nimble UI. The storage administrator can manage the VASA Provider, and the vCenter Plugin for thick client and the web client from a central location (Administration > VMware Integration).

vcenter-register.png

When this task completes, the communication channel between the vSphere components (vCenter server & ESXi) and the Nimble Storage array has been established. The vCenter server now has the ability to query the capabilities of the Nimble Storage system. However, it does not yet have access to storage capacity. On to the next step …

 

Step 2: Folder creation

 

The administrator delegates a certain amount of storage to be utilized by a vSphere environment for VVol use. A new storage construct – “Folder” is available in Nimble OS for this purpose. A folder is a logical unit of capacity and will be the backing storage object for a VVol datastore.

new-folder.png

Here the administrator chose to allocate 2 TB with the name eng-builds to vCenter server named production-vc.

 

In an environment with multiple vCenter servers, like a production and test environment for example, the administrator allocates and assigns a separate VVol folder for each vCenter server.

 

Multiple VVol folders can be assigned to the same vCenter server as well, for multi-tenancy deployments. vCenter Server RBAC can then be utilized to control access to the VVol datastores.

 

Step 3: Mounting VVol datastores.

 

The administrator has access to the capacity allocated to the vCenter server by the storage administrator. The Create Datastore wizard is used to choose VVol as the type of the datastore and the hosts and clusters to which the datastore should be accessible.

mount-datastore.png

Behind the scenes, Nimble’s VVol implementation simplifies and automates secure access to storage from the vSphere environment during this operation.

 

Each pool in the Nimble Storage system has an automatically provisioned Protocol Endpoint (PE) when the first VVol folder is created. IO for all VVols in the pool flows through this PE. By default, no ESXi host has access to this PE.

 

Each ESXi host that the VVol datastore is mounted on establishes a VASA session with the provider. Certificate authentication is used to secure this communication. Once the session is validated, the provider creates an initiator group for each ESXi host, and an access control entry to the PE. The PE is now accessible to the ESXi host, but the host needs to rescan.

 

Instead of depending on the administrator to initiate this, Nimble’s provider generates a VASA event that signals the host to rescan and recognize the PE.

 

So, the act of creating a VVol datastore has fully setup a secure data access path.

 

Creating Virtual Machines

 

At this point the vSphere environment has been fully configured for VVol use.  Familiar Virtual Machine management workflows can now be leveraged to create and manage the VMs using the vCenter UI. In addition, administrators can utilize the capabilities of Nimble OS through vCenter server’s policy based management engine. Because Nimble Storage’s implementation of VASA maps a volume to a  VMDK, vCenter  administrators have an extremely fine grained control over storage configuration such as; performance, encryption, space savings (compression and dedupe), snapshots, and replication.

 

While we covered how an ESXi host gains access to a PE, we haven’t covered how an ESXi host gains access to an individual VVol. This is done through a VASA operation called “bind”. The automatically created initiator group described earlier is used to provide access control to a specific VVol.  This ensures that a host only sees the VVols that it has explicitly “bound” to.

 

The bind operation can be thought of as the “open” function on a VMFS datastore. For example, the bind command is issued when a VM is created, a VM is powered on, a virtual drive is added to a VM, and etc.  The unbind operation can be thought of as the “close” function on a VMFS datastore. For example, the unbind operation is issued when a VM is powered off or when a virtual disk is removed from a running virtual machine.

 

Conclusion

 

In this blog entry we’ve described the three simple steps required to start provisioning VVol based virtual machines on Nimble Storage.  We’ve also “pulled the covers back” and explained some of the inner workings of Nimble Storage’s VASA implementation. Subsequent blogs in this series will dive into the VM granular capabilities provided by Nimble Storage VVol implementation.

Outcomes