Force virtual IP move during NSM 150 software upgrade

[Dave Brenner]

Most of our iSCSI clients are running Windows or Linux and they don't mind a bit if the NSM with the virtual IP is rebooted. They simply pause for a bit and then continue on with the new VIP holder.

Our Solaris servers are a different story. For whatever reason, they do not behave well in this scenario. Every time we perform maintenance that requires that the virtual IP holder be rebooted, we have to stop all Solaris services that use the LeftHand volumes, then unmount those volumes. We've come to expect this and just plan accordingly.

One situation where this is a problem, though, is during a SAN/iQ upgrade. Because we cannot predict when the VIP NSM will reboot (I do realize that it should be upgraded last) during the upgrade, we have to do the Solaris maintenance steps before we even start the upgrade, which can mean up to an hour of downtime. I have been putting off an upgrade to 7.1 for this very reason.

Which brings me to this...

Rather than using the approach above, is there any reason why I couldn't do a reboot of the VIP holder before starting the upgrade on it so as to force the VIP to move? This way, I am only downing the Solaris stuff long enough to let the HBAs figure out the new VIP holder. Obviously, the other 3 NSMs (we have a total of four NSM 150s) would already be upgraded at this point. Then I can remount the volumes, start the Solaris services, wait for any restriping that may need to be done, and then upgrade the last NSM.

On the surface, this seems like the best way to keep the Solaris downtime to a minimum, but I want to make sure that there are no gotchas. Is there any reason why I shouldn't do this?

We would be upgrading from 6.6.00.0099.0 to 7.0.01.4046.

Thanks in advance!

[Dave Brenner]

No takers?

[Gauche]

I think you have people stumped because of such old SAN/iQ versions.

I've been doing LeftHand for 5 years but I barely remember what 6.6 looks like.

What type of nodes are you running?
Are they supported on any newer SAN/iQ than 7.0.01?

If they can go to 8 or 8.1 I'd say bite off a bigger upgrade and get it over with. Newer versions automate the upgrade process better (like reboot VIP last) and failover the VIP so much faster your Solaris issue could be solved.

If you can't go newer than 7.0.01 then you are right to get there as soon as possible.


All that crud said. I think your idea is sane. Upgrade all the nodes other than the VIP first, once that is done reboot just the VIP, not as part of an upgrade, using your now learned process with Solaris, then when you upgrade the last node it is no longer the VIP. At least you'd be able to time / control when the VIP was rebooted.

Good Luck.

[Gauche]

Duh, now I see 150 in your title. Guess you are right about 7.0.01. Well worth the update from 6.6 still.

[Dave Brenner]

Thanks for the reply. We actually have two clusters. The other one consists of 4 2TB NSM 160's. Ultimately, I would like to move everything over to the 160 cluster, since it is a) newer and b) RAID 5, but it just hasn't happened yet.

Our support/maintenance contract is up for renewal at the end of the year and we would like to renew it, if at all possible. Do you have a number I could call to inquire about renewal?

[Gauche]

Sure, don't know it off hand. I'll ask support people and get back.

Are your 160s and 150s in the same management group?

[Dave Brenner]

No, they're in two different clusters and each cluster is in a different management group and subnet. Same physical segment, though.

The NSM 150 cluster was our first. Later, we added the NSM 160 cluster.