Reporting on Trespassed LUNs

All of our production clariions are configured with two large tiered storage pools, one for LUNs on SPA and one for LUNs on SPB. When storage is created on a server, two identical LUNs are created (one in each pool) and are striped at the host level. I do it that way to more evenly balance the load on the storage processors.

I’ve noticed that LUNs will occassionally trespass to the other SP. In order to keep the SP’s balanced how I want them, I will routinely check and trespass them back to their default owner. Our naming convention for LUNs includes the SP that the LUN was initially configured to use, as well as the pool ID, server name, filesystem/drive letter, last four digits of serial number, and size. Having all of this information in the LUN name makes for very easy reporting. Having the default SP in the LUN name is required for this script to work as written.

To quickly check on the status of any mismatched LUNs every morning, I created a script that generates a daily report. The script first creates output files that list all of the LUNs on each SP, then uses simple grep commands to output only the LUNs whose SP designation in the name does not match the current owner. The csv output files are then parsed by the csv2html perl script, which converts the csv into easy to read HTML files that are automatically posted on our intranet web site. The csv2html perl script is from http://www.jpsdomain.org/source/perl.html and is under a GNU General Public License. Note that this script is designed to run in unix. It can be run using cygwin installed on a Windows server if you don’t have access to a unix based server.

The script I posted is farily specific to my environment, I was looking for a way to easily verify that LUNs stay in the correct designated pool for their SP. I don’t have anything already written that I could post for you, but one possible way would be to create a script that runs “naviseccli -h x.x.x.x getlun -trespass > output.txt” on a regular basis and have it send you the results in an email or write it to a folder shared on your intranet.

If you wanted to make that output more useful and readable, you’d have to parse the output file and grep/awk the info you need into a report, I’ve got several samples of how to do that in my posts. Doing that would make it easier to quickly scan two columns (Current Owner | Default Owner) and look for mismatches. I can’t think of any way off the top of my head to immediately alert you to a trespassed LUN. That could be an option in EMC Ionix Control Center, but it’s not something I’ve looked into before.

One idea on getting trespassed luns to generate an alert is to run “naviseccli -h x.x.x.x getlun -trespass | grep LOGICAL > /dev/null” (assuming naviseccli is installed on unix/linux). If it has a return code of 0, you have trespassed luns. You could use the logger command to set an error in syslog which should generate an alert if you’re monitoring syslog messages. You could probably run the script out of cron periodically.

A very convenient way to get all of the trespassed luns back to their default SP is to use “naviseccli -h x.x.x.x trespass mine”. Run it against both SPs.