EMC – naviseccli – checking your iSCSI ports are running at the correct speed

It’s been a while since I wrote about naviseccli and I admit I’ve missed it. I once wrote about using naviseccli to identify MirrorView ports on a CLARiiON array. Normally the MirrorView port is consistently located, but in that example we’d upgraded from a CX3-80 to a Cx4-960 and it was in a different spot. Oh how we laughed when we realised what the problem was. Anyway, we’ve been doing some work on an ever so slightly more modern VNX5300 and needed to confirm that some newly installed iSCSI SLICs were operating at the correct speed. (Note that these commands were run from the Control Station).

The first step is to list the ports

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.09.07 08:59:37 =~=~=~=~=~=~=~=~=~=~=~=
[nasadmin@NAS001 ~]$ navicli -h A_VNXSP connection -getport

SP:  A
Port ID:  8
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a8
iSCSI Alias:  0017.a8
IP Address:  192.168.0.13
Subnet Mask:  255.255.255.0
Gateway Address:  192.168.0.254
Initiator Authentication:  false

SP:  A
Port ID:  9
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a9
iSCSI Alias:  0017.a9

SP:  A
Port ID:  10
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a10
iSCSI Alias:  017.a10

SP:  A
Port ID:  11
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a11
iSCSI Alias:  017.a11

SP:  B
Port ID:  8
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b8
iSCSI Alias:  0017.b8
IP Address:  192.168.0.14
Subnet Mask:  255.255.255.0
Gateway Address:  192.168.0.254
Initiator Authentication:  false

SP:  B
Port ID:  9
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b9
iSCSI Alias:  0017.b9

SP:  B
Port ID:  10
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b10
iSCSI Alias:  017.b10

SP:  B
Port ID:  11
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.b11
iSCSI Alias:  017.b11

Once you’ve done that, you can list the port speed for a particular port

[nasadmin@NAS001 ~]$ navicli -h A_VNXSP connection -getport -sp a -portid 8 -speed
SP:  A
Port ID:  8
Port WWN:  iqn.1992-04.com.emc:cx.cetv2223700017.a8
iSCSI Alias:  0017.a8
IP Address:  192.168.0.13
Subnet Mask:  255.255.255.0
Gateway Address:  192.168.0.254
Initiator Authentication:  false
Port Speed:  1000 Mb
Auto-Negotiate:  Yes
Available Speeds:  10 Mb
-               :  100 Mb
-               :  1000 Mb
-               :  Auto

If you have a lot of ports to check this may not be the most efficient way to do it (ioportconfig may be more sensible), but if your network team are reporting on one particular port being an issue – this is a great way to narrow it down.

EMC – Using naviseccli to configure a VNX domain

The concept of domains have been with CLARiiON and (later) VNX arrays since the early part of the 21st Century. The configuration is fairly simple, and, in keeping with the idea that you can do anything with naviseccli, I thought I’d do a quick post on using naviseccli to join SPs to a domain. This assumes you have security setup with your naviseccli environment, and you know the IPs of the SPs you’re trying to add to the domain.

You can the set the master node for a domain with this command. Note that the nominated node can’t be a member of another domain at the time.

naviseccli -h SPA-IP-Address domain -setmaster SPB-IP-Address
 WARNING: You are about to set the following node as the master of the domain: SPB-IP-Address
 Proceed? (y/n) y

If a node is a problem, or you’re about to remove an array from your environment, it’s a good idea to remove it from the domain before you rip it out of the rack.

naviseccli -h SPA-IP-Address domain -remove SPA-IP-Address
 WARNING: You are about to remove the following node from the domain: SPA-IP-Address
 Proceed? (y/n) y

You may also wish to add another couple of nodes, particularly if you have a number of arrays in the environment.

naviseccli -h SPB-IP-Address domain -add SPA-IP-Address
 WARNING: You are about to remove the following node from the domain: SPA-IP-Address
 Proceed? (y/n) y

And that’s it. I recommend you check out EMC’s white paper – Domain Management with EMC Unisphere for VNX (p/n h8853.4) – for more information on VNX domain management.

EMC – Using naviseccli to create a VNX Snapshot

If you’re a VNX customer you’ve probably heard someone bang on about how easy to use VNX Snapshots are, particularly if they’ve used SnapView in the past. If you’re after the good word on VNX Snapshots, check out this whitepaper from EMC here. Tomek has a reasonable write-up here as well.

In any case I’ve been working with a customer on some migration scripts and they wanted to take VNX Snapshots as well as VM snapshots while they update their OS and apps. I wrote about creating SnapView Clones with naviseccli some time ago, but I find VNX Snapshots a shedload easier to work with. This is will, as always, be dictated by your own set of requirements, circumstances and religious beliefs.

So here’s what you need to do to get from start to finish. Note that I haven’t covered creating Snapshot Mount Points (SMPs) in this, nor do I talk about using host-based tools such as SnapCLI. I’ll follow up in the future with some words around this.

[Update] I forgot to mention @Dynamoxxx / Storage Monkey‘s excellent posts on this subject too – have a look here for Linux and here for Windows.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.

C:\Program Files (x86)\EMC\Navisphere CLI>NaviSECCli.exe
Not enough arguments
  Usage:
    [-User <username>] [-Password <password>]
    [-Scope <0 - global; 1 - local; 2 - LDAP>]
    [-Address <IPAddress | NetworkName> | -h <IPAddress | NetworkName>]
    [-Port <portnumber>] [-Timeout <timeout> | -t <timeout>]
    [-AddUserSecurity | -RemoveUserSecurity | -DeleteSecurityEntry]
    [-Parse | -p] [-NoPoll | -np] [-cmdtime]
    [-Xml] [-f <filename>] [-Help] CMD <Optional Arguments>
    [security -certificate]

You’ll need to set yourself up if you’re using a fresh installation.

C:\Program Files (x86)\EMC\Navisphere CLI>NaviSECCli.exe -addusersecurity -scope 0 -user sysadmin

You can then create a snapshot of LUN 7 called “testsnap1” which is read/write and will be kept for 4 hours.

C:\Program Files (x86)\EMC\Navisphere CLI>NaviSECCli.exe -address 192.168.0.100 snap -create -res 7 -resType LUN -name "testsnap1" -descr "snap via CLI" -keepFor 4h -allowreadwrite yes
Unable to validate the identity of the server.  There are issues with the certificate presented.
Only import this certificate if you have reason to believe it was sent by a trusted source.
Certificate details:
Subject:        CN=192.168.0.100,CN=SPA,OU=CLARiiON
Issuer: CN=192.168.0.100,CN=SPA,OU=CLARiiON
Serial#:        fcd99068
Valid From:     2015:01:15:02:55:01
Valid To:       2020:01:14:02:55:01
Would you like to [1]Accept the certificate for this session, [2] Accept and store, [3] Reject the certificate?
Please input your selection(The default selection is [1]):
2

Note that there’s no output from this command. If you want to check out the snapshots you have, you can list them.

C:\Program Files (x86)\EMC\Navisphere CLI>naviseccli -address 192.168.0.100 snap -list

Name:  testsnap1
Description:  snap via CLI
Creation time:  05/19/15 10:22:37
Source LUN(s):  7
Source CG:  N/A
State:  Ready
Allow Read/Write:  Yes
Modified:  No
Allow auto delete:  No
Expiration date:  05/19/15 14:22:37

Want to change the ID of the snapshot or change the autodelete setting?

C:\Program Files (x86)\EMC\Navisphere CLI>naviseccli -address 192.168.0.100 snap -modify -id "testsnap1" -name "testsnap2" -allowautodelete yes
Setting auto-delete on this Snapshot will clear expiration date on it. Are you sure you want to perform this operation?(y/n): n
C:\Program Files (x86)\EMC\Navisphere CLI>naviseccli -address 192.168.0.100 snap -modify -id "testsnap1" -name "testsnap2"

Great, now let’s get rid of it.

C:\Program Files (x86)\EMC\Navisphere CLI>naviseccli -address 192.168.0.100 snap -destroy -id "testsnap2"
Are you sure you want to perform this operation?(y/n): y

And that’s about it.

EMC – VNX Pool LUN Allocation vs Default Owner

I had a question about this come up this week and thought I’d already posted something about it. Seems I was lazy and didn’t. If you have access, have a look at Primus article emc311319 on EMC’s support site. If you don’t, here’s the rough guide to what it’s all about.

When a Storage Pool is created, a large number of private LUNs are bound on all the Pool drives and these are divided up between SP A and B. When a Pool LUN is created, it uses the allocation owner to determine which SP private LUNs should be used to store the Pool LUN slices. If the default and current owner are not the same as the allocation owner, the I/O will have to be passed over the CMI bus between SP, to reach the Pool Private FLARE LUNs. This is a bad thing, and can lead to higher response times and general I/O bottlenecks.

OMG, I might have this issue, what should I do? You can change the default owner of a LUN by accessing the LUN properties in Unisphere. You can also change the default owner of a LUN thusly.

naviseccli -h <SP A or B> chglun -l <metalun> -d owner <0|1>

where

-d owner 0 = SP A
-d owner 1 = SP B

But what if you have too many LUNs where the allocation owner sits on one SP? And when did I start writing blog posts in the form of a series of questions? I don’t know the answer to the latter question. But for the first, the simplest remedy is to create a LUN on the alternate SP and use EMC’s LUN migration tool to get the LUN to the other SP. Finally, to match the current owner of a LUN to the default owner, simply trespass the LUN to the default owner SP.

Note that this is a problem from CX4 arrays through to VNX2 arrays. It does not apply to traditional RAID Group FLARE LUNs though, only Pool LUNs.

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 – Some new scripts

Mat has come up with a few new scripts – FlipFASTTiering and ReplicationCapacity. They’re PERL scripts that you can use to list / modify FAST Tiering scheduling and report on MirrorView replication data respectively. Hopefully you’ll find them of some use. Further information can be found on the Utilities page.

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 – DIY Heatmaps – Updated Version

I’ve patched the DIY Heatmaps script, fixing a problem with the table names generated in the database files. You can download it from the Utilities page.

 

Thanks

Mat.

EMC – DIY Heatmaps – Updated Version

Mat has patched the DIY Heatmaps script, fixing a problem with current model VNXs and updated naviseccli whereby using the –get_drive_type –display_drive_type options of the heatmap script would cause a JavaScript error in the resulting heatmap HTML file. You can download it from the Utilities page.