- Poll: How reliable are ChatGPT and Bing Chat? - Tue, May 23 2023
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
The best way to understand Hyper-V Recovery Manager is to look at the figure below. Using the Hyper-V Replica feature of Windows Server 2012, virtual machines are directly synced between a primary site and a secondary site—that is, replication data does not go through Windows Azure. Hyper-V Recovery Manager only receives metadata from virtual servers that it requires to orchestrate disaster recovery. Aside from Windows Server 2012, Virtual Machine Manager 2012 SP1 or R2 is also required.
Windows Azure Hyper-V Recovery Manager
Administrators manage recovery plans in the Windows Azure Hyper-V Recovery Manager web console that determine what happens in case of a failure. The service can also be used for planned data center migrations and for testing failover capability.
Steps to get started with Hyper-V Manager
Aidan Finn raised a few concerns about Microsoft’s new cloud service. He complains about the pricing ($16/month per virtual machine) and the reliance on System Center. However, his main criticism is about the idea of putting the DR failover/orchestration system on a different location than the DR site.
I think the market will decide if the price is justified or not. If the reliance on Virtual Machine Manager has a technical foundation—that is, if the required functionality could have been built into Recovery Manager without raising costs—it is hard to tell.
I think the third concern is valid only if two sites are involved. However, if you have multiple sites and complex inter-site relationships, you want a centrally accessible tool to manage your DR plans.
The other question is if this tool has to be in the cloud. Scalability and reduced management costs are not the issue here because Hyper-V Recovery Manager probably just needs one server. The point of running your DR tool in the cloud is that you can introduce an additional independent site with a guaranteed high availability.
Your DR plan won’t work, say, if you have six sites and site 6, which hosts your DR tool, goes down. But if your DR tool runs on site 7, which is in the cloud, site 6 can fail over to another site and you are spared the costs of renting a new building for site 7. Of course, you can also run your DR tool on every DR site, but this would certainly increase your management costs.
However, if you have only two sites, it probably makes more sense to host your DR tool on the DR site because, by using an external tool in the cloud, you introduce three new points of failure in your DR topology: the cloud service and the two network connections to the cloud.