SRM DataCenter migration Question

[pchafer]

Hello,

We are looking to use SRM to migrate VMs from one DataCenter to another.

One concern is the footprint SRM leaves on the VM that has been replicated.

We are using vSphere replication.

Question:

If we power on the replicated VM in the new DataCenter and an issue occurs with the application is there any footprint left on the original VM that could cause issues with powering it back on?

ie. We basically revert back to the original VM. Does SRM need a clean up before such task?

Thanks in advance for any info.

Peter.

[Smoggy]

are you asking can you power on the original VM without using SRM's reprotect / fallback workflows?

i.e you protect a VM in SiteA, use SRM to recover it to SiteB, VM is recovered to SiteB but post recovery you decide application "doesn't look right" and want to power on SiteA VM again?

I guess question at this point is what makes you think in this hypothetical scenario that the application does not look "right" if this is data related chances are same issue is resident in SiteA VM's virtual disks. If data is corrupt because application has mangled it then its restore from your backups to correct unless application can roll back.

If you want to forcibly power a VM on at the protected site without using the reprotect / failback process then this could be done manually but SRM won't like it as you are effectively altering its management of the protected and placeholder VM's and you would need to clean that up later if you wanted to continue using SRM.

Usual way to revert to the SiteA VM would be to reprotect in B->A direction, test failover B->A (check all ok), planned migration (B->A), reprotect again. You are then back where you were.

[pchafer]

Yes that's exactly the question. Can we just power back on without going through the failback process? So it can be done manually but is the clean-up process easy or quite cumbersome?

We've had issues in past migrations where services, for what ever reason, won't start after the replication and failover. These will be mission critical VMs that we are migrating so any issue needs to be dealt with as quickly as possible even if that means reverting back to the original VM at the original site.

I'm wondering if just using vSphere replication, without SRM, is a simpler method?

We are on version 5.1 across the board.

Peter.

[Smoggy]

well one of the features SRM brings to the table for vSphere Replication is "Test Failover". This will allow you to test your protected workloads in isolation at the recovery site without affecting the running production workloads. If the applications continually fail to start in this test "bubble" then you now have the means to root cause that. Most applications built within the last 15 years should easily be able to restart from crash consistent images. if this is not the cause for your apps then you can use this facility to troubleshoot that now rather than wait till its too late.

if you use vSphere Replication without SRM then you could perform a failover but vSphere Replication would expect you to power off the source VM (it won't do this for you but will warn you). The danger here is that unless the network is isolated correctly if you ignore the warning then you have the same VM powered on in two locations and if there is a route you missed between the two VM's on the network then things might get confusing for the application owner!

So without SRM you could just power back on the source VM and then manually reconfigure replication in the same direction (VR would then checksum source/target disks) as before and then wait for the initial sync to checksum and resync the disks but you have no isolated test capability and all reconfigure steps are manual OR you use SRM and its testing feature plus the reprotect workflows to reverse replication/failback and reconfigure and steps are automated via SRM's orchestration capabilities i.e the recovery plans. if you use the test failover options effectively then the scenario where you need to power on the source VM to resume the application is going to very rare given that its questionable why you would have performed a planned migration or failover in the first place if the source VM was working OK. Usually if an application stops working its the data. If the "corrupt" data has been replicated to the target then source/target will be affected...this is why you still need backups for worst case scenarios of data corruption that your application cannot unravel itself.

hope that helps?

[pchafer]

Fantastic informative reply, Lee! Thanks very much.

SRM sounds the way forward with the testing in a bubble feature.

I am a lot more confident for the migration now!

Thanks,

Peter.

[pchafer]

One last quick question if you don't mind!

Access for user testing within the SRM Bubble network before the production cutover:

1) How would you give this access for people on the WAN? Some VDI client or something with local permissions as AD wouldn't be available although I guess cached accounts may still work ok?

Cheers!

Peter.