Non-disruptive upgrade path 2.0 ->2.1 when using default zoning?

[Tore Anderson]

Hi. I have a UCS system running version 2.0(5a). I'd like to upgrade it to 2.1(3b), but the warning in the release notes about the removal of default zoning has me worried, as I have a couple of directly attached FC storage arrays, and my Fabric Interconnects are operating in FC switch mode. The VSANs have default zoning enabled, as this was the only way I managed to make them accessible to the hosts.

http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/upgrading/from2.0/to2.1/b_UpgradingCiscoUCSFrom2.0To2.1.html#concept_9DAFEA7A78444CF6AE860D8FAF143B7B

As far as I can tell, it is impossible to prepare for the new style zoning with using Storage Connection Profiles associated with vHBA Initiator Groups while still running 2.0 - I would need to upgrade to 2.1 first. However, if I understand the 2.1 Release Notes correctly, the act of upgrading will break all storage connectivity until I've managed to reconfigure all the service profiles to use the new style. This is obviously not very tempting; one of the primary reasons for having a redundant set of Fabric Interconnects and Fabric Extenders is after all to be able to perform rolling non-disruptive upgrades where you to each fabric sequentially. But how exactly would I go about doing this, considering that there does not appear to be an interim release that supports both the old and the new style of doing things?

Tore

[Walter Dey]

please see https://supportforums.cisco.com/message/3796303#3796303

Solution:

If you're using default/open zoning, you will need reconfigure your system & hosts and disable it prior to upgrading to UCSM 2.1 to avoid any operational impact.  Once upgraded you can leverage the new FC zoning feature to create 1:1 zones for Iniators & Targets.

[Tore Anderson]

But how, exactly, would I go about «diabling [default zoning] prior to upgrading»?

As I understand it, if I were to disable default zoning right now (while running version 2.0), the hosts would no longer be able to communicate with the storage arrays - as without the default zoning active, nobody can speak to anybody on the FC fabric. This would in turn cause service disruption, which obviously is precisely the thing I am trying to avoid.

Or am I missing something? How can I reconfigure my 2.0 system to avoid the use of default zoning, yet maintaining connectivity to the directly attached FC storage array?

Tore

[Walter Dey]

default zoning enabled simply means, any to any is allowed (permit any); therefore you take one fabric eg. B, disable default zoning, and create proper zoning (eg. single initiator - single target); during this time Fabric A is still operational. This of course requires that FC multipathing is setup properly; then you check the zoning, and if ok, do the other fabric.

[Tore Anderson]

Well, again, the problem is that default zoning isn't available in UCSM 2.0. As it clearly says in the release notes warning I linked to: Fibre Channel zoning, a more secure form of zoning, is available from Cisco UCS, Release 2.1(1a) onwards. (emphasis mine).

And indeed, in UCSM 2.0, there is no FC Zones tab in the service profile view. There's no vHBA Initiator Groups under the Storage tab. And there's no Storage Connection Policies node in the SAN tree. I also have a system running UCSM 2.1, and it does have all of those things, and I use them to successfully configure specific FC zoning that works with directly attached arrays. So I'm very aware of how it should look in the end, but what I for the life of me cannot understand is how you mean I should configure my UCSM 2.0 system to the new system with explicit FC zoning, when UCSM 2.0 simply does not support this?

Tore

[Walter Dey]

Sorry, I should have to be more clear: In V2.0, you could either have default zoning on the FI, and/or a MDS/N5k attached to FI, doing proper zoning, pushing the zoneset to the FI. That's what I was assuming; however, it seems you have no external switch.

In V2.1 onwards, you can of course do FC zoning on the FI, without external FC switch.

[Tore Anderson]

Yes, like I said in my initial message, the storage arrays are directly attached. (If the UCS system had reached them through external FC fabrics, I would in all likelihood configured the FIs in FC End-Host mode instead, and not worried for a second about FC zoning within the UCS infrastructure).

So my question still remains: How would I go about upgrading from UCSM 2.0 to UCSM 2.1 in a non-disruptive manner?

Tore

[Walter Dey]

You don't seem to have the complete history of direct storage attachment to UCS

Issue:

Default/Open zoning was supported in version prior to UCSM 2.1.  In the storage world this is known as IMPLICIT PERMIT. Default zoning was used to allow the direct connection of storage devices to the Fabric Interconnects. For direct connect devices we also allowed for zoning to be pushed from an upstream storage switch.  The only "supported" use of direct attach FC storage required an upstream SAN switch. Even with an upstream SAN switch to provide the zoning configuration, default zoning was still possible.

V1.4

V2.1

Therefore my conclusion: with a northbound fc switch, you can do a non disruptive update; without a FC switch, no way !!!

I hope this is clear now ;-)

[Tore Anderson]

The only "supported" use of direct attach FC storage required an upstream SAN switch.

Well, this is an oxymoron. If you're putting a switch in between, it no longer is directly attached.

Also that directly attached storage isn't supported as of V1.4 and April 2011 is demonstrably false, as I have it running here today, on V2.0, and it's working just fine. But even if it was the case that this stopped working in April 2011, there is still a profound lack of a non-disruptive upgrade path from whatever was there in March 2011 up until today...

Therefore my conclusion: with a northbound fc switch, you can do a non disruptive update; without a FC switch, no way !!!

This is the conclusion I came to as well after reading the V2.1 Release Notes. However I could not really bring myself to believe it, and was really hoping I was overlooking how to actually do it. After all UCS is supposed to be a high end system, and non-disruptive upgrades is really essential functionality. That Cisco appears to have decided that «we're going to change this around, and nevermind those that used the old functionality, we'll leave them high and dry» is very, very disappointing.

Tore

[Walter Dey]

This will be my last reply

Well, this is an oxymoron. If you're putting a switch in between, it no longer is directly attached.

It's a fc switch on a stick !!! therefore the storage is directly attached to the FI

Also that directly attached storage isn't supported as of V1.4 and April 2011 is demonstrably false, as I have it running here today, on V2.0, and it's working just fine.

Working fine ! means you used permit all, which is not usually accepted by storage folks; you completely miss the security of zoning, and rely on lun masking/mapping.

You are not doing any zoning

And working is not identical to supported !

Therefore if you would have a supported configuration with a fc switch on a stick, non disruptive upgrade would be possible

you are essentially migrating a configuration without zoning (permit all) to a configuration with zoning (on the FI)