We recently installed a Solidfire cluster in one of our multi-tenant environments. I figured it would be a good idea to test the use of Virtual Volumes (VVols), since SolidFire touts easy integration for VVol use. SolidFire has a great VVols configuration guide, so I used that as a jumping off point. First of all, enabling VVols on the SolidFire is crazy simple. From the cluster settings, you can simply click the “Enable Virtual Volumes” button.
You get a nice warning that this is a permanent change and that VVols are only compatible with ESX 6+. While you can’t disable VVols on the SolidFire cluster after you go through with this, enabling VVols in no way removes any other configurations you currently have. It solely adds the VVols functionality to your cluster.
Once VVols are enabled, the area where the buttons appeared now displays a VASA Provider URL. The VASA Provider is basically a set of APIs that allow vSphere to communicate with the storage array. Unlike VMFS, VVols are not a file system, and all the underlying functionality is performed on the array itself. The VASA provider just helps vSphere with the translation. SolidFire built their VASA provider into the cluster itself, so unlike some other vendors it is not a virtual appliance and it has built-in redundancy via the cluster.
Log in to the web client and navigate to vCenter server -> Manage -> Storage Providers to add a new provider for the SolidFire. Give it a name, creds and paste in the VASA Provider URL.
Once added into vCenter, you can see some basic info about the cluster in the web client. The next step is to create a Storage Container, which is essentially a logical container that can be presented to vSphere as a datastore. This container does not have any storage properties at all, it is just a location for the array to group the VVols that will be created in this particular container.
Now that a Storage Provider exists, a VVol Datastore can be created in vSphere. The process is exactly the same as creating a VMFS or NFS datastore, but in this case you select VVOL as the type. Provide the new datastore with a name and select the Storage Container which will back this datastore. Any Storage Container that has been created on SolidFire should appear in here, and there is a one-to-one relationship between Storage Containers and vSphere datastores.
Once the datastore is created, the next step is to create a Storage Policy in vCenter that will assign certain characteristics to our storage. At this point, we haven’t really created anything on our storage other than logical containers. The containers don’t currently have any properties such as disk type, space allocation, deduplication, etc. that a typical LUN or Volume would have. A Storage Policy can be created to define which type of storage we would like our VVols to be reside on. These policies are defined by the VASA provider, and vary between storage vendors and models. With SolidFire, the special sauce (and basically the only sauce) is QoS. SolidFire is an all flash array, so there is no need to have different levels of storage quality based on disk type. The VASA provider allows for the creation of policies that define QoS, just as you would when creating SolidFire volumes directly on the cluster. In this case you can define your tiers of service based on IOPs levels that you assign to different policies.
Once your service level policies are in place, you can also add tag-based rules so that you can ensure certain workloads live within particular storage containers. At this point SolidFire is ready to run VMs on VVols! The great thing is that not only can you define a storage policy per VM, but also per VM disk. So if you want the OS disk to have a lower level QoS than say, a SQL DB disk, go ahead and switch the storage policy at the VM disk level and the array instantly makes the changes behind the scenes.
SolidFire certainly makes it very easy to get up and running with VVols. Once a VM is provisioned to a VVol datastore, you can see the VVols themselves within the SolidFire admin GUI. Since there are at least three VVols for every powered on VM, the filter option is very handy for drilling down to exactly what you want to see.
The only downside so far to VVols on SolidFire is the lack of VASA capabilities outside of QoS. Each datastore you create exposes the full capacity of the SolidFire array to vSphere, so you have to be careful when deploying a lot of VMs. Currently, I don’t have VVols exposed to our multi-tenant cluster because I need a maintenance window (and motivation) to create iSCSI networking on those hosts. vCloud Director will allow Org VDC storage policies that can put a limit on the datastore assigned to a particular Org. Sounds like a good reason for a “part two” blog post down the road…
