Host-based backup of VMware vSphere VMs.
Post Reply
SimonGreen
Influencer
Posts: 22
Liked: never
Joined: Nov 17, 2015 11:40 am
Full Name: Simon Green
Contact:

Cloud Connect Failover Testing

Post by SimonGreen »

All,

Could do with some insight on the above.

We've signed up to a Cloud Connect provider and now have a replica in the cloud environment so that we can validate and test that we have everything configured correctly. I've configured a Failover Plan for this and basically I'd like to test the process.

What do I need to do in order to bring up the VM in the cloud without impacting on the production VM? I don't actually want to fail over to it but first validate that the VM boots fine and that I can access it? The plan has a public IP mapped to the replica so that I should be able to RDP onto it.

As an aside are there any best practices on configuring for failover? For example should we configure failover plans for individual servers, logical application groups etc. etc? Ideally we would like to be able to failover based on the disaster event impact i.e. individual VM failure, VM host failure or total site failure.

Appreciate any input.

Regards,

Simon
veremin
Product Manager
Posts: 20415
Liked: 2302 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Cloud Connect Failover Testing

Post by veremin »

What do I need to do in order to bring up the VM in the cloud without impacting on the production VM?
We've added test failover plan functionality specifically for this goal.

Individual VM can be tested by powering down source VM and failing over to replica one. It is certainly worth doing it from time to time just to assure that connectivity between you and SP works as expected.
As an aside are there any best practices on configuring for failover? For example should we configure failover plans for individual servers, logical application groups etc. etc?
In general, it depends on your needs and desires. If there is some dependency between different sets of VMs, more specifically, which group should be powered up first and which afterwards, it stands to reason to place them in different failover plans.
Ideally we would like to be able to failover based on the disaster event impact i.e. individual VM failure, VM host failure or total site failure.
Failover type would vary, depending on disaster type. Either partial or full site failover would be needed.

Thanks.
SimonGreen
Influencer
Posts: 22
Liked: never
Joined: Nov 17, 2015 11:40 am
Full Name: Simon Green
Contact:

Re: Cloud Connect Failover Testing

Post by SimonGreen »

Thanks for posting this.

I presume that I can perform a 'start failover' at any time in order to test our DR environment fully and that this has no impact on the production services i.e. they just continue unaware of the fact that the services have been instantiated at the DR site? When complete we can just 'Undo' which brings the DR services offline again?

Regards,

Simon
veremin
Product Manager
Posts: 20415
Liked: 2302 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Cloud Connect Failover Testing

Post by veremin »

I presume that I can perform a 'start failover' at any time in order to test our DR environment fully and that this has no impact on the production services i.e. they just continue unaware of the fact that the services have been instantiated at the DR site?
You meant start failover plan, right? (as usage of partial failover would result in IP collision - two VMs having one IP address)

With start failover plan there should not be any issues, as long as no service tries to reach replica VMs under new address defined in RE-IP rules.

Thanks.
Post Reply

Who is online

Users browsing this forum: Baidu [Spider], Majestic-12 [Bot] and 42 guests