In this post, we’ll talk about vSphere Storage APIs for Storage Awareness (VASA), vSphere Storage APIs Array Integration (VAAI) etc. in VMware vSphere 7.0. This post covers Objective 1.3.2 of VMware 2V0-21.20 Exam Preparation Guide where we’ll learn about the different storage APIs such as VASA and VAAI.
In a vSphere 7.0 virtual environment, VMware introduce several options for integrating with supported storage solutions including vSphere APIs for Storage Awareness (VASA), vSphere APIs for Array Integration (VAAI), and Virtual Volumes (vVols).
vSphere APIs for Storage Awareness (VASA)
Storage providers (vendors) or VMware can make use of VASA where Storage providers (VASA providers) are software components that integrate with VMware vSphere to provide information about the physical storage capabilities. Storage providers are utilized by either ESXi hosts or vCenter to gather information about the storage configuration, status, and display it to administrators in the vSphere Client. There are several types of storage providers that can support VMware vSphere 7:
- Persistent storage providers: Manage storage arrays and handle abstraction of the physical storage. vVols and vSAN use persistent storage providers to offer their services.
- Data storage providers: Uses host-based caching, compression, and encryption features.
- Built-in storage providers: VMware offers these type of storage providers and usually do not require registration. vSAN and I/O filters included in ESXi installations are examples of built-in storage providers.
- Third-party storage providers: A third-party storage provider must be registered in the vSphere Client and the information that storage providers offer may include the following:
- Storage data services and capabilities that are referenced when defining a storage policy
- Storage status, including alarms and events
- Storage DRS information
Storage providers must be registered in the vSphere Client to establish a connection between vCenter and the storage provider. VASA will be essential when you are working with vSAN, vVols, vSphere APIs for I/O Filtering (VAIO), and storage VM policies.
vSphere APIs for Array Integration (VAAI)
VAAI is a hardware acceleration or hardware offload APIs that enable ESXi hosts to communicate with storage arrays while using functions called storage primitives that allow offloading of storage operations to the storage array itself. The main purpose of this is to reduce overhead and increase performance.
The following are some features of VAAI primitives for block storage:
Also Read: What is VMware vSphere+? A Comprehensive Guide to Modern Virtualization
- Atomic Test and Set (ATS): ATS Replaces the SCSI reservations usage on VMFS datastores when updating metadata. With SCSI reservations, only one process can establish a lock on the LUN at a time, leading to contention and SCSI reservation errors. Metadata updates occur whenever a thin-provisioned disk grows, a VM is provisioned, or a vSphere administrator manually grows a virtual disk. With ATS, a lock is placed on a sector of the VMFS datastore when updating metadata. ATS allows larger datastores to be used without running into such contention issues. On storage arrays that do not support VAAI, SCSI reservations are still used.
- XCOPY (Extended Copy): Allows the VMkernel to offload cloning or Storage vMotion migrations to the storage array, avoiding use of the VMkernel Data Mover service.
- The following are the features of VAAI primitives for NAS:
- Full File Clone: Works the same way as XCOPY but applies to NAS devices as opposed to block storage devices.
- Fast File Clone/Native Snapshot Support: Allows snapshot creation to be offloaded to the storage device for use in linked clones used in VMware Horizon View or in vCloud Director, which leverage reading from replica disks and writing to delta disks.
- Reserve Space: Allows thick provisioning of virtual disks on NAS datastores. Prior to this primitive, only thin provisioning could be used on NAS storage devices.
- The following are the features of VAAI Thin Provisioning primitives:
- If you are using thin provisioning, and VMs are deleted or migrated off a datastore, the array may not be informed that blocks are no longer in use.
- Thin Provisioning Stun: Prior to vSphere 5.0, if a thin-provisioned datastore reached 100% space utilization, all VMs on that datastore were paused. After the release of vSphere 5.0, only the VMs requiring extra space are paused, and other VMs are not affected.
- Thin Provisioning Space Threshold Warning: When a VM is migrated to a different datastore or is deleted, the SCSI UNMAP command is used for the ESXi host to tell the storage array that space can be reclaimed.
Virtual Volumes (vVols)
vVols is a storage operational module that is similar to vSAN where you can leverage SAN and NAS arrays. With vVols, you can leverage SPBM that allows you to streamline storage operations. The VASA provider communicates with vCenter Server to report the underlying characteristics of the storage container. You can leverage these characteristics as you create and apply storage policies to virtual machines to optimize the placement and enable the underlying services (such as caching or replication).
The main use case for vVols is to simplify the operational model for VMs and their storage. With vVols, the operational model changes from managing space inside datastores to managing abstract storage objects handled by storage arrays.
Also Read: VMware Private AI: A New Dawn in Generative AI for Enterprises
Figure: Thanks to Pearson IT Certification
Pluggable Storage Architecture (PSA)
PSA was initially introduced in vSphere 4 as a way for storage vendors to provide their own multipathing policies, which users can install on ESXi hosts. PSA is based on a modular framework that can make use of third-party multipathing plug-ins (MPPs) or the VMware-provided Native Multipathing Plug-in (NMP).
Figure: Thanks to Pearson IT Certification
VMware NMP
VMware NMP supports all storage arrays listed on the VMware storage HCL and provides a default path selection algorithm based on the array type. It associates a set of physical paths with a specific storage device (LUN). NMP uses submodules, called Storage Array Type Plug-ins (SATPs) and Path Selection Plug-ins (PSPs).
NMP performs the following operations:
- Manages physical path claiming and unclaiming
- Registers and unregisters logical devices
- Maps physical paths with logical devices
- Supports path failure detection and remediation
- Processes I/O requests to logical devices:
- Selects an optimal physical path
- Performs actions necessary to handle path failures and I/O command retries
- Supports management tasks, such as resetting logical devices
There are 2 sub-modules of VMware NMP:
Storage Array Type Plug-ins (SATPs)
SATPs are submodules of the VMware NMP and are responsible for arrayspecific operations. The SATP handles path failover for a device. ESXi offers an SATP for every type of array that VMware supports. ESXi also provides default SATPs that support non-specific active/active, active/passive, ALUA, and local devices.
Each SATP performs the array-specific operations required to detect path state and to activate an inactive path. This allows the NMP module to work with multiple storage arrays without being aware of the storage device specifics.
Path Selection Plug-ins (PSPs)
VMware PSPs are submodules of NMP. PSPs handle path selection for I/O requests for associated storage devices. NMP assigns a default PSP for each logical device based on the device type. You can override the default PSP.
