Installs & Upgrades of VNXe

This discussion is now open. All of our experts look forward to your questions and lively interactive discussion.

Regards,

Mark

Hello Folks,

It's our pleasure to pull a team like this together. Our goal is to increase your baseline knowledge. The Topics being discussed in this thread will surround Installing and Upgrading the VNXe. Please post anything and everything having to do with any aspect of these two topics. This discussion will continue until Dec 14th we encourage the collaborative back and forth dialogue.

Hello everyone,

Thanks Glen and Mark for inviting me to this event! We recently posted an Upgrades FAQs document on the VNXe Support Forum at ECN. As part of this effort, we collaborated with a quite a few folks and got some of the frequently asked questions on upgrades answered. Here's the URL: https://community.emc.com/docs/DOC-19732.

I learnt a lot from that experience. Looking forward to a great conversation here and an opportunity to answer any open questions or share some knowledge/tips on these two topics.

I'm putting this post out to gain insight to gauge efficiencies with upgrading VNXe. We've seen calls coming into support where there is uncertainty to the completion and status of the upgrade. Many times we're being asked "what is the status of the upgrade and is it progressing", even though progress is being made. We'd like to better understand what circumstances are involved here , and the cause of the uncertainty. 

Hello folks! I'm only here to watch this ATE and get a little tips and hints with VNXe as I've never seen one yet. I primarily deal with VNX and even V-MAX, so I might actually learn something here

In the several upgrades I've performed on our VNXe, I have often had the feeling of being somewhat lost in the upgrade process. I think this is because of two factors. The first is that while the system reports it is making progress, and has a countdown, the up update period of the status bar and countdown are very slow. It can sit there for server minutes with no indicaiton that anything is changing, resulting in the admin wondering if things are going well, or if the system has stalled. The second factor that can result is confusion as to the status of the upgrade is that when Unipshere fails over between the the two SPs during the upgrade, it can become non-responsive for a period of time, either not allowing me to log in, or falsely reporting the the last status that was on the screen, when in reality that is stale data that needs to be refreshed.

I believe that smoother failover of Unisphere between the SPs, as well as more frequent updates to the status bar would help us know that things have been progressing well, and continuing to progress well. For many of us (at least in my experience) in smaller shops, a single array is the lifeblood of IT holding almost all of our data, so upgrades are a stressfull time, and that is accompanied by a certain degree of time distortion (things seem to be moving very slowly), and constant and reliable reassurance that things are progressing (or a very detailed message of why they're not) is very welcome.

First off thank you for showing interest and please pass the word around this Event is in place. 

We appreciate the input you've provided along with the suggestions being offered. We're kicking these events off for VNXe to enhance the Serviceability of the product. The two areas you've highlighted are what we experience as common concerns during an Upgrade.

Unfortunately I'm sure this has caused some pain and curious to know some steps you've taken either prematurely or as a work around to complete the upgrade.

I agree with what adimite mentioned.  I have done many software updates and the loss of connectivity to Unisphere is annoying.  That being said, isn't the latest code supposed to use a virtual MAC tha will flow properly during SP failover to help alleviate this issue?

THat should be failover and not flow.

To get around Unisphere disconnecting when failing over between SPs, my solution has been to hit refresh until the system starts responding again, which in past upgrades could be some time.

I have no good workaround for the slowly updating progress bar except to worry that it's stalled, and call support if I'm convinced it has. Thankfully, I've only had to call support once, and that time the system had a legitimate problem.

I've noticed that the upgrade process has improved signifigantly since the early days of the VNXe series, but the system could still be more responsive it terms of update frequency and failover response.

Yes Adimite the upgrade functionality has come a long way but still leaving room for improvement. Your points are well taken and documented which will be included in our summary wrap-up  when this event ends.

Do you have enough information to elaborate on the issue where you needed to contact support? I'd like to make sure we close the loop on that .

In early codes of VNXe actual MAC address of management ports on SPA/SPB were used whenever ECOM (Unisphere Management Service) was running on that SP. That means, whenever ECOM failed over from SPA to SPB it was associated with MAC address of SPB or vice versa.  Though IP address was same, the MAC address was different when ECOM failover happened. This posed a problem in some customer environments where switches are configured with few security features like MAC address filtering. It is something like if Network Admin does not want people to use hub in his network, he will say to switch if it detects multiple MAC addresses in one port, shutdown that port. This is what happens in our case when ECOM fails over. Customer will lose access to Unisphere until Network admin brings up that port.

To alleviate this situation, we associated the ECOM with a virtual MAC address which will not change. Regardless of where ECOM running this virtual MAC will be used for all MGMT communications. Bottom-line, this should not impact the upgrade process. However this change happened only in 2.3.1.20364 code. That means if customer is using any other version is still exposed to problem I mentioned above. Any future upgrades/failover will not affect Unisphere accessibility in MAC address filtering environments.

Experts,

Compared with VNX, there is an additional step for VNXe: license file and need to register on the Internet. It’s a little complex. Why VNXe needs this step?

I checked the support chat transcript to jog my memory. Upon attempting to upgrade the system, the system reported there wasn't enough memory to install the upgrade. I checked a knowledge base article on that error, and the article suggested rebooting the SP, so I did. The SP never came back up, and I contacted support. I needed to hook up the serial console to get them access to the system, and they performed some magic to get it working again. If it helps, the chat incident number was 477328, and the incident occured on 4/15/2012.

VNXe is targetted at Small and Medium Business customers. It's simple and ready to configure with minimum installation requirements unlike VNX which requires planning and experienced engineers to implement. Since implementation is not done by EMC, it is left to customers to register and get the license for VNXe. EMC has taken all care to make this process simple. If there are any suggestions to improve or pain-points please feel free to tell us.