The last 12 months has been very exciting for Windows Azure Customers like us who have long-wanted to host traditional virtual servers in Azure. The list on the Azure bar portal bar is getting mighty long, and finally getting things that matter to administrators who fit this description. I don’t mean to say BizTalk and Media Services aren’t extremely cool, impressive and hopefully profitable endeavors for the true cloud application development world, but I don’t know any of those people.
Today’s topic, how Microsoft is ALMOST there with Windows Azure Disaster Recovery features. It’s been about 3 years since the writing on the wall became clear: some day you would be able to Live Migrate VM’s back and forth from Hyper-V to Azure. It seems like every major new feature release in Windows Azure, and the amazing new features in Server 2012 followed by those in R2 have inched us ever closer to providing that ability (which many administrators have wanted for a long time).
Here’s how it’s supposed to be:
-Run some virtual machines in Hyper-V on-premise
-Run other virtual machines in Azure
-Replicate between the two
-Let us do Live Migration and Disaster Recovery
What’s Already Done
-The VPN capability has been in place for a long time
-Virtual Machine Manager’s is “public-cloud” aware
-You can now copy VHD’s from On-Premise to Azure and boot it up
-Hyper-V Recovery manager Has the Logic To Orchestrate a Failover Scenario
-The virtual network features in Server 2012 R2 solve one of the bigger networking issues
-Azure Backup handles the file level backup and restore piece
What we’re waiting for (not that much new technology actually):
-Simple, efficient, deduplicated, thin, replication from my local VHD’s to azure storage
-Opening up the “Recovery manager console” to include “Live Migrate Server to Azure”
The latter does involve one legitimate difficulty which I will summarize, although I do not believe it is technically challenging for the developers to enable. When one would migrate a VM from Hyper-V to Azure with the current functionality (copy an offline server VHD to Azure and then boot it), Azure programatically adds a new NIC with a new IP which is remotely accessible. This is fine, but to enable such live migration in a way that would actually be useful and awesome, the IP’s of the servers would have to be able to remain the same after the move. In my opinion, the most likely and supportable solution would be to allow us to “Extend” an Azure virtual network down to my on-premise environment over the VPN. With this, administrators would need to build or change their on-premise servers to have an “Azure IP” and a “Azure virtual NIC” that Azure would accept during the migration. This is the only way to enable the feature without seriously reworking some of Azure’s core networking principles (which simply wouldn’t be right).
With the solution above, the required changes in Hyper-V and VMware recarding virtual NIC’s and virtual network extensions seem much simpler. Actually, I think the current designs and roadmap of both Hyper-V and Azure already aim to make this possible, since it’s almost the only logical approach. There will also need to be some clever engineering to get the maximum efficiency, for example, it’s imperative that on-premise user traffic doesn’t have to get routed to Azure and come back down the tunnel to reach an on-premise server. Likewise, forcing all traffic the other way would be unacceptable, because then my Azure environment could be rendered offline when my on-premise internet connection is down (Like in some implementations of Office 365 with ADFS). But again, I think they already got the virtual routing and switching logic worked out for Recovery Manager for site-to-site DR scenarios.
Believe me, we’ll post a followup to this article when we see that somebody actually does the first live migration to Azure.
Other notes for Microsoft:
-PLEASE don’t require use to have a StorSimple SAN to do anything important please, that would be a mistake.
-Console access? Please? Someday? We can all work without it, but it deserves a mention.