EMC – VNX2, Unisphere and Java Support

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 8.1.6.96, EMC Unisphere 1.3.6.1.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.

“Java support

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.

Brocade – Alias and Zone syntax. Or how FOS is a love / hate thing.

I’ve been spending a lot of time recently working through some storage performance issues at a client. One of the outcomes of this work was that a serious amount of remediation was required within their two FC fabrics, as they were running a lot of multi-initiator – multi-target zoning and other crazy stuff. I spent a lot of time rebuilding the configs for the Brocade-based fabrics, and had a colleague double-check my work.

Now, for those of you playing along at home, you might remember that I’ve spent the last 7 years or so working primarily on Cisco MDS environments, so doing work with Brocade gear was meant to be a refreshing change. And for the most part it was. In any case, I generated 148 new aliases and 365 new zone sets, and hoped like heck I hadn’t missed anything.

Here’s the syntax of the commands I was using.

alicreate "SAN1_SPA5","50:06:01:65:3e:a0:1e:d7"
alicreate "SAN1_SPB4","50:06:01:6c:3e:a0:1e:d7"
alicreate "A-HOST1_HBA0","20:00:00:00:c9:53:71:ba"
zonecreate "A-HOST1_HBA0_SAN1_SPA5","A-HOST1_HBA0;SAN1_SPA5"
zonecreate "A-HOST1_HBA0_SAN1_SPB4","A-HOST1_HBA0;SAN1_SPB4"
cfgcreate "PROD1","A-HOST1_HBA0_SAN1_SPA5"
cfgadd "PROD1","A-HOST1_HBA0_SAN1_SPB4"
cfgsave
cfgenable "PROD1"

In this example, I’m creating an alias for two FE ports on a VNX and one host port, zoning them together, and creating a new configuration and adding the zone sets to it. The naming convention I generally use is HOSTNAME_HBAx. Nothing spectacular, and it all looks okay in theory. Except when I saved and enable the configuration, a whole bunch of hosts were missing paths. Anyway, great story Dan, but what was the problem?

Dashes.

Seriously, the problem was dashes in the aliases. The CLI was just ignoring them. Change those to underscores and you’re good to go.

Am I overreacting when I feel really disappointed that this is still a thing with FOS 7.x? If someone wants to set me straight I’m happy to hear the whys and wherefores about this. In the end it was all sorted fairly rapidly, and there were no outages which was great.

EMC – FAST and FAST Cache on the CX4-960

Apologies for the lack of posts over the last few months – I have been nuts deep in work and holidays. I’m working on some literature around Storage Pools and FAST in general, but in the meantime I thought I’d share this nugget with you. We finally got approval to install the FAST and FAST Cache enablers on our production CX4-960s a few nights ago. We couldn’t install them on one of the arrays because we had a dead disk that prevented the NDU from going ahead. Fair enough. Two awesome things happened when we installed it on the other array. Both of which could have been avoided if I’d had my shit together. Firstly, when I got into the office the next morning at 8 am, we noticed that the Read Cache on the array was disabled. For those of you playing at home, we had the cache on the 960 set at 1000MB read and 9760MB for write. I think I read this in a whitepaper some where. But after FAST went on, we still had 9760MB allocated to Write, and 0MB available for Read. Awesome not so much. Seems that we lost 1000MB, presumably because we added another layered application. Funnily enough we didn’t observe this behaviour on our lab CX4-120s, although you could argue that they really have sweet FA of cache in the first place. So now we have 8760MB for Write, and 1000MB for Read. And I’m about to configure a few hundred GB of FAST Cache on the EFDs in any case. We’ll see how that goes.

The other slightly boneheaded thing we did was forget to trespass the LUN ownership of LUNs on SP A back from SP B. In other words, an NDU applies code to SP B first, reboots the SP, checks it, and then loads code on the other SP. As part of this, LUN ownership is temporarily trespassed to the surviving SP (this is the whole non-disruptive thing). Once the NDU is complete, you should go and check for trespassed LUNs and move them back to their owners. Or not, and have everything run on one SP for a while. And wait for about 9000 Exchange users to complain when one of the Exchange clusters goes off-line. Happy days.