In my current role, I don’t do a lot of array configuration from scratch anymore. I generally do the detailed design and hand it over to a colleague to go and make it so. Recently, however, I’ve had to step in and do some actual work myself because reasons. Anyway, I was deploying a new VNX5400 and having a heck of a time getting Unisphere to work. And by Unisphere I mean Java. I initially wanted to blame my work-issued Windows 8.1 laptop, but it was ultimately a Java issue. It turns out my Java version was high. Not Cypress Hill high, but still too high for Unisphere.
EMC’s snappily titled “EMC VNX Operating Environment for Block 05.33.006.5.096, EMC VNX Operating Environment for File 188.8.131.52, EMC Unisphere 184.108.40.206.0096 Release Notes” talks fairly explicitly about Java support on page 6, and I thought it was worth repeating here for schmucks like me who do this stuff part-time. You can find this document on the EMC support site.
The following 32 bit Java Platforms are verified by EMC and compatible for use with Unisphere, the Unified Service Manager (USM), and the VNX Installation Assistant (VIA):
Oracle Standard Edition 1.7 up to Update 75
Oracle Standard Edition 1.8 up to Update 25
The 32-bit JRE is required – even on 64 bit systems. JRE Standard Edition 1.6 is not recommended because Oracle has stopped support for this edition”.
I think I was running 1.8 Update 31, and saw that, regardless of the browser, Unisphere just wouldn’t load. If you need to track down an older version of Java to work on stuff like this – Oracle has a site you can go to here. Incidentally, I can confirm that it is not necessary to install the Ask Toolbar in order for Unisphere to function correctly.
*Update (2016.05.20): Current link to 1.8 U25 is here.
*Update (2016.06.04): Jirah Cox (@vJirah) pointed out that http://filehippo.com keeps an extensive archive of versions too.
I spent a recent public holiday assisting a client move some VNX5500s between racks in their data centre. Not terribly exciting, but it helped them out of a spot. Something that was done as part of the shift was a change in SP IP addresses. There’s an article on support.emc.com that refers to Primus ID emc274335 and some Java misconfiguration. I’m not entirely convinced though, because we observed that Unisphere would (eventually) come good, without us making any changes to the client settings. In any case, I thought it was something interesting. The arrays were running VNX OE R31 and R32.
If you’re trying to do an OE upgrade on a VNX you might get the following error after you’ve run through the “Prepare for Installation” phase.
Turns out you just need to upgrade USM to the latest version. You can do this manually or via USM. Further information on this error can be found on support.emc.com by searching for the following Primus ID: emc321171.
Incidentally, I’d just like to congratulate EMC on how much simpler it is upgrade FLARE / VNX OE nowadays than it was when I first started on FC and CX arrays. Sooo much nicer …
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 Klaushere. 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.
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.
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.
I’m a bit behind on my news, but just a quick note to say that FLARE 33 for the next-generation VNX (Block) has received an update to version 05.33.000.5.038. The release notes are here. Notably, a fix related to ETA 175619 is included. This is a good thing. As always, go to EMC’s Support site for more info, and talk to your local EMC people about whether it’s appropriate to upgrade.