Implementing Azure Site Recovery – Part 4 – Managing and Automating

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 last post of a series of 4 (see the first post here, second here and third 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:

After an on-premises computer appears in the portal with the Protected status, you can perform test failovers, planned failovers, or unplanned failovers. When you do so, the sequence of events differs, depending on the type of failover you choose:

  • In case of a test failover, you specify the Azure virtual network you want to fail over to. To prevent any possibility of impacting the production environment, this should be an isolated network. Site Recovery provisions a new Azure virtual machine in the virtual network by using replicas of the virtual disks that are residing in the Azure storage account. The protected virtual machine stays online. After you complete your testing, Site Recovery automatically delete the Azure virtual machine.
  • In case of a planned failover, Site Recovery shuts down the protected virtual machine to prevent the possibility of data loss. Next, it provisions the corresponding Azure virtual machine by using replicas of virtual disks residing in the Azure storage account. It also places the new virtual machine in a commit pending state. You must perform the commit action to complete the failover. The commit removes any existing recovery points in Azure storage.
  • In case of an unplanned failover, Site Recovery provisions the replica Azure virtual machine by using replicas of virtual disks residing in the Azure storage account. You can instruct Site Recovery to attempt to synchronize protected virtual machines and shut them down, but, in this scenario, such an action might not be possible. Alternatively, you can specify to use the latest recovery point available in Azure storage. Site Recovery will place the newly-provisioned Azure virtual machine in a commit pending state. You must perform the commit action to complete the failover. The commit removes any existing recovery points in Azure storage.

Note: With all three types of failover, if you enabled data encryption when you are running the Azure Site Recovery Provider setup, you must provide the encryption certificate as part of a failover.

When performing planned or unplanned failover, once your primary site is back online, you should protect the Azure virtual machines and establish reverse replication. This will allow you to fail back to the on-premises location without data loss.

Recovery plans

While it is possible to perform failover and failback of individual protected computers, it is more beneficial from the standpoint of business continuity to orchestrate disaster recovery of multiple computers. Site Recovery supports this scenario by allowing you to create recovery plans.

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.

Site Recovery uses a context variable to pass several parameters to the Azure Automation runbook. You can use these parameters to customize runbook activities. These parameters include:

  • RecoveryPlanName: Name of the Site Recovery plan.
  • FailoverType: Type of failover (test, planned, or unplanned).
  • FailoverDirection: Direction of the failover (from the primary site to Azure or from Azure to the primary site).
  • GroupID: Identifier of a group within the recovery plan.
  • VmMap. Collection of virtual machines within the group.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga

Implementing Azure Site Recovery – Part 3 – For VMware Virtual Machines and physical server

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 third post of a series of 4 (see the first post here and second 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 VMware virtual machines and physical servers. In this scenario, you are using VMware vCenter to manage your vSphere 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. Setting up an account on the vSphere host or vCenter server to facilitate automatic discovery of VMware virtual machines.
  4. Preparing the configuration server to allow outbound access to the Azure URLs listed in the previous lesson and installing vSphere PowerCLI 6.0.
  5. Creating a Recovery Services vault in the same subscription and the same region as the storage account and the virtual network.
  6. 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 two questions:
    1. Where do you want to replicate your machines? Select the To Azure option.
    2. Are your machines virtualized? Select the Yes, with VMware vSphere Hypervisor option.
  7. Setting up the source environment. This consists of the following steps:
    1. Adding the configuration server entry that is representing your on-premises configuration server.
    2. Downloading the Site Recovery Unified Setup installation file and the Recovery Services vault registration key to the configuration server. Run the installation by using the newly downloaded setup file and, when you receive a prompt, provide the vault registration key. As part of the installation, you will set up an instance of MySQL Server and specify its admin credentials. You will also be able to designate the port TCP 9443 on which the server will send and receive the replication data. You can modify it if needed.
    3. Running CSPSConfigtool.exe on the configuration server and adding the account you set up in step 3 that will perform automatic discovery of VMware virtual machines.
    4. Adding the vCenter server and vSphere host entries that are representing your on-premises virtualization environment in the Azure portal.
  8. 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 that 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.
  9. Setting up replication settings. This step involves configuring a replication policy and associating it with the configuration server you added in step 7.1. The policy includes settings such as copy frequency, recovery point retention, app-consistent snapshot frequency, and initial replication start time.
  10. 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.
  11. Selecting the VMware virtual machines and enabling their replication. This consists of the following steps:
    1. Installing the Mobility service on the virtual machines you intend to protect. You can perform the installation by initiating it from the process server, either by using your existing software deployment solution such as System Center Configuration Manager or doing it manually.
    2. Configuring Step 2: Replicate Applications of the GETTING STARTED Wizard in the Azure portal. You must specify the vCenter server or vSphere host you selected in step 7.4. In addition, you must select the process server if you installed it on a computer other than the configuration server. You also must select the Azure virtual network and the storage account you want to use to host replicas of protected virtual machines and their disks. In addition, this step involves selecting the VMware virtual machines that you want to protect. For each virtual machine, you can designate the account that the process server will use to install the Mobility service. You can also select disks that you want to exclude from replication and specify the size of the replica Azure virtual machine. Finally, you also must 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 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 4 – For VMware Virtual Machines and physical server

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 VMware virtual machines and physical servers. The general considerations you can find here.

When configuring Azure-based protection of VMware virtual machines and physical servers, the following additional considerations apply:

  • Use VMware vSphere v5.1, vSphere v 5.5 or vSphere v6.0.
  • Microsoft recommends the use of VMware vCenter 5.5 or VMware vCenter 6.0 to manage vSphere hosts.
  • If you decide to use an Azure premium storage account to store replicated data, you must designate another storage account to store replication logs.
  • To use push installation of the Mobility service on the Windows virtual machine that you intend to protect, ensure that the Windows Firewall allows inbound File and Printer Sharing and Windows Management Instrumentation traffic. For Linux virtual machines, you should enable the Secure File Transfer Protocol subsystem and password authentication in the sshd_config
  • You have the option of excluding individual disks from replication.
  • The computer hosting the configuration server component must have outbound connectivity to Azure via TCP port 443. The computer hosting the process server component should have outbound connectivity to Azure via TCP port 9443. You can use a different port for this purpose if needed. Because both the process server and the configuration server components reside by default on the configuration server, you should make sure that this server can access the following URLs over ports 443 and 9443:
    • *.accesscontrol.windows.net
    • *.backup.windowsazure.com
    • *.hypervrecoverymanager.windowsazure.com
    • *.store.core.windows.net
    • *.blob.core.windows.net
    • https://www.msftncsi.com/ncsi.txt
  • The configuration server should also be able to reach https://dev.mysql.com/get/archives/mysql-5.5/mysql-5.5.37-win32.msi over TCP port 80.
  • Depending on the outcome of your capacity planning, you have the option of adjusting the bandwidth available to the replication traffic. In this scenario, the process server handles replication. Therefore, you can configure its Microsoft Azure Backup throttling settings or adjust the number of upload and download threads per virtual machine by modifying its registry. For details regarding this option, refer to the Azure Site Recovery Planning Considerations – Part 2 – For Hyper-V Virtual Machines.

Cheers,

Marcos Nogueira
azurecentric.com
Twitter: @mdnoga