July 03, 2015

Pluggable Storage Architecture (PSA)

PSA - (Storage API - Multipathing)

With a SAN, to improve availability, the administrator can create multiple, redundant paths between hosts and storage targets or LUNs. However, multiple, redundant paths can introduce confusion if not properly managed. Multipathing software was created to minimize the confusion. Multipathing software takes control of all I/O requests; it chooses the best path for data transmission and manages path failover if an active path becomes unavailable.

The multipathing software in ESXi is known collectively as the Pluggable Storage Arctitecture (PSA). The PSA is used to manage storage multipathing in ESXi. It is an open, modular framework that coordinates the simultaneous operation of other multipathing plug-ins (MPPs) created by VMware and/or third-party software developers.

Pluggable Storage Architecture (PSA)
vSphere Pluggable Storage Architecture (PSA) Framework is a special VMkernel layer in vSphere that manages storage multi-pathing. It is a collection of VMkernel APIs that allow storage partners or third-party software developers to enable and certify their arrays asynchronous to ESXi release schedules. Using PSA, partners can design their own load balancing techniques and failover mechanisms for a particular storage array.

When a virtual machine sends a SCSI command to access data on a SAN, the VMkernel needs to know how to access the storage and which path it should choose. PSA manages this function and defines how multipathing works within vSphere.

PSA enables the delivery of performance-enhancing, multipathing and load-balancing behaviors that are optimized per array.

“The PSA acts as a base for two types of storage plug-ins: VMware’s Native Multipathing Plug-in (NMP) and a third-party vendor’s Multipathing Plug-in (MPP). NMP itself acts as a management layer for additional sub-plug-ins: Storage Array Type Plug-in (SATP) and Path Selection Plug-ins (PSP).”

The PSA performs two primary tasks:
  1. Discovers available storage and the physical paths to that storage.
  2. Assigns each storage device a Multipathing Plug-in (MPP) by using predefined claim rules
Since multiple MPP’s cannot manage the same storage device, claim rules allow you to designate which MPP is assigned to which storage device.

“PSA discovers the storage and figures out which multipathing driver will be in charge of communicating with that storage. All the error codes, I/O requests, and I/O queuing to the HBA will be handled by the MPP."

Third-party vendors can create and integrate SATPs and PSPs that run alongside VMware’s SATP and PSP.

  • Pluggable Storage Architecture (PSA)
  • introduced in vSphere 4.0
  • a set of APIs
  • manages storage multipathing
  • enables the function of MPPs, NMPs, SATPs and PSPs
  • allows third-party storage vendor to add code for managing multipathing and access in ESXi
  • sits in the SCSI middle layer of the VMKernel I/O Stack
  • coordinates the operation of the VMware NMP and third-party MPP
Before PSA, the only multipathing options were VMware’s Fixed or Most Recently Used (MRU) policies. The Pluggable Storage Architecture gave third-party storage vendors a means to add policies and to recognize the type of storage deployed.

VMware PSA namespace:

PSA Overview
The PSA consists of plug-ins (MPP and NMP) and sub plug-ins (SATP and PSP):
  • Multipathing Plug-in (MPP)
    • These are provided by third-party vendors. An example of of a MPP is EMCs PowerPath/VE. VMware’s Native Multipathing Plug-in is also an MPP.
  • VMware Native Multipathing Plug-in (NMP) – Handles overall MPIO (multipath I/O) behavior and array identification
    • Storage Array Type Plug-ins (SATP) – also called Storage Array Type Policy
      • Determines and monitors the physical path states to the storage array
      • Activates new physical paths when the active path(s) has failed
      • Handles path failover for a given array and determines the failover type for a LUN
      • Allows the NMP to be modular by hosting rules on how to handle array-specific actions or behavior as well as any specific operations needed to manage array paths
        • Additional modules for new arrays can be added in the SATP without changing the NMP
      • Perform any other necessary array specific actions required during a storage fail-over
    • Path Selection Plug-in (PSP) – also called Path Selection Policy
      • Handles path selection for a given storage device
      • If the active path fails, PSP determines the next path to use for I/O requests
"PSA selects an MPP, and if that MPP is the NMP, the NMP selects an SATP and PSP."