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
-
- Influencer
- Posts: 22
- Liked: never
- Joined: Nov 17, 2015 11:40 am
- Full Name: Simon Green
- Contact:
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Cloud Connect Failover Testing
We've added test failover plan functionality specifically for this goal.What do I need to do in order to bring up the VM in the cloud without impacting on the production VM?
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.
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.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?
Failover type would vary, depending on disaster type. Either partial or full site failover would be needed.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.
Thanks.
-
- Influencer
- Posts: 22
- Liked: never
- Joined: Nov 17, 2015 11:40 am
- Full Name: Simon Green
- Contact:
Re: Cloud Connect Failover Testing
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
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
-
- Product Manager
- Posts: 20415
- Liked: 2302 times
- Joined: Oct 26, 2012 3:28 pm
- Full Name: Vladimir Eremin
- Contact:
Re: Cloud Connect Failover Testing
You meant start failover plan, right? (as usage of partial failover would result in IP collision - two VMs having one IP address)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?
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.
Who is online
Users browsing this forum: Semrush [Bot] and 28 guests