Azure Migrate - how to use for failover

Zachary Hamilton 201 Reputation points
2020-05-20T13:34:01.547+00:00

Hello,

We have a number of on-premise Hyper-V VMs. We are looking to backup a few of them to our Azure cloud in case our building would face a true disaster and be destroyed.

Would Azure VM "migration" be the ticket? We're not really looking to "migrate" as I understand the term, but rather, make a copy of the machine in Azure that we could spin up and fail over to if necessary.

I'm having difficulty sifting through the voluminous Microsoft documentation to get a clear answer on this. All I want is to know what time it is, and Microsoft wants to teach me how to build a clock.

Thanks for your help.

Zachary Hamilton

Azure Virtual Machines
Azure Virtual Machines
An Azure service that is used to provision Windows and Linux virtual machines.
7,160 questions
0 comments
Accepted answer
  1. Stephane Budo 426 Reputation points
    2020-05-20T21:44:39.087+00:00

    Hi Zachary,

    I know what you mean, the number of services in Azure (and the documentation) is huge these days, so hard to sift through the weeds to find what you need.

    From what you describe above, you are after "Azure Site Recovery".
    This service will continuously replicate your existing Virtual Machines to an encrypted Recovery Services Vault. From there, you can then fail over (for testing or during a real disaster) to Azure.

    Process at a high level:

    General overview of the service and all related documentation can be found here:
    https://learn.microsoft.com/en-us/azure/site-recovery/site-recovery-overview

    Hope this helps, but let us know if you have any questions/problems,
    Stephane

    3 people found this answer helpful.
    0 comments

7 additional answers

Sort by: Newest
Most helpful Newest Oldest
  1. Zachary Hamilton 1 Reputation point
    2020-06-03T19:59:49.05+00:00

    I didn't have a public IP assigned to the NIC. I got connected. Thanks for all your help.

    Zachary Hamilton

    0 comments
  2. Stephane Budo 426 Reputation points
    2020-06-03T00:40:55.867+00:00

    Hey Zach,

    The RDP connection should work, but there are a few things to watch out for:

    • Since the IP addresses of the servers have changed, is Windows Firewall blocking the connection?
    • How do you connect to the VNet? Are you using a VPN gateway or a public IP assigned to each VMs? If you are using a VPN Gateway, make sure that the server knows the route back to your workstation. If you are using Public IP, make sure the Windows Firewall allows the connection and that there is the appropriate NSG in place on the Subnet and NIC to allow the RDP connection.
    • Are you allowing pings in Windows Firewall? If so, can you ping the VM? (i.e. is the network connectivity working and it's only RDP that doesn't work?)

    In most cases that I see, Windows Firewall is the culprit in those situation...

    Cheers,

    Stephane

    0 comments
  3. Zachary Hamilton 201 Reputation points
    2020-06-02T19:53:23.973+00:00

    Another question if I may: I set up the virtual network with a different subnet. I did a test failover of the VM and it seems to be working according to the Azure dashboard. However, I can't connect to it through either RDP or Bastion (didn't try SSH). Is there a secret to this that will get me going quickly? I found some RDP troubleshooting docs, but again, it's quite a lot to go through for what I'm guessing would be a simple fix if I knew where to look.

    Thanks,

    Zach

    0 comments
  4. Stephane Budo 426 Reputation points
    2020-05-22T00:37:38.627+00:00

    That's exactly right.

    The Recovery Services Agent running on your Hyper-V hosts will replicate (block level) the disk changes up to the Recovery Service Vault (down to every 30 seconds for critical systems if needed), so if you have a disaster (either your entire on-premises datacentre goes up in flames, or even if one of your servers starts to blue screen), you can failover the servers up in Azure and continue to run the server(s) up there while you fix your datacentre.
    When you initiate a fail over, the platform will copy the data out of the Vault, create the VM disks from it, then create the VMs associated and spin them up.

    The few things to be aware of:

    • Make sure you have the network design done and setup well before a disaster. This involve creating the virtual networks in Azure (to which your VMs will connect to), as well as the connectivity to the network (and therefor your servers) should your datacentre becomes inaccessible.
    • Beware that the bandwidth required from your datacentre to Azure has to be sufficient to sustain the rate of change and upload of the data to the vault. This is also valid for the disk access once the VM is in Azure itself.
      Microsoft has developed an assessment tool that will calculate it all based on your existing workloads: found here
    • I would recommend to have your network in Azure connected back to your on-premises network and to deploy a domain controller up in Azure. That way, you have an existing domain controller always available should your datacentre go down (Domain controllers are a bit hard to failover due to the IP addressing change as well as the domain topology, so it's easier to have one already up and running as opposed to failover your existing ones).

    I did a quick Azure Site Recovery demo video, and although it's a bit old now (about 3 years ago) and the tooling/portal might have slightly changed, the principles in there are still valid, so worth watching:
    https://www.youtube.com/watch?v=ZNImiAslDyQ

    Feel free to reach out if you have more questions :-)
    (and don't forget to mark the answers as accepted if you feel I've answered the questions correctly :-))

    Thank you,

    Stephane

    0 comments