Migrating Local Service Profile to Global (UCS Central)

Hi!

I'm working on a project that involves migration of a number Service Profiles from one UCS Domain to another and I'm looking for a best way to do that. It seems that UCS Central can help me with that, however the service profiles need to become Global however there's no automated way to do that. From what I understand, this can be achieved by re-creating a service profile as global, but I'm looking for a way to assure that it will have the same IDs (MACs, WWNs, UUIDs) as the LSP had. All the LSPs were created from templates and all the IDs were auto-assigned from pools. I wonder if it's possible to "move" an ID from one Service Profile to another in a way that it would still be tracked by the corresponding pool. Does anyone have any experience with this?

Thanks,
Ivan

Greetings Ivan,

Technically you cannot move an ID from one pool to another physically, but you can create a duplicate pool at the Global Level within UCS Central. UCS Central is adept at keeping track of ALL ID's in your infrastructure, whether those ID's are defined in Local Pools on registered UCS Domains, or if they exist as Global ID Pools within UCS Central.

Unless you have a very unique implementation, I am guessing it would be acceptable if your MAC ID's change....but keep the same pattern.

UUIDs will have to change...they are "unique", and crafting a Global UUID Pool will insure that the Prefix is Unique. As for MAC's, you can duplicate your exact scheme Globally, easy enough.

Usually, the ID's that cannot change for customers are those Storage IDs....WWNNs and WWPNs. Again, you can craft the Pools Globally to insure the exact same pattern exists.. When you create your G-SP's from the G-SP Templates....you will in-fact sequentially grab values from those Global Pools....and, if those values are in-fact different from that specific ID that is required per the Local SP, then you can manually edit those Global WWNN/WWPN IDs and make sure they are the same.

At the end of the day....there's no "Easy Button" to magically transform a Local SP into a Global SP....however using the concepts above, you can get there. It will be a One-for-One Swap of a given Local SP for it's Global SP Counterpart...and of course, that is a disruptive operation. This is obviously an easier process in Hypervisor Environments, as you can leverage vMotion/Live Migration to evacuate workloads from a given server(s) placed in Maintenance Mode. Also to note...you'll have to delete the Local Service Profile "before" you associate the Global Service Profile....because UCS Central will recognize that the Local Service Profile exists....and has consumed the same IDs as you have crafted Globally in your Global SP...and to state again, UCS Central will not issue Duplicate IDs. If you tried to Associate the Global SP down to the Blade, before the Local SP is deleted, your Association will Fail.

Finally, you can leverage UCS Central PowerTools to automate this process...but your project scope would likely dictate the time it takes to create the script.

Also, you can easily "Lab" this exercise using another Instance of UCS Central plus registering UCS Emulators to that UCS Central....everything you need to do can be exercised within that Virtual Environment.

Hope this helps.

Regards,

Matt

Hi Matt,

This is pretty much what I was thinking about that too. I'm going to try and write a script to test this out (against platform emulators) and see how easily that will go.

Thank you so much for your prompt response.

Regards,

Ivan

Hi Ivan,

I went through the exact same project about a year ago.  I've uploaded the script I wrote for the process but be warned, there isn't a whole lot of error checking and a lot of parts (specifically the zoning) are very specific to my environment.  However, you're welcome to modify it for your own environment.

Script Steps

1) Run script by passing a UCSC instance

2) Logs into UCSC and returns all connected UCSM instances

3) Select a UCSM instance and a currently associated local profile

4) Select a UCSC template to create the new global profile from

5) Select a LAN Connectivity policy to apply

6) Tests connectivity to a given SAN (see note below)

7) Select SAN to zone host too (see more notes)

8) Select a SAN storage group

9) Creates a new global profile with the chosen settings

10) Zones the new profile on the appropriate SAN switch determined from the prefix of the chosen SAN name (customized, see notes)

11) Removes the old initiators from the VNX

12) Registers the new initiators to the storage group you selected

13) Disassociates the local service profile and once successfully disassociated, deletes the local profile

14) Associates the new global profile to the same blade location

Notes:

1) Uses plink to send SSH commands to Cisco Nexus switches

2) We use the server's name to determine if it is odd or even and zone SAN ports appropriately  This is used both for the zoning section as well as registering the initiators with the array.

3) The "SAN" section in the global variables is used for both adding the new initiators to an EMC VNX as well as creating the zones in the Nexus switches.  Note the zoning commands are all pre-populated with the SAN Names.  I've scrubbed the script of the names and replaced them with <SANNAME> where appropriate.

4) For the creation of the naviseccli command file (if using an EMC VNX) you will need to update the test SAN URL or comment out the block.  Script assumes LDAP security so you can change the scope if needed.

5) Script assumes that the SAN name is resolvable to a storage processor (for the VNX).  You may need to update the naviseccli -h commands to make sure you can connect

6) The SAN de-zone commands are all hard-coded with all possible zones in our environment.  This actually helped us clean up zones that didn't match the proper port associations based on even/odd names.  As with the above I sanitized the commands so if you do want to use the zoning section, spend a lot of time here.

7) I determined which set of Nexus switches to use based on the prefix of the SAN name (and therefore datacenter location).  More sanitation

8) I wrote this almost a year ago when the UCSC powershell cmdlets were VERY lacking.  They've added some useful cmdlets such as associating a blade which used to be very cumbersome to do.  The script should still work but use at your own risk.

9) For some reason you will get an "CMD" error when the plink SSH commands finish but as long as the commands themselves are correct, the zoning works despite the error.

10) The script adheres to our naming standards and conventions (e.g. all capital service profile names, lower case zoning, etc).  You will need to adjust theses to fit your environment.

Lastly, this script worked 9 out of 10 times but I did babysit it.  I didn't write a whole lot of error checking and try/catches because it's a one-off project; once the profiles are migrated you're done forever !

Hope this helps.

-Alex

many thanks !