EMC – VNX / CX4 LUN Allocation Owner and Default Owner

Mat’s been doing some useful scripting again. This time it’s a small PERL script that identifies the allocation owner and default owner of a pool LUN on a CX4 or VNX and lets you know whether the LUN is “non-optimal” or not. For those of you playing along at home, I found the following information on this (but can’t remember where I found it). “Allocation owner of a pool LUN is the SP that owns and maintains the metadata for that LUN. It is not advised to trespass the LUNs to an SP that is not the allocation owner. This introduces lag. The SP that provides the best performance for the pool LUN. The allocation owner SP is set by the system to match the default SP owner when you create the LUN. You cannot change the allocation owner after the LUN is created. If you change the default owner for the LUN, the software will display a warning that a performance penalty will occur if you continue.”

There’s a useful article by Jithin Nadukandathil on the ECN site, as well as a most excellent writeup by fellow EMC Elect member Jon Klaus here. In short, if you identify NonOptimal LUN ownership, your best option is to create a new LUN and migrate the data to that LUN via the LUN Migration tool. You can download a copy of the script here. Feel free to look at the other scripts that are on offer as well. Here’s what the output looks like.

 output1

 

 

EMC – Using naviseccli to report on a LUN’s FAST status

Ever wondered what tier a LUN was sitting on in a FAST VP pool? Wonder no more, naviseccli is here to help.

C:\>naviseccli -user username -scope 0 -password password -h 1.1.1.1 lun -list -l 24 -userCap -consumedCap -tieringPolicy -initialTier -tiers
LOGICAL UNIT NUMBER 24
Name: LUN_0024
User Capacity (Blocks): 4294967296
User Capacity (GBs): 2048.000
Consumed Capacity (Blocks): 4379120640
Consumed Capacity (GBs): 2088.127
Tiering Policy: Auto Tier
Initial Tier: Optimize Pool
Tier Distribution:
FC: 93.87%
SATA: 6.13%

Also, you can see this information via Unisphere. Those of you who are challenged at the thought of typing something won’t be left out.

lun1

lun2

 

 

EMC – Using naviseccli to expand a pool

I haven’t banged on about how much I like naviseccli in a little while. I was reading a white paper on FAST VP in the new VNX series recently, and came across the storage pool -expand command. This isn’t so exciting, but the -skipRules option was intriguing. It seems you would use this if you didn’t want to follow all of the rules associated with a normal pool expansion. I inferred from the white paper that by default a FAST VP pool will automatically redistribute its LUNs across the new disks. This may be non-optimal if you’re in the middle of a busy period on the array, and if you don’t want this to happen, you should use the skipRules option.  Note that this is for Release 5.33. If I’ve misunderstood this I’m happy to be corrected.

In any case, here’s an example of how to expand a pool using naviseccli.

storagepool -expand -id poolID| -name poolName-disks disksList [-rtype raidType[-rdrivecountdrivecount]][-initialverify yes|no][-skipRules] [-o]

The RAID types you can select are r_5, r_6 and r_10. This is important if you already have disks of a certain tier type in the pool. The capacity tier (NL-SAS drives) uses RAID 6, the performance tier (SAS drives) uses RAID 5, and the extreme performance tier (Flash drives) is RAID 1/0.

naviseccli -h SP_IPaddress storagepool -expand -id 10 -rtype r_6 -disks 0_2_0 0_2_1 0_2_2 0_2_3 0_2_4 0_2_5 0_2_6 0_2_7 –o

EMC – Using naviseccli to change the LUN Migration priority of a LUN

I am currently working through a metric shitload of LUN migrations on one of our CX4 arrays, with the end-goal being a replacement of 60 or so 300GB FC disks with 60 600GB FC disks. This is the sort of stuff you have to do when you’re not allowed to buy new arrays (budget notwithstanding). But enough moaning.

I’ve set up a number LUN migrations to get this done, but Mat says I shouldn’t run them at a high priority during business hours. I say if the spurs fit. But whatever. With naviseccli, you can list all of the LUNs that are currently migrating on the array. Once you have this list, you can grep for the LUN IDs and modify the migration priority depending on whether it’s during or after hours.

C:\Users\dan>naviseccli -h SPA migrate -list
Source LU Name: LUN 7010
Source LU ID: 7010
Dest LU Name: LUN 6
Dest LU ID: 6
Migration Rate: HIGH
Current State: MIGRATING
Percent Complete: 89
Time Remaining: 24 minute(s)

Source LU Name: LUN 7018
Source LU ID: 7018
Dest LU Name: LUN 8
Dest LU ID: 8
Migration Rate: HIGH
Current State: MIGRATING
Percent Complete: 90
Time Remaining: 20 minute(s)

Source LU Name: LUN 600
Source LU ID: 600
Dest LU Name: LUN 1
Dest LU ID: 1
Migration Rate: MEDIUM
Current State: MIGRATING
Percent Complete: 44
Time Remaining: 8 hour(s) 23 minute(s)
[snip]

 

So let’s say I want to change the migration priority for LUN ID 7018. All I need to use is the modify command, specify the correct source ID, and the set the rate to low | medium | high | asap. I’m using -o to avoid prompting.

C:\Users\dan>naviseccli -h SPA migrate -modify -source 7018 -rate medium -o

Now I can use the -list switch to verify my work. Note that it takes the array a little while to calculate the new estimate for  Time Remaining. So if you really want to know that, give it a minute or so.

C:\Users\dan>naviseccli -h SPA migrate -list
Source LU Name: LUN 7010
Source LU ID: 7010
Dest LU Name: LUN 6
Dest LU ID: 6
Migration Rate: HIGH
Current State: MIGRATING
Percent Complete: 90
Time Remaining: 22 minute(s)

Source LU Name: LUN 7018
Source LU ID: 7018
Dest LU Name: LUN 8
Dest LU ID: 8
Migration Rate: MEDIUM
Current State: MIGRATING
Percent Complete: 91
Time Remaining: ?

Source LU Name: LUN 600
Source LU ID: 600
Dest LU Name: LUN 1
Dest LU ID: 1
Migration Rate: MEDIUM
Current State: MIGRATING
Percent Complete: 44
Time Remaining: 8 hour(s) 23 minute(s)
[snip]

C:\Users\dan>

And that’s pretty much it.

EMC – naviseccli – Getting LUN info from Analyzer stats

So Mat was working on some new features for the DIY Heatmap, or whatever it’s called, and came across this, er, issue with Analyzer.

It seems that the code that you query via Analyzer for the object type is the same for both Pool LUNs and Private LUNs. Check it out on page 37 of the “EMC Unisphere Analyzer Command Line Interface (CLI) Reference”, revision A06, EMC P/N 300-004-210. So what we’ve been trying to incorporate is a LUN heatmap in the script. But this is going to be a problem if, for example, you have MetaLUN components, or Reserved LUN Pools, in combination with FAST VP Pools. Or have we missed something critical here?