Native Multipathing Plugin (NMP)

 As with anything I post regarding virtualization – nothing groundbreaking, just some notes.
Pluggable Storage Architecture (PSA)
To manage storage multipathing, ESX/ESXi uses a special VMkernel layer, Pluggable Storage Architecture (PSA). The PSA is an open modular framework that coordinates the simultaneous operation of multiple multipathing plugins (MPPs).PSA is a collection of VMkernel APIs that allow third party hardware vendors to insert code directly into the ESX storage I/O path. This allows 3rd party software developers to design their own load balancing techniques and failover mechanisms for particular storage array. The PSA coordinates the operation of the NMP and any additional 3rd party MPP.
Native Multipathing Plugin (NMP)
The VMkernel multipathing plugin that ESX/ESXi provides, by default, is the VMware Native Multipathing Plugin (NMP). The NMP is an extensible module that manages subplugins. There are two types of NMP subplugins: Storage Array Type Plugins (SATPs), and Path Selection Plugins (PSPs). SATPs and PSPs can be built-in and provided by VMware, or can be provided by a third party.If more multipathing functionality is required, a third party can also provide an MPP to run in addition to, or as a replacement for, the default NMP.
VMware provides a generic Multipathing Plugin (MPP) called Native Multipathing Plugin (NMP).
What does NMP do?
  • Manages physical path claiming and unclaiming.
  • Registers and de-registers logical devices.
  • Associates physical paths with logical devices.
  • Processes I/O requests to logical devices:
    • Selects an optimal physical path for the request (load balance)
    • Performs actions necessary to handle failures and request retries.
  • Supports management tasks such as abort or reset of logical devices.

What’s new in  5.0 (regarding multipathing)?

Host Profiles have been extended to include support for storage multipathing.

vSphere Client operations

You can view the Storage Array Type and set the NMP pathing policy in Host and Clusters > Configuration tab > Storage (Hardware pane) > Click the Manage Paths link in the Device details section.

Path Policies explained:

  • Most Recently Used (MRU) — Selects the first working path, discovered at system boot time. If this path becomes unavailable, the ESX/ESXi host switches to an alternative path and continues to use the new path while it is available. This is the default policy for Logical Unit Numbers (LUNs) presented from an Active/Passive array. ESX/ESXi does not return to the previous path when if, or when, it returns; it remains on the working path until it, for any reason, fails.Note: The preferred flag, while sometimes visible, is not applicable to the MRU pathing policy and can be disregarded.
  • Fixed (Fixed) — Uses the designated preferred path flag, if it has been configured. Otherwise, it uses the first working path discovered at system boot time. If the ESX/ESXi host cannot use the preferred path or it becomes unavailable, ESX/ESXi selects an alternative available path. The host automatically returns to the previously-defined preferred path as soon as it becomes available again. This is the default policy for LUNs presented from an Active/Active storage array.
  • Round Robin (RR) — Uses an automatic path selection rotating through all available paths, enabling the distribution of load across the configured paths.
    • For Active/Passive storage arrays, only the paths to the active controller will used in the Round Robin policy.
    • For Active/Active storage arrays, all paths will used in the Round Robin policy.

    Note: This policy is not currently supported for Logical Units that are part of a Microsoft Cluster Service (MSCS) virtual machine.

  • Fixed path with Array Preference — The VMW_PSP_FIXED_AP policy was introduced in ESX/ESXi 4.1. It works for both Active/Active and Active/Passive storage arrays that support ALUA. This policy queries the storage array for the preferred path based on the arrays preference. If no preferred path is specified by the user, the storage array selects the preferred path based on specific criteria.

CLI operations

~ # esxcli storage nmp [ENTER] will display the following namespaces, and allows for many useful native multipathing operations.  Useful for confirming GUI configurations.

Output from ~ # esxcli storage nmp device list command.

I know that’s not much but it’s all I got 🙂 .  Sayonara.

Gabe@networkdojo.net

Sources:
VMware KB 1011375
FC SAN Config Guide

Advertisements

vSphere 5.0 – Storage I/O control ( SOIC )

Nothing ground-breaking in this post – just jotting down some notes.  An excellent deep technical explanation can be found here:  Storage I/O Control Technical Overview and Considerations for Deployment.

But if you’re satisfied with peanuts (which is all I gots), keep on reading.

What is Storage I/O control?

When you enable Storage I/O Control, ESXi monitors datastore latency and adjusts the I/O load sent to it, if datastore average latency exceeds the threshold. The sole purpose is to prevent any single VM from monopolizing a datastore.  This feature is not enabled by default – but it’s a good idea to get around to understanding and enabling it.

What is new regarding SOIC in 5.0?   Storage I/O Control NFS support!

vSphere 5.0 extends Storage I/O Control to provide cluster-wide I/O shares and limits for NFS datastores.


To Enable Storage I/O Control

1 In the vSphere Client inventory, select a datastore and click the Configuration tab.
2 Click Properties.
3 Under Storage I/O Control, select the Enabled check box.
4 Click Close.

On the Datastores tab, the Storage I/O Control column shows that Storage I/O Control is enabled for the datastore.

 

Setting the Congestion Threshold Value for Storage I/O Control 

The congestion threshold value for a datastore is the upper limit of latency that is allowed for a datastore before Storage I/O Control begins to assign importance to the virtual machine workloads according to their shares.

You do not need to adjust the congestion threshold setting in most environments. Do not make any changes to these settings unless you are working with the VMware support team or otherwise have thorough information about the values to provide for the settings

 If you do change the threshold setting, set the value based on the following considerations.
  • A higher value typically results in higher aggregate throughput and weaker isolation. Throttling will not occur unless the overall average latency is higher than the threshold
  • If throughput is more critical than latency, do not set the value too low. For example, for Fibre Channel disks, a value below 20 ms could lower peak disk throughput. On the other hand, a very high value (above 50 ms) might allow very high latency without any significant gain in overall throughput.
  • A lower value will result in lower device latency and stronger virtual machine I/O performance isolation. Stronger isolation means that the shares controls are enforced more often. Lower device latency translates into lower I/O latency for the virtual machines with the highest shares, at the cost of higher I/O latency experienced by the virtual machines with fewer shares.
  • If latency is more important, a very low value (lower than 20 ms) will result in lower device latency and better isolation among IOs at the cost of a decrease in aggregate datastore throughput.
Procedure
  1. Select a datastore in the vSphere Client inventory and click the Configuration tab.
  2. Click Properties.
  3. Under Storage I/O Control, select the Enabled check box.
  4. Click Advanced to edit the congestion threshold value for the datastore.
    The value must be between 10 and 100. You can click Reset to restore the congestion threshold setting to the default value (30 ms).
  5. Click Close.
And that’s all I got folks!  Good nite!
Yours,
Gabe@networkdojo.net
Sources :
– vmware tech paper on SOIC.
– vmware kb 1019687
– vSphere5.0 Help Topics
– http://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-new-features.html