We have experienced this in the past as well. During a Flarecode upgrade processors are upgrade one at a time. Once the first is completed a SP reset / reboot occurs which briefly disconnects the SP from the fabric. A host will only notice this if it's written and block at the moment in which case a trespass will occur and the write will be committed.
Although it’s a Non-disruptive upgrade there is this potential “disconnect” for a device that is writing at the moment. Hence the suggestion to perform Flarecode upgrades during a “quite” IO time to avoid this.
So with an NDU it actually doesnt mind which SP is which,
What I mean by that is SPA and be either the primary or the secondary in the NDU
The NDU process will only reboot one SP at a time (although it can reboot an SP more than once due to driver updates)
If what you are saying Syed, that while one SP was rebooting, that you lost access to hosts on the other side, then that should be investigated further to determine what happened during the NDU
I agree with Gearoid on this, if you lost total connectivity to a host during the Flarecode further investigation is required and it's likly that you have a configuration issue with that host.
My question is simple,,
Which SP is primary ?
Because I see SPb reboot and ndu was saying primary rebooting
Syed Ahmar Amjad
Technical Team Leader
MDS Systems Integration - Storage Solutions
It depends on which SP you logged into to start the NDU - if you log in to SPA, then SPA is the Primary and SPB will be the first to reboot. If you log into SPB, then SPB is the primary and SPA will be the first to reboot.