The APIs provided by VMware allow administrators and publishers to extend the functionality of vSphere 5.
vStorage API for Array Integration
The vStorage API for Array Integration (VAAI) is a set of application program interfaces allowing interoperability between VMware and storage array manufacturers to communicate with VMware in a smarter manner. Some tasks can be offloaded to the storage array, which lightens the load of ESXi hosts.
Note
Processor manufacturers have already integrated Intel VT and AMD V instructions into their chips to reduce high-consuming CPU interceptions. What processor manufacturers have done for servers, VAAIs do for storage arrays. These APIs now seem
indispensable to obtain high levels of consolidation.
Table 3.4 lists the VAAI in vSphere 4.1 and VAAI 2 in vSphere 5.
Table 3.4. VAAI Functionality: vSphere 4.1 Versus vSphere 5
Following is a brief description of each of the features listed inTable 3.4:
LUN level. With the API, the work is done at the block level instead of the LUN level, which causes fewer issues related to SCSI reservations and reduces VM startup time, in particular for virtual desktop infrastructure (VDI) projects.
• Hardware Accelerated Zero: Without the API, when creating a datastore, the “zero write” is done by the server, which sends SCSI commands to the storage array. With the API, a single command is initiated by the ESX server, and the storage array is responsible for repeating the operation and informing the ESX server when the operation is finished. This reduces traffic between the ESXi server and the storage array.
• Hardware Accelerated Copy: Without the API, copy operations are performed from the ESX server toward the storage array. With the API, data is moved within the array by the storage array without going through the server. This reduces the load of the ESXi server and the time required for data migration.
In vSphere 5, new primitives have been defined for VAAI 2:
• Dead Space R eclaim: Allows the recovery of spaces that are no longer used when a virtual disk is deleted or after the migration of a virtual disk from one datastore to another by using Storage vMotion on a provisioned thin LUN. ESXi 5.0 transmits the information about the freed-up blocks to the storage system via VAAI through commands, and the storage system recovers the blocks.
• Thin Provisioning Out of Space API: Guards against storage-space problems on thin LUN s.
• Thin Provisioning LUN Reporting: Enables the identification of the storage array use in vCenter.
• Quota Exceeded: Displays an alert in vCenter when a capacity threshold is passed within a datastore.
• Out of Space Behavior: The VM determines whether the space is available before the write. If storage space is full, an alert message is displayed in vCenter and this VM is paused (while the other VMs continue running).
The following primitives are defined for NAS VAAI storage:
• Full-File Clone: Enables cloning and snapshot operations of vmdk files to be performed by the NAS in a cold manner, similar to VMFS block cloning (Full Copy).
• Extended Stats: Enables the visibility of consumed spaces on NFS datastores.
• Space R eservation: Allows the creation of vmdk files in thick-provisioning mode for NAS storage.
vSphere Storage API: Storage Awareness
The vStorage API for Storage Awareness (VASA) is a storage-detection API. It allows the visualization, straight from vCenter, of the information related to storage arrays, such as replication, RAID type, compression, de-duplication, thin or thick format, disk type, snapshot state, and performance (IOPS/MBps). Among other things, the vStorage API is used for Profile-Driven Storage.
Multipathing
switches, to create logical paths between a server and a storage device. Pluggable Storage Architecture
Pluggable Storage Architecture (PSA) is a collection of APIs that allows storage manufacturers to insert code directly into the VMkernel layer. Third-party software (for example, EMC
PowerPath VE) can thus be developed to offer more advanced load-balancing functionalities in direct relation to their storage array’s technology. VMware, however, offers standard basic multipathing mechanisms, called native multipathing (NMP), divided into the following APIs: Storage Array Type Plug-in (SATP), which is in charge of communicating with the storage array; and Path Selection Plug-in (PSP), which provides access to load balancing between paths.
As shown inFigure 3.22, VMware offers three PSPs:
• M ost R ecently Used (M R U): Selects the first path discovered upon the boot of ESXi. If this path becomes inaccessible, ESXi chooses an alternate path.
• Fixed: Uses a dedicated path designated as the preferred path. If configured otherwise, it uses the path found at boot. When it can no longer use this path, it selects another available path at random. When it becomes available again, ESXi uses the fixed preferred path again. • Round R obin (R R ): Automatically selects all available paths and sends the I/O to each in a circular fashion, which allows basic load balancing. PSA coordinates NMP operations, and third-party software coordinates the multipathing plug-in (MPP) software.”
The NMP Round Robin path-selection policy has a parameter known as the I/O operation limit, which controls the number of I/Os sent down each path before switching to the next path. The default value is 1000; therefore, N MP defaults to switching from one path to another after sending 1000 I/Os down any given path. Tuning the Round Robin I/O operation limit parameter can significantly improve the performance of certain workloads (such as online transaction processing [OLTP]). In environments that have random and OLTP workloads, setting the Round Robin parameter to a lower number yields the best throughput, but lowering the value does not improve performance as significantly as it does for sequential workloads. For these reasons, some hardware storage companies recommend that the N MP Round Robin I/O Operation parameter should be lower (can be set to 1).
Third-party software solutions use more advanced algorithms because a limitation of Round Robin is that it performs an automatic distribution without taking into account the actual activity at path level. Some software establishes dynamic load balancing and is designed to use all paths at all times rather than Round Robin, which uses only a single path at a time to bear the entire I/O burden. M odes
Access to data stored on shared storage space is fundamental in a virtual environment. VMware strongly recommends implementing several access paths to the LUN . Two paths is a minimum, but VMware recommends using four. Multipathing reduces service interruptions by offering a
redundancy of access paths to the LUN s. When a path is not available, another is used—without service interruption. These switch mechanisms are called multipath I/O (MPIO).
In VMware, as shown inFigure 3.23, storage can adopt various modes:
• Active/active: At a given moment, a LUN is connected to several storage controllers at the same time. The I/O can arrive from several controllers simultaneously.
• Active/passive: At a given moment, a single controller owns one LUN (owned LUN ). N o other controller can send I/O to this LUN as long as it is linked to a controller.
• ALUA: Access to a LUN is not direct (nonoptimized) but occurs in an asymmetrical manner, going through the secondary controller.
Figure 3.23. Storage modes.