Looking for Expert Advice?
We're here happy to help
I recently attended the Netapp Insight conference in Las Vegas. There were a lot of great speakers and sessions but for my money, the best one was Best Practices and Deep Dive for VMware with SolidFire. The presenter for this session was Andy Banta, his title was Storage Janitor. Here’s a pic of Andy.
When your presenter looks like this and chooses that title, you know you’re about to get some knowledge dropped on you! This man did not come all the way to Vegas to read you the datasheet.
If you’re not familiar with SolidFire here is a quick overview:
It’s a very cool solution but I knew that walking in. What I wanted to know more about was, how it would fit in most of the enterprise environments we work with. Certainly, we have clients looking to take a Service Provider stance and leverage automation tools but the vast majority are running good old VMware.
A lot actually but the most impressive capability was their implementation and support of VVols. In a nutshell, VVols provide much tighter integration between ESX and external storage arrays. The arrays become VM aware, meaning you can apply array based tools like Snapshots, Cloning and Replication at the VM level rather than LUNs. This is a huge and immediate win.
VVols are an excellent concept and have the potential to greatly simplify the storage aspects of a virtual environment. The problem has been that most vendors haven’t done a good job of enabling these capabilities. Either the implementation is limited or it adds a great deal of complexity. VVols are supposed to make things simpler not more complicated. It’s in the simplicity where SolidFire shines.
VVol Components and SolidFire Implementation
If a storage vendor wants to support VVols, they need to develop a VASA provider. The VASA provider is the control mechanism for VVols.
To be clear, the VASA provider is not a management interface, it is a critical piece of the VVol implementation and although storage will continue to function without the VASA provider, you cannot change the environment or leverage array based capabilities.
The SolidFire implementation is integrated, a VASA provider is installed on each node in the cluster. This is a simple, elegant approach that provides maximum availability. From a SolidFire customer perspective, this means you don’t have to worry about the VASA Provider, it is built in, not an external system you need to manage.
Protocol Endpoints are how ESX accesses Virtual Volumes. ESX uses Protocol Endpoints (PE) to establish a data path on demand from virtual machines to their respective virtual volumes. The VMware documentation refers to a PE as a logical IO proxy. It is up to the storage vendor to determine how to implement Protocol Endpoints, how many endpoints to create and how they are distributed. SolidFire creates one PE per node. This has been validated to provide optimal performance. Again, you’re not being asked to manage anything new, it is built in.
Much of the information available describes Storage Containers as VVol Datastores. They are comparable in that both can be used to logically group VMs but there are some significant differences. VMFS Datastores are physical constructs, they are file systems. They are limited in terms of size and due to the overhead associated with metadata locking, they are limited in terms of how many VMs can share a Datastore. Point being, most environments will have many Datastores, not because it makes it easier to manage but because it is necessary to support the volume of data and IO required. You have to manage the datastores, you have to size and expand them, you may have to balance the VMs across them. This is not true with Storage Containers, at least not the way they are implemented on SolidFire. With SolidFire, Storage Containers are a logical construct. You can divide your storage into multiple containers if you want to isolate storage for administrative purposes but otherwise you only need one container. All the storage exists in this container. If you add capacity, the container expands automatically, nothing for you to do.
As we already mentioned, one of the biggest benefits of SolidFire is their QoS capabilities. With VVols we can apply QoS to the individual VMs or Virtual disk rather than LUNs. What’s more, QoS can be applied from ESX through Storage Based Policy Management. Policies defined and set within SBPM are automatically passed through the VASA provider and applied to the underlying virtual disk. Using this framework, managing the QoS settings across a range of VMs and virtual disk is not only practical, it’s simple.
So, in terms of implementing VVols with SolidFire, you don’t have to worry about the VASA provider, you don’t have to do anything with the Protocol Endpoints and you can choose to use one or more storage containers but there is really no management required. With the VVol framework in place you can apply SolidFire’s QoS capabilities from an application rather than a storage perspective and do it all from within the native VMware Management tools.
A couple of last notes. There are multiple ways to consume SolidFire. You can buy the storage itself, it is offered as a converged solution with Flexpod SF and it is the foundation of Netapp’s HCI solution. All the capabilities mentioned here, work the same iin all three flavors. They also offer some flexible licensing options that you can read more about on the SolidFire page.
Thanks to Andy for a great session! If you want to follow him, here is his Twitter handle. @AndyBanta