Changing domain allocation from preferred to static

[dean.allen1]

Hi folks.

I am about to embark on a project to move a customer from a MDS 9509 based core to 9396S. It will be a staged implementation, so I want to make sure all the fcdomains and switch priorities are set right so as not to cause any disruption. 

All of the VSAN domains on each switch are unique, which is good, and most are static, but one of the core switches has the domain preference as "preferred" for the main prod VSAN.

I'd like to change this to "static" before I hook in the new switches via ISL, and I want the new switches to be the primaries.

So I guess I have 2 questions:

1. If I set the fcdomain on that one switch/VSAN from "preferred" to "static", WITHOUT changing the domain ID, will that be disuptive? The docs seem to be inconclusive about this. Everything I've read says it "may" cause a disruptive restart of the VSAN.

2. The second question is about switch priorities. The plan is to setup ISLs b/w the 9396S's and the 9509's, and I move over the storage to the 9396S's,then they move the hosts over later, and decomm the 9509s. So we want the 9396S's to be the primary switch eventually. So... if I set the priority on the new 9396's, in advance, to be higher (numerically lower) than the existing configuration, will that cause any disruption? Or will things just stay as they are in the interim with the 9509s as the primary, then once the 9509s get disconnected, the primary will just move to the 9396S's? Is the reallocation of a primary switch disuptive?

I've been doing a lot of reading, but haven't found anything conclusive about this kind of thing.

Thanks,

Dean

[Walter Dey · Accepted solution]

Hi Dean

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/mds9000/sw/5_2/configuration/guides/sysmgnt/nx-os/sysmgmt_cli/domn.pdf

A disruptive restart is required to apply most configuration changes, including manually assigned domain IDs. Nondisruptive domain restarts are acceptable only when changing a preferred domain ID into a static one (and the actual domain ID remains the same).

If you perform a nondisruptive restart, build fabric (BF) frames are sent to other switches in the fabric and data traffic is disrupted only on the switch.

By default, the domain manager starts a build fabric (BF) phase, followed by a
principal switch selection phase. Both of these phases involve all the switches in the VSAN and together take at least 15 seconds to complete. To reduce the time required for the domain manager to select a new principal link, you can enable the domain manager fast restart feature.

switch(config)#fcdomain optimize fast-restart vsan 10

Walter.

[dean.allen1]

Thanks Walter.

So I take from that, that changing the 9509 VSAN which is currently "preffered" to "static" will not be disruptive, as long as I set the static VSAN number to the same as the  preferred one.

The next step (which is out of my scope of works), once the customer has migrated all their hosts over to the new switches, they'll shutdown the ISLs to the 9509s, which would trigger a fabric rebuild and the 9396S's would become the primary.

I'll set the fast-restart to minimise any disruption this might cause.

Thanks again

Dean

[Jason Mooney]

You are correct, there will not be a disruption when you set the static to match the the preffered domain id.

[p11l]

Hello together,

sorry for the late answer but I've one question about that.

I need to change a few domain-id and fc priorities to change the principal. If I do so I want to use the fast-restart command but as Walter said I dind not understand right.

I read in the user manual that I need to have a 'backup link'.
https://www.cisco.com/c/en/us/td/docs/dcn/mds9000/sw/9x/configuration/system-management/cisco-mds-9000-nx-os-system-management-configuration-guide-9x/configuring_domain_parameters.html#con_1597441

At the 'Domain Manager Fast Restart' section.

When fast restart is enabled and a backup link is available, the domain manager needs only a few milliseconds to select a new principal link to replace the one that failed. Also, the reconfiguration required to select the new principal link only affects the two switches that are directly attached to the failed link, not the entire VSAN. When a backup link is not available, the domain manager reverts to the default behavior and starts a build fabric phase, followed by a principal switch selection phase. We recommend using fast restart on most fabrics, especially those with a large number of logical ports (3200 or more), where a logical port is an instance of a physical port in a VSAN.

So I understand the command make only sense to me if I've a second physical link from my new mds to the actual running principal.
If one link fail then the fabric does not make a disruptive recalculation from about 15 seconds. The Fabric change the link to the actual fabric in a few miliseconds.

Is that right so I must to do a fully disruptive recalculation to reach the above goal?

Thanks!

[Jason Mooney]

There really isn't isn't going to be a good reason to change the pricipal switch, unless you know you are removing multiple devices and would prefer not to have it auto-negotiate more than once per fabric.  

To manually change the principle it will cause a disruption.  It's the same amount of time if you shutdown an ISL to an decomissioned device that was previously principal.