In the Unisphere for PowerMax 9.0 release we have increased integration with Powerpath hosts that are discovered on the arrays we monitor in Unisphere. With a new PowerMax array with a FX/Pro license (premium) you are entitled up to 75 ESXi host licenses. These PowerPath licenses are now automatically deployed for VMware, Windows and Linux hosts with PowerPath 6.3 and later.
With over 25 years of engineering and development behind it PowerPath is a family of multipathing software products that automate and optimize I/O performance in physical and virtual environments. PowerPath intelligently manages I/O path loads and failover to increase application availability and reduce latency. Proprietary optimization for Dell EMC PowerMax and VMAX increases I/O performance 2X – £3X over native multipathing.
We have heard from customers they want to see more integration with our existing software products in order to help their ongoing automation drive and also provide enhanced troubleshooting capabilities from our side.
PowerPath Hosts Landing Page:
In Unisphere on the left hand navigation you will find it under Hosts>PowerPath Hosts.
This view gives you a single pane of glass view of all your PowerPath hosts that are connected on arrays that this specific Unisphere instance can see.
In this view you are presented with a lot of useful information if you are in the midst of a troubleshooting scenario. By selecting the lcvt1032 host you are presented with a lot more information on the right hand navigation. The PowerPath version and patch level, OS version, revision and patch level, Server hardware, MFG and serial number, PowerPath license type and connectivity type (FC, iSCSI or FCOE) are all displayed.
The objects Initiators, Hosts/Host Groups, Masking Views, Storage Groups and Volumes are displayed in blue and can be selected in order for you to drill down to the specific object. At the bottom of the list is the number of VM’s on this ESXi server. Selecting the VM count highlighted in blue will get you to a list of the VM’s as we see here.
So let’s say we need to quickly find out what are the initiators for lcvt1032 as we are investigating an internal ticket for a performance issue.
Now in this view to drill down on your performance problem you can select volumes to see what volumes are assigned to this host.
When you select an individual volume you can see the right hand pane shows a wealth of good information including whether if the volume is mounted. In this case it is not so that may indicate the root of the problem. If the dev was mounted, below the mount status will be the name of the host process using the dev (for ESXi it’s the VM name). The host process/vm name allows you to figure out what application is using the device. At the bottom of the device information is the date when date when the device last received I/O from any host. This allows you to find the devices that were not used for a while, and the combination of host name and process/vm name allows you to identify who owns the dormant device.
I hope I’ve displayed some of the power of the troubleshooting you can potentially do from the PowerPath landing page when you are investigating a potential PowerPath issue.
Auto Initiator Group (IG) creation using PowerPath Host Name:
On the main landing page we also have a new option called create host which will allow Auto IG creation:
On 5978 HyperMax code and Unisphere/Solutions Enabler 9.0 allows for the hostname to be provided when creating an IG. Unisphere/SE picks the host HBA WWN’s from the Host registration data provided by PowerPath and add them to the IG for you. This significantly helps you in the overall provisioning flow if adding a new PowerPath host.
The initiator array switch that controls AUTO IG creation is disabled by default, but you can turn it on by selecting it in the settings section of Unisphere.
Auto IG Creation works in tandem with the PowerPath Host registration, if the PowerPath host registration switch is disabled, then the Auto IG Creation will also be disabled.
As of now Linux and AIX PowerPath will automatically detect Devices added or deleted on a certain path following masking or zoning changes (ESXi and Windows already does this). Once PowerPath Devices have changed it will run a host scan and the O/S will discover the new Devices.
This significantly helps you in the overall provisioning flow if adding a new PowerPath host. It achieves this by automatically pulling the WWN’s registered with that hostname provided the correct settings are enabled as outlined below. This reduces some of the configuration work that the user has to perform when setting up a host.
Device in Use Details:
Another really powerful feature is the Device in use example. By using Unisphere or SE you can easily see if a device is mounted and active by looking at the volume level. In Unisphere you would navigate down to the volume level:
On selecting a specific device the right hand pane will show more detailed information. We can see here that the device mounted state is true and is used by a process called consist_lun_x (for ESXi it would be the vm name). Therefore we can see if a device was used lately and who is the owner (host, mount status, application or vm name). The same information can also be viewed in SE with symdev list –sid xxxx –ppi.
The use case we were looking to resolve here is that often SA’s get requested for resources on the array by application owners and they do so to future proof themselves for projects. Although from an application owner this makes perfect sense but from a SA whose job is to manage array usage and consumption it is not best practice. In certain cases people who manage the capacity of the array can leave or transfer and the capacity they owned goes unused. Up until this feature there was no good way from the storage side to track it down.
This information is updated every 24 hours and if the SA feels that application owners are taking liberties by not mounting volumes or using storage they can have a frank discussion with the application owner!
Another new feature we have added is we’ve exposed some PowerPath metrics in our Performance section. These metrics are % PowerPath Observes Relative RT (PowerPath reported RT divided by array RT), PowerPath Average Response Time (ms) and PowerPath Observed Delta RT (ms) (PowerPath reported RT minus the array RT).
These metrics can be accessed in the all metrics section by using the radio button slider. These new metrics are available at the SG and Thin volume object type level. Here’s an example showing the differences in the three measurements vs array response time.
In this example the array response is .41 ms, while the average I/o Response time as measured by PowerPath from the host to the array is .60 ms. This .20 ms (observed delta) and 147% relative delta (%PowerPath observed Relative RT) difference can help identify where the slowdown is occurring – not at the array level here! A spike in PowerPath observed Relative RT % may indicate SAN slowdown or a possible slow drain problem which occurs outside of the array.
I hope you found these use cases helpful and if you have any questions please let me know.
I would like to thank some learned PowerPath colleagues in preparing this content, Owen Crowley in QE, Eric Don in Engineering and Robert Lonadier in PM.