I, like you, am trying to make sense of vSphere’s new Pluggable Storage Architecture or PSA. Acronym’s galore float through that camp, so if your not careful you may find yourself in the middle of cosmic confusion. So here’s my crack at the different functions of each plug-in and specifically their interrelations. Up first…

PSA- Pluggable Storage Architecture-this is a modular framework within the VMkernel responsible for managing storage arrays and their pathing. This pathing is orchestrated via MPP’s, but before we get to that what else does the PSA provide task wise, take note..

■ Loads and unloads multipathing plug-ins, Hides virtual machine specifics from a particular plug-in, Routes I/O requests for a specific logical device to the MPP managing that device, Handles I/O queuing to the logical devices.

■ Implements logical device bandwidth sharing between virtual machines, Handles I/O queuing to the physical storage HBAs, Handles physical path discovery and removal, Provides logical device and physical path I/O statistics.

Onward fellow storage enthusiasts..

MPP-Multi-Path Plugin’s-These are, you guessed it, modules responsible for multi-path selection for a LUN (and failover). Now within this are third-party and VMware specific plug-in’s. Which brings us to…

NMP- Native Multi-Pathing Plug-in- this is a VMware specific path selection plug-in responsible for providing support for all HCL listed arrays. If the array is listed on the HCL, NMP is there to assign a path policy. But not alone, oh no, this function is delegated to SATP and PSP, sub plug-ins within NMP…

SATP- Storage Array Type Plug-in-What does it provide? Failover specifically. But as the graphic below states it also monitors path health, reports changes in those paths, and  enables inactive paths in storage failover situations.

PSP- Path Selection Plug-in-What does it provide? Load balancing specifically. I/O placement on to the available physical path’s is the name of the game here, Fixed, MRU and Round robin are the native default path selections I speak of within vSphere.

Third Party MPP-Third party MPP (failover and load balancing). Alternative to VMware’s NMP (i.e. EMC PowerPath/VE). Just as you can have multiple arrays attached to a single ESX host, you most certainly can have multi-partner plug-ins side by side. User defined claim rules can be mapped to a specific plug-in for a specific set of LUNs, array types, or  HBA’s. I know,I know, explain claim rules?

What are claim rules?- It goes with out saying that multiple MPP’s cannot manage the same storage device, so claim rules allow you to designate which MPP is assigned to which storage device. As noted here, each claim rule identifies the following parameters:

Vendor/model strings

• Transportation, such as SATA, IDE, FC, and so forth
• Adaptor, target, or LUN location
• Device driver

Claim rules are defined within /etc/vmware/esx.conf on each ESX host and can be managed via the vSphere CLI. Obviously you can change the MP policy (Fixed, MRU, RR) within the vSphere client itself but any claim change/operations need to happen from the command line.

FLOW of I/O, complements of NMP- So lets put it all together as noted here…

When a virtual machine issue an I/O request to a storage device managed my NMP, the following process takes place.

1. The NMP calls the PSP assigned to this storage device (Fixed, MRU or RR)
2. The PSP selects an appropriate physical path on which to issue an I/O
3. If the I/O operation is successful , the NMP reports its completion.
4. If the I/O operation reports an error, the NMP calls an appropriate SATP.
5. The SATP interprets the I/O command errors and , when appropriate, activates inactive paths.
6. The PSP is called to select a new path on which to issue the I/O.

Well I hope this helps, it helps me. Expect more on this topic in the future…