Migrating hosts to new storage ports, LIVE!
Many SAN administrators will face this challenge from time to time: certain hosts need to start using new storage ports. Reasons vary, but in the EMC Clariion/VNX world this might happen because it’s decided to dedicate the mirrorview ports to mirrorview only instead of allowing hosts to use these ports as well. Obviously having dedicated replication ports will improve replication performance and for synchronous replication this will also improve the production host performance since the write acknowledgement from the remote array will be quicker and the extra latency is limited to a minimum.
So you end up wanting to free the SPA1 and SPB1 ports (most Clarrions) or SPA0 and SPB0 (VNX). But disalowing hosts to use these ports means they will loose access to these paths. This just might be disruptive! Or not?
There’s a way to migrate nondisruptively!
To make sure a host always has access to its disks you must make sure that there will always be working paths. So adding the new paths before removing the old will do the trick! Check this on your host and not just in your storage array, because although a new path (=zone) might be in use by an HBA, its operating system might not have picked it up and therefore not use it. The worst case scenario will be that you need an HBA restart or even a host reboot to get the new paths working.
Last weekend Jon Klaus (www.faststorage.eu) and I performed this change with success! Let me describe the steps how we did it:
- First create the zones to the new storage ports in each fabric
- Add these new zones to the active zonesets in both fabrics
- Enable the zonesets one by one (not at the same time!!)
Check if the new paths are visible in Unisphere (each of the new paths should be visible as “logged in”, but “not registered- On the (Windows) host now restart the Navisphere Agent service (or register the new paths manually if you don’t have the Navisphere Agent installed)
Check if the new paths are visible in Unisphere (logged in, but registered this time)
Open the Storage Group in engineering mode and tick the extra paths for this host- On the host now rescan the disks (Windows: disk manager, right click and choose “rescan”; VMware “rescan SAN”) to create some traffic on all paths
- Check if all paths are visible on the host (in Powerpath you should now see extra paths per disk and in VMware you can check the extra paths in datastore properties for this host; for each available datastore you will now see this)
If you’re using PowerPath you could put the old paths on “standby” so no more I/O uses those paths, but not doing so should be nondisruptive as well since PowerPath will automatically stop using any dead paths. Putting them on standby before removing the paths is the preferred way of course- Now remove the old zones from the active zoneset and enable the zonesets again in both fabrics (one after the other once again!!)
In PowerPath you can now remove the dead paths from the config (“remove from config” in the PowerPath GUI in Windows or by using the command “powermt check”, which works on all operating systems with PowerPath installed)- The final step is now to deregister the old paths in Unisphere
Now your host no longer uses the storage port you wanted to free up and if all went well the host never even noticed its configuration changed! Sometimes though you might need to initiate a rescan more than just once and maybe you’ll even need a reboot to get the new paths working, but you normally should not encounter this behavior.
0 Comments.