Upgrade SRM 5.8 to 6.5 in a Side-by-Side Migration. Coexistence?

[Obsidian120]

Hi all,

I have a client that wishes to upgrade their vSphere platform from 5.5 to 6.5 via a side-by-side migration.  To ensure as little production downtime as possible, ESXi 5.5 hosts will be disconnected from vCenter 5.5 and re-connected to the new vCenter 6.5 environment.  To accomplish this, all SAN LUNs, networks etc will be shared across all ESXi 5.5 and 6.5 hosts.

Part of this project will require the migration and upgrade of SRM to 6.5, however as the new vCenter 6.5 will be a new instance and not an upgrade I am not sure how the SRM migration should proceed.

The current SRM configuration is a fairly simple Prod/DR arrangement:

- Protected Site (Production)

- Recovery Site (DR)

- EMC FC storage

- Array replication and EMC SRDF's used.

The client wants to create a new SRM 6.5 instance in the new vCenter environment but I have concerns around having any kind of storage coexistence between the production SRM and new 6.5 SRM instances.  Is there any way to safely share LUNs/Datastores in a way that facilitates an easy SRM transition or will I be forced to uninstall/disable the original SRM environment before the new SRM 6.5 can be configured?

Cheers

[jhague]

‌I think in this instance you would need a fresh install of SRM because you are moving to a new instance of vCenter and much of the information used by SRM will no longer be relevant because vCenter and SRM are so intrinsically linked (IDs will change in the DB etc.). There is a KB article which talks about migrating SRM to a different server but says to avoid vCenter inventory changes for exactly this reason.

Migrating an SRM server to run on a different host (1008426) | VMware KB

The other issue would be the SRM database would be based on an older version so you'd have to upgrade that also. You'd probably need different versions of the SRA. Sounds to me like it would be a hack trying to migrate SRM in this way and a fresh install as per vCenter would be the safest and cleanest way to proceed.

[Obsidian120]

Thanks for the reply Jhahue, however I am not performing an upgrade of SRM.  As we are moving to a completely separate vCenter instance then an upgrade of SRM is out of the question.

What I'm trying to work out is how to create a new instance and do so in a safe manner considering the client will be sharing LUN across all ESXi hosts.  I am suspect on just how much coexistence of multiple SRM instances or shared storage would be possible, if any.  Or will i simply have to completely uninstall SRM as a first step before anything else is attempted.

[jhague]

Sorry had misread your post. What are you using for replication and what does the new environment look like from an array / replication perspective? I.e. the LUNs that are presented to both environments aside, are the new LUNs on the same array or new array - will the VMs be vMotioned into new LUNs?

‌

[Obsidian120]

No problem at all, thank you for helping.

From a storage perspective its rather simple, a single EMC Symmetrix array replicating all LUNs to another Sym in the DR datacenter.  I believe the replication is SRDF/A.

All LUNs are on the same array (Prod), all replicating to the other array (DR).  As for the VM's, as we are creating a new totally separate vCenter 6.5 environment, we cannot vMotion to the new hosts.  Instead we will be disconnecting the ESXi 5.5 hosts and reconnecting them to the vCenter 6.5 environment to be upgraded later.

To give you an idea, here are some Visio diags I have roughly knocked up to demonstrate the suggested approach.  I am not sure just how much coexistence the shared LUNs across the SRM enabled and SRM non-enabled ESXi hosts will play out.  Or the exact cut over methodology of SRM itself, I am hoping there is a less intrusive way to go about the migration.

Note: The number of ESXi hosts and VMs is not to scale and used for illustrative purposes.

(Visio Diags removed)

1) Current state

2) Zone new 6.5 ESXi hosts into production LUNS

3) Install but don't configure SRM in vCenter 6.5 environment

4) Uninstall/Deconfigure old SRM, configure SRM 6.5 for new environment.  Noting Production VMs are not protected

5) Disconnect ESXi 5.5 hosts, reconnecting to vCenter 6.5.  SRM 6.5 discovers production VMs.

[jhague]

‌First of all I don't have much experience with SRDF so not really sure of the realms of the possible there. I think with storage co-existence between environments it would be ok as a transitional thing if one vCenter 'owns' the LUN so you don't get lots of changes happening in different places. Cant see why the approach above wouldn't work - SRM wouldn't be aware of where the LUNs are presented - it would only care about consistency between its config and the vCenter inventory and the data store. As you mention you'd have a short window where there was no SRM protection (though replication would still be happening in the background).

Another possible alternative is a more staged approach (depending on whether SRDF could support different SRM servers controlling different consistency groups).

1. Present datastore to new environment

2. Connect host to new vCenter

3. Register VMs with new vCenter / remove from old vCenter

4. Storage vMotion VM onto new data store (protected by new SRM)

5. Put host in maintenance mode, evacuate VMs & upgrade host

6. Add host to new environment

7. Back to step 1

[Obsidian120]

Thanks for the reply jHague,

You've touched on all the points I have been mulling over.  I'm pretty sure the above transition will work more less but its not ideal.  I was hoping there was a different approach that didn't involve provisioning new Datastores/LUN's.  Normally I would just build two completely separate environments and Storage vMotion the VM's over but I've been told there will be no new LUNs available for us at all.

If I were to uninstall SRM from the original vCenter, would the new SRM instance have any issues with the original placeholder Datastores etc?  Would there be any clean up needed etc?

Ideally I'm hoping for someone to tell me I am 'doing it wrong stupid!' and suggest a better way.

Cheers

[vbrowncoat · Accepted solution]

Having 2 SRM instances managing/seeing the same LUNS won't be an issue so you don't need to worry about creating new ones. The only time you'd have a problem with that is if you had to run a failover as that would confuse the remaining SRM pair.

You can use the same placeholder datastores, though I wouldn't recommend doing that at the same time. Remember placeholder datastores can be very small and shouldn't be replicated.

[Obsidian120]

Thanks for the reply gs_khalsa,

Sounds promising.  So you see no issue with 2 separate SRM instances managing common LUN's/Datastores/VMs so long as the placeholder Datastores are different and no recovery actions are taken?

Ideally thar is what I was hoping I could do - share the array with 2 SRM instances while ESXi hosts are shifted about.

Cheers

[vbrowncoat]

Correct.

[Obsidian120]

Thanks for the help.  Just one more question if I may?

Would you suggest that we "unprotected" the affected VM's prior to moving the ESXi hosts to the new environment?  My thinking is removing any registrations in the original placeholder Datstores is likely a good idea.

Thanks again.

[vbrowncoat]

Yes, I would recommend unprotecting the VMs and remove them from PGs prior to moving the hosts the VMs are running on.

[Obsidian120]

Brilliant!  I think I have a sufficient idea to test the scenario out.

Thank you very much for the help, much appreciated.

I will flag a correct answer once the testing has been completed.

Cheers once again.

[vXav]

Hi, it was a while ago but can you provide some feedback on how things went ?