Implementing Azure Site Recovery – Part 2 – For Hyper-V Virtual Machines in SCVMM Clouds

After I post the series of Azure Site Recovery (ASR) Planning considerations, I received an enormous quantity of feedback how It should be implemented, following those considerations. So, this is the second post of a series of 4 (see the first post here), about how to implement Azure site recovery based protection on the scenarios describe on the previous series posts.

If you want to visit the series where I talked about the ASR Planning Considerations, you can do it by select the right scenario:

In this post, you will step through a sample implementation of Site Recovery with the on-premises primary site and the secondary site that is residing in Azure. Your intention is to protect on-premises Hyper-V virtual machines. In this scenario, you are using System Center Virtual Machine Manager to manage your Hyper-V hosts. Your implementation will consist of the following tasks:

  1. Creating one or more Azure virtual networks in your Azure subscription in the Azure region that meets your disaster recovery objectives.
  2. Creating an Azure storage account in the same subscription and the same region as the Azure virtual network.
  3. Creating a Recovery Services vault in the same subscription and the same region as the storage account and the virtual network.
  4. Preparing for the mapping of on-premises virtual machine networks to the Azure virtual networks. You need to make sure that all virtual machines you intend to protect are connected to the virtual machine networks you will be mapping to the Azure virtual networks.
  5. Specifying the protection goal of your implementation. When using the Azure portal, this is the first task in Step 1: Prepare Infrastructure of the GETTING STARTED Wizard and involves answering the following four questions:
    1. Where do you want to replicate your machines? Select the To Azure option.
    2. Are your machines virtualized? Select the Yes, with Hyper-V option.
    3. Are you using System Center VMM to manage your Hyper-V hosts? Select the Yes option.
    4. Are you managing the recovery site with another System Center VMM? Select the No option.
  6. Setting up the source environment. This consists of the following steps:
    1. Adding a System Center VMM server entry representing your on-premises VMM environment and selecting the VMM cloud that is hosting the virtual machines that you intend to protect.
    2. Downloading the Azure Site Recovery Provider setup file and Recovery Services vault registration key to the VMM server. Run the installation using the newly downloaded setup file and, when you receive a prompt, provide the vault registration key. You will also receive a prompt to accept or modify an SSL certificate for encryption of disks uploaded to the Recovery Services vault. Finally, you will have the option to enable synchronization of cloud metadata for all VMM clouds. Optionally, you can select individual VMM clouds that you want to be visible in the Azure portal.
    3. Downloading the setup file for the Azure Recovery Services agent and installing it on each Hyper-V host in the VMM cloud that is associated with the virtual machine network you will be mapping to the Azure virtual network.
  7. Setting up the target environment. As part of this step, you must specify the post-failover deployment model. In this walkthrough, you will choose Resource Manager, but Site Recovery also supports the classic deployment model. At this point, you will also have a chance to verify that you can use the virtual network and the storage account you created earlier to host replicas of protected virtual machines and their disks. You have the option to create the virtual network and the storage account if this is not the case. Finally, you must also configure network mapping between virtual machine networks and the Azure virtual network.
  8. Setting up replication settings. This step involves configuring a replication policy and associating it with the VMM cloud you selected in step 6.1. The policy includes settings such as copy frequency, recovery point retention, app-consistent snapshot frequency, and initial replication start time.
  9. Confirming that you have run the Capacity Planner. The wizard will include a drop-down list from which you need to select Yes, I have done it in order to successfully complete the Preparing infrastructure step.
  10. Selecting the VMM cloud and enabling its replication. This is part of Step 2: Replicate Applications in the GETTING STARTED Wizard. You will need to specify the VMM cloud you selected in step 6.1. You also will need to select the Azure virtual network and the storage account you want to use to host replicas of protected virtual machines and their disks. You also have the option to choose the target subnet. In addition, this step involves assigning the name to the target virtual machine and choosing its operating system. Finally, you also have to choose a replication policy that you want to take effect in this case.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Implementing Azure Site Recovery – Part 1 – For Hyper-V Virtual Machines

After the series of Azure Site Recovery (ASR) Planning considerations, I received an enormous quantity of feedback how It should be implemented, following those considerations. So, this is the first post of a series of 4 about how to implement Azure site recovery based protection on the scenarios describe on the previous series posts.

If you want to visit the series where I talked about the ASR Planning Considerations, you can do it by select the right scenario:

Implementing Site Recovery is a relatively involved process. However, the Azure portal simplifies this process by guiding you through the implementation steps, asking for your design decisions, and providing instructions on how to execute the corresponding actions. The implementation steps reflect the recovery scenario that you have chosen to be the most suitable for your organization’s business continuity needs.

A recovery plan consists of one or more recovery groups, which serve as logical containers of protected virtual machines. You arrange groups in a sequence that dictates the order in which Site Recovery failover and failback bring the protected virtual machines online. Within this sequence, you can add pre and post actions. Each action can represent a manual recovery step or an Azure Automation runbook. By using Azure Automation, you have the option to fully automate your disaster recovery. You can also use it to provision and configure additional Azure components, such as load balancers.

There is no direct support for specifying Web jobs in the recovery plans. There is no support for VMM library scripts when failing over to Azure.

In this post, you will step through a sample implementation of Site Recovery with the on-premises primary site and the secondary site that is residing in Azure. Your intention is to protect on-premises Hyper-V virtual machines. In this scenario, you are not using System Center Virtual Machine Manager (VMM) to manage your Hyper-V hosts. Your implementation will consist of the following tasks:

  1. Creating an Azure virtual network in your Azure subscription in the Azure region that meets your disaster recovery objectives.
  2. Creating an Azure storage account in the same subscription and the same region as the Azure virtual network.
  3. Creating a Recovery Services vault in the same subscription and the same region as the storage account and the virtual network.
  4. Specifying the protection goal of your implementation. When using the Azure portal, this is the first task in Step 1: Prepare Infrastructure of the GETTING STARTED Wizard. This task involves answering the following three questions:
    1. Where do you want to replicate your machines? Select the To Azure option.
    2. Are your machines virtualized? Select the Yes, with Hyper-V option.
    3. Are you using System Center VMM to manage your Hyper-V hosts? Select the No option.
  5. Setting up the source environment. In this case, you must create a Hyper-V site, which serves as a logical container for Hyper-V hosts or clusters of Hyper-V hosts. Once you create a site, you must add one or more Hyper-V hosts to it. Next, download the Azure Site Recovery Provider setup file and Recovery Services vault registration key to the Hyper-V server. Run the installation by using the newly downloaded setup file and, when you receive a prompt, provide the vault registration key.

    Note: The Azure Site Recovery Provider setup file installs both the provider and the Recovery Services agent.

  6. Setting up the target environment. As part of this step, you must specify the post-failover deployment model. In this walkthrough, you will choose Resource Manager, but Site Recovery also supports the classic deployment model. At this point, you will also have a chance to verify that you can use the virtual network and the storage account you created earlier to host replicas of protected virtual machines and their disks. You have the option to create the virtual network and the storage account if this is not the case.
  7. Setting up replication settings. This step involves configuring a replication policy and associating it with the Hyper-V site you created earlier. The policy includes settings such as copy frequency, recovery point retention, app-consistent snapshot frequency, and initial replication start time.
  8. Confirming that you have run the Capacity Planner. The wizard will include a drop-down list from which you need to select the Yes, I have done it option to successfully complete the Preparing infrastructure step.
  9. Selecting the protected virtual machines and enabling their replication. This is part of Step 2: Replicate Applications of the GETTING STARTED Wizard. You will need to specify the source Hyper-V site that you defined earlier. You also will need to select the Azure virtual network and the storage account you want to use to host the replica of the protected virtual machine and its disks. You also have the option to choose the target subnet. In addition, this step involves assigning the name to the target virtual machine and choosing its operating system. Finally, you also must choose a replication policy that you want to take effect in this case.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Azure Site Recovery Planning Considerations – Part 3 – For Hyper-V Virtual Machines in SCVMM clouds

On these post series, I want to cover some of the planning considerations that I usually use, when I’m designing/planning with my costumers, an ASR deployment/infrastructure. I broke down in several posts so I can cover and make easy to find the considerations that you are looking for. In this post, I will cover additional considerations when you need to configure Azure-based protection of Hyper-V virtual machines based on System Center Virtual Machine Manager (SCVMM) Clouds. The general considerations you can find here.

When you are configuring Azure-based protection of Hyper-V virtual machines located in VMM clouds, the following additional considerations apply:

  • You must create virtual machine networks in your VMM environment. You associate virtual machine networks with VMM logical networks, which, in turn, link to private clouds containing protected virtual machines. Once you create virtual machine networks, you must map them to the corresponding Azure virtual networks. This ensures that, following a failover, the network configuration in Azure matches the one that exists in your on-premises environment. By mapping networks, you ensure that replicas of protected virtual machines, which reside on the same on-premises network, also reside on the same Azure virtual network. You can map multiple virtual machine networks to a single Azure virtual network.
  • You have the option to select individual VMM clouds that will appear in the Azure portal. You can choose this option if you want to ensure that the Azure Site Recovery Provider running on the VMM server does not upload all of your cloud metadata to the Recovery Services vault.
  • If you want to ensure that Site Recovery attaches a replica of a protected virtual machine to a specific subnet, then name the Azure virtual network subnet the same as the virtual machine network subnet.
  • The Azure Site Recovery Provider running on the VMM server must have outbound connectivity to Azure via TCP port 443. The Azure Site Recovery Services agent running on each Hyper-V server that is hosting the virtual machines that you want to protect also must have outbound connectivity to Azure via TCP port 443. You must allow access to the following URLs from the VMM server and Hyper-V servers:
    • *.accesscontrol.windows.net
    • *.backup.windowsazure.com
    • *.hypervrecoverymanager.windowsazure.com
    • *.store.core.windows.net
    • *.blob.core.windows.net
    • https://www.msftncsi.com/ncsi.txt
  • Depending on the outcome of your capacity planning, you have the option of adjusting the bandwidth available to the Hyper-V replication traffic on individual Hyper-V hosts. For details regarding this option, refer to the Azure Site Recovery Planning Considerations – Part 1 post.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Azure Site Recovery Planning Considerations – Part 2 – For Hyper-V Virtual Machines

On these post series, I want to cover some of the planning considerations that I usually use, when I’m designing/planning with my costumers, an ASR deployment/infrastructure. I broke down in several posts so I can cover and make easy to find the considerations that you are looking for. In this post, I will cover additional considerations when you need to configure Azure-based protection of Hyper-V virtual machines. The general considerations you can find here.

When configuring Azure-based protection of Hyper-V virtual machines, the following additional considerations apply:

  • Each Hyper-V server that is hosting virtual machines that you want to protect must have outbound connectivity to Azure via TCP port 443. Both the provider and the agent use this port. You must allow access to the following URLs from the Hyper-V servers:
    • *.accesscontrol.windows.net
    • *.backup.windowsazure.com
    • *.hypervrecoverymanager.windowsazure.com
    • *.store.core.windows.net
    • *.blob.core.windows.net
    • https://www.msftncsi.com/ncsi.txt
  • Depending on the outcome of your capacity planning, you might want to adjust the bandwidth that is available to the Hyper-V replication traffic. There are two ways to accomplish this:
    • Throttle bandwidth to a specific value according to the schedule you define. You can configure this setting from the Microsoft Azure Backup Microsoft Management Console (MMC) snap-in. In the console, you can display the Microsoft Azure Backup Properties dialog box and, in the dialog box, switch to the Throttling From there, you can set the maximum bandwidth that is available for backup operations during work and nonwork hours. You have the option of defining what constitutes the start and end of work hours.
    • Increase or decrease the number of threads that are dedicated to replicating virtual disks on a per-virtual machine basis during failover and failback. This requires direct modification of entries in the HKLM\SOFTWARE\Microsoft\Windows Azure Backup\Replication registry key. The UploadThreadsPerVM entry controls the number of threads dedicated to replicating the disk data. The DownloadThreadsPerVM entry controls the number of threads when failing back from Azure.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

New version of Azure Backup Server introduces Modern Backup Storage technology

WOW! What a day for me! Microsoft Azure just announces new and improved features on the new version Azure Backup Server. Let’s start!

They announce with Azure Backup Server v2 (MABSv2) you can protect your VMWARE and Windows Server 2016 environment. That is really important feature (in my opinion). Now I don’t need to rely on third party backup software vendors to backup the workloads into Azure, special if the workload is running on ESXi.

Microsoft introduces now thought MABSv2 the Modern Backup Storage technology, based on the features available o Windows Server 2016.

With Windows Server 2016 broth enormous enhancements like ReFS cloning. MABSv2, now leverage these modern technologies, like ReFS cloning and Dynamic VHDX to reduce the overall TCO of backup. MABSv2 also introduces workload infinity technology, that helps to optimize storage utilization.

One of the features that Windows Server 2016 intruded was resilience change checking that improved virtual machine backup resiliency. MABSv2 are now resilient with Resilient Check Technology (RCT) and organizations don’t need to go with painful consistency checks scenarios like virtual machine storage migrations.

MABSv2 can detect and protect VMs that are store on Storage Spaces Direct (S2D), ReFS based cluster seemly without any manual steps. Windows Server 2016 VMs are more secure with shield VM technology and MABSv2 can protect and recovery them securely.

Windows Server 2012 R2 cluster can be upgraded to Windows Server 2016 using rolling cluster upgrade technology without bring down the production environment. MABSv2 will continue to backup the VMs and so there no miss of the SLA while the cluster upgrade is in progress.

You can also auto protect SQL workloads and VMware VMs to cloud using MABSv2. MABSv2, now also comes with the support to protect SQL 2016, SharePoint 2016 and Exchange 2016 workloads as well.

MABSv2 can protect VMware VMs, although the support is in test for MABSv2 running on Windows Server 2016.

MABSv1 deployments can be upgraded to MABSv2 with a few simple steps. MABSv2 will continue to backup data sources without rebooting production servers. So, you don’t need to worry about rebooting production servers or backup interruption with the upgrade to MABSv2.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga