In this NetApp tutorial, you’ll learn about VMware terminology, which is specific to storage. That’s VAAI, VASA, and Multi-Path Plugins (MPP). Scroll down for the video and also text tutorial.
NetApp VMware Storage – VAAI, VASA, and MPP Video Tutorial
I have been in a couple of classroom Netapp Bootcamp trainings but this course is much better and in-depth. It takes you from the core to the nitty gritty.
VAAI: vSphere API for Array Integration
Starting off with VAAI, which is the vSphere API for Array Integration. This utilizes communication between the ESXi hosts and the storage system. vSphere can offload some functions to storage systems, such as virtual machine cloning.
So if you've got a virtual machine, which is already set up in vSphere, and you want to make a clone of that, you can use VAAI for that. Also, if you're deploying a new virtual machine from a template and also Storage vMotion.
Offloaded functions have better performance. The offloaded functions take place directly on the storage system without having to be processed by and passed through the ESXi host. Again, on the next couple of slides, I'm going to show you how this is going to aid the performance.
VAAI is built-in for SAN protocols on supported storage systems. For NAS protocols, it's NFS that is supported by vSphere. That requires a software plugin to be installed.
SAN Storage vMotion Without VAAI
Let's see how VAAI improves performance by first looking at what happens when we don't have it enabled, and I'm going to use Storage vMotion for this example. Storage vMotion is where you can move a virtual machine from one ESXi host to another ESXi host. So, you're moving the ESXi that the virtual machine is running on.
With Storage vMotion, what you're doing there is moving the virtual machines files from one datastore to a different datastore.
We're going to do our Storage vMotion in this first example. We do not have VAAI enabled. When we do that, you can see that I've got my ESXi host, which is running VM1, and I want to move the virtual machine's files from Datastore 1 to Datastore 2 on the same storage system.
So I run that Storage vMotion, and what is going to happen is the files are going to be passed through the ESXi host on the way from one datastore to the other datastore. That is going to take up resources on the ESXi host, and it's also going to take up network bandwidth as well.
SAN Storage vMotion with VAAI
Now, let's look at what happens when we do have VAAI enabled. When this happens, the ESXi host sends the command to the storage system, and the migration is going to happen directly on the storage system.
Rather than passing through the ESXi host, the files move from one datastore to the different datastore on that same storage system, directly on the storage system, without having to go through the ESXi host. So, you can see that we offloaded that function from the ESXi host. It literally puts less load on the host, which is going to aid performance.
With VAAI, it's going to work for Storage vMotion. Also, other functions, like if we are cloning a virtual machine or deploying a virtual machine from a template. Again, that traffic won't have to go through the ESXi host. It's going to be done directly on the storage system. VAAI utilizes communication between the ESXi host and the storage system.
VASA: vSphere for Storage Awareness
Next up is VASA, which is the vSphere API for Storage Awareness. Where VAAI is between the host and the storage system, VASA utilizes communication between the vCenter server and the storage system.
With VASA, vCenter learns the capabilities of the storage, such as the disk types that are available there, whether thin provisioning is available on the storage system or not, if storage efficiency is available, meaning deduplication and compression, and also if replication is available for redundancy for replicating our data from one storage system to another.
Your vCenter server is going to learn that information, and then that information can be used in Storage Policies. With these Storage Policies, you can choose the required capabilities of the storage when provisioning virtual machines.
So you could, for example, have a high-performance profile, and you could also have a low-performance storage profile. When you created a virtual machine that required high-performance, you would say, "I want to use the high-performance storage profile for that," and it will get high-performance capabilities on the storage system.
Then, your low-performance virtual machine that doesn't require that high performance will get the lower performance capabilities.
This provides simplicity and reduces errors because you set up the storage policy once, then select it whenever you create a VM. So rather than every time you create a VM, you have to individually configure the storage settings for that VM. You just use policies that are set up ahead of time.
Then, when you provision the VM, you just specify the profile that you want to use. So rather than doing it individually each time, you're going to get more consistency there. Thus, you're going to have less errors, and that's going to mean that you have to do less troubleshooting.
Health and capacity information can also be provided to vSphere as well. That information can be viewed from the vCenter server, rather than having to see it on the storage system, which can make administration easier.
MPP: Multi-Pathing Plugins
The last one that I want to talk about here is MPP, which is Multi-Pathing Plugins. MPPs allow SAN storage traffic to flow over multiple paths. There are two components of MPPs, that's PSPs and SATPs.
PSP is the Path Selection Plugin, which selects the best path. For example, if you've got a 4-node cluster, and the LUN is on Node 1, we would like the ESXi host to choose a path that terminates on Node 1, not one that terminates on Node 4. PSP will control that.
SATP is the Storage Array Type Plugin. That handles failover and error detection. If a path goes down, we're going to need to detect that it's gone down and failover to another path. It's SATP that handles that.
PSA is the VMware Pluggable Storage Architecture. This is a collection of APIs that allow storage vendors like NetApp to design their own MPPs, PSPs and SATPs, which optimize load balancing and failover, and are specifically designed for their storage systems. So it's the best settings optimized for that particular storage system.
NMP is the Native Multipathing Plugin. That is the default MPP from VMware, which is built into ESXi hosts.
Path Selection Policy and Storage Array Type Policy can be found in the vSphere settings for an ESXi host connection to a datastore.
The default Path Selection Policy options are:
- Fixed – Always use a particular fixed path.
- Round Robin – Can load balance over two separate Fabric A and Fabric B connections.
- Most Recently Used
Deploying the NetApp NFS Plug-in for VMware VAAI: https://docs.netapp.com/ontap-9/index.jsp?topic=%2Fcom.netapp.doc.exp-nfs-vaai%2FGUID-957FAFF3-5F52-487B-9187-5F9C68C45B3C.html
What VAAI offloaded operations are supported by Data ONTAP?: https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/What_VAAI_offloaded_operations_are_supported_by_Data_ONTAP%3F
VASA Provider for Clustered Data ONTAP Overview: https://library.netapp.com/ecmdocs/ECMP12405937/html/GUID-2478BE29-CA8B-40E9-ADB7-F2EF6DFDD323.html
Power Methods for Configuring Multipath: https://library.netapp.com/ecmdocs/ECMLP2439710/html/GUID-FB24621A-D517-40FB-9D54-CFB52C8E5E8E.html
Text by Libby Teofilo, Technical Writer at www.flackbox.com
With a mission to spread network awareness through writing, Libby consistently immerses herself into the unrelenting process of knowledge acquisition and dissemination. If not engrossed in technology, you might see her with a book in one hand and a coffee in the other.