Expanding our DR scenarios to new zonal capabilities with Azure Site Recovery

Azure provides high availability, disaster recovery, and backup solutions that can enable your applications to meet business availability requirements and recovery objectives. We continue to build upon our portfolio of resilient services by bringing zonal capabilities for improved business continuity and disaster recovery with Azure Site Recovery. Azure Site Recovery replicates workloads running on physical and virtual machines (VMs) from a primary site to a secondary location. When an outage occurs at your primary site, you failover to a secondary location, and access apps from there. After the primary location is running again, you can fail back to it. Azure Site Recovery helps ensure business continuity by keeping business apps and workloads running during outages.  

With the zonal disaster recovery capability, we are making it possible to replicate and orchestrate the failover of applications in Azure across Azure Availability Zones within a given region. Zone to Zone disaster recovery options with Azure Site Recovery is on its way to being available in all regions with Azure Availability Zones (AZs). Availability Zones, fault-isolated locations within an Azure region, provide redundant power, cooling, and networking, allowing customers to run mission-critical applications with higher availability and fault tolerance to datacenter failures. Azure Availability Zones will be available in every country Microsoft Azure publicly operates in by the end of 2021. 

While Availability Zones are traditionally used by customers for high availability, they can also be leveraged for Disaster Recovery under specific scenarios. The capability adds disaster recovery options for scenarios that may require maintaining data residency and local compliance, reducing the complexity of configuring a DR strategy in a secondary region, and improving the recovery point objective (RPO). 

Adhering to local compliance and data residency

To support customers' unique compliance and data residency needs, Azure offers regions within geographies that provide a distinct boundary for data residency and compliance. Zone to Zone recovery can be leveraged by customers that prefer to keep applications within a particular legal jurisdiction since your applications and data do not cross-national boundaries. Azure provides a wide portfolio of more than 90 compliance offerings to support streamlined compliance and protect data with the most comprehensive compliance coverage.

Reducing the complexity of DR in a secondary region, latency, and RPO

Many Azure regions are designed to provide traditional disaster recovery, with a distinct region that has a large degree of separation from the other location. For some customers enabling this type of DR requires recreation of complicated networking infrastructure and increased cost and operational complexity. Zone to Zone disaster recovery reduces complexity as it leverages redundant networking concepts across Availability Zones making configuration much simpler. 

Since Availability Zones are designed to support synchronous replication while optimizing physical separation to offer protection and isolation from localized failures, this also means the data traverse shorter distances when compared with region to region DR so customers may see lower latency and consequently lower RPO by leveraging zonal DR. 

“When Availability Zones for Azure were being made available, we were in the middle of moving our production workloads to cloud from on-premises datacenters. At that time, we made a bold decision to start distributing all of our IaaS instances across different zones to maximize benefits of redundancy and minimize impact of single datacenter failures on business-facing applications. We looked at recently announced Zone to Zone replication as an enhancement of our DR capability and implemented it in production. The call was quite easy, given that we had prior positive experience with ASR and we’d simply change the datacenter to which we replicate. A couple of drills for different applications were conducted in non-production environments with great success—we were able to restore the protected VMs in about 10 minutes. By failing over to the same region/VNET, we didn’t need to create dedicated test networks which greatly reduces administrative overhead. I really liked the fact that Azure took care of almost the entire failover process end-to-end with provisioning new VM, attaching the disks, and even swapping the IP so that other applications could quickly reconnect to the “new” instance." - Patryk Wolski, Senior Manager – Infrastructure Lead at Accenture.

Architecting for zonal resilience and disaster recovery

Beyond providing the right capabilities in the right regions, we are also committed to providing guidance and proven practices to help our customers and partners take advantage of these capabilities. We recently launched the Azure Well-Architected Framework—a set of guiding tenets that can be used to improve the quality of a workload. Reliability is one of the five pillars of architectural excellence alongside Cost Optimization, Operational Excellence, Performance Efficiency, and Security. If you already have a workload running in Azure and would like to assess your alignment to best practices in one or more of these areas, try the Azure Well-Architected Review.

Source: microsoft.com

Continue reading

Reduce disaster recovery time with Azure Site Recovery

Companies and cloud solutions teams by and large understand the need for a disaster recovery solution. One of the first steps while defining and choosing a disaster recovery plan is to perform a business impact analysis. This process helps in identifying applications that support critical business processes, the impact to the business in case of an outage, and guides in developing the right disaster recovery strategy for your business. Once you perform the analysis and identify critical applications, the next step is to chart down your disaster recovery strategy. This usually translates into:

1. Identifying the right employees or admins who will handle the disaster recovery segment
2. Setting targets for recover time objectives (RTOs) and recovery point objectives (RPOs)
3. Identifying the right product or service based on the needs
4. Identifying all the required software and hardware resources needed
5. Frequently testing the disaster recovery strategy
6. Making continuous improvements to improve the RPO and RTO, identifying and rectifying failure points if any

Configuring disaster recovery of Azure Virtual Machines using Azure Site Recovery

With the best in class RTO and RPO, Azure Site Recovery is one of the leaders in the space of disaster recovery. Being a first-class solution in Azure also gives the service, the edge to enable, test, and perform disaster recovery for customers in just a few clicks. One of the key differentiators while choosing a disaster recovery solution is the availability of integrations with additional resources to achieve parity between source and target. This essentially also reduces the RTO as it reduces the number of manual steps required once the virtual machine is brought up online in the target. The failure points are also minimized with this.

Let’s take a look at a common architecture model.

As a disaster recovery administrator, there are multiple components that you would need to handle to ensure that a target disaster recovery site is activated with similar configurations in the event of a disaster. Other than the virtual machines, it also includes the internal load balancers, the network security groups, and the public IPs that are used to access the virtual machines from outside of Azure. With Azure Site Recovery, while configuring for disaster recovery for your virtual machines, you can also provide the input for corresponding network resources in the target, which will be honored at the time of failover. This takes away the complexities of having to deal with scripts or manual steps and reduces the RTO significantly. The service is also intelligent enough to allow selection of only those target resources that comply with the target virtual machine that will be created, thereby reducing the points of failover.

Azure natively provides you the high availability and reliability for your mission-critical workloads, and you can choose to improve your protection and meet compliance requirements using the disaster recovery provided by Azure Site Recovery.

Continue reading

Moving your Azure Virtual Machines has never been easier!

To meet customer demand, Azure is continuously expanding. We’ve been adding new Azure regions and introducing new capabilities. As a result, customers want to move their existing virtual machines (VMs) to new regions while adopting the latest capabilities. There are other factors that prompt our customers to relocate their VMs. For example, you may want to do that to increase SLAs.

In this blog, we will walk you through the steps you need to follow to move your VM as is or to increase availability, across regions.

Why do customers want to move their Azure IaaS Virtual Machines?

Some of the most common reasons that prompt our customers to move their virtual machines include:

• Geographical proximity: “I deployed my VM in region A and now region B, which is closer to my end users, has become available.”

• Mergers and acquisitions: “My organization was acquired, and the new management team wants to consolidate resources and subscriptions into one region.”

• Data sovereignty: “My organization is based in the UK with a large local customer base. As a result of Brexit, I need to move my Azure resources from various European regions to the UK in order to comply with local rules and regulations.”

• SLA requirements: “I deployed my VMs in Region A, and I would like to get a higher level of confidence regarding the availability of my services by moving my VMs into Availability Zones (AZ). Region A doesn’t have an AZ at the moment. I want to move my VMs to Region B, which is still within my latency limits and has Availability Zones.”

If you or your organization are going through any of these scenarios or you have a different reason to move your virtual machines, we’ve got you covered!

Move Azure VMs to a target region

For any of the scenarios outlined above, if you want to move your Azure Virtual Machines to a different region with the same configuration as the source region or increase your availability SLAs by moving your virtual machines into an Availability Zone, you can use Azure Site Recovery (ASR). We recommend taking the following steps to ensure a successful transition:

1. Verify prerequisites: To move your VMs to a target region, there are a few prerequisites we recommend you gather. This ensures that you’re creating a basic understanding of the Azure Site Recovery replication, the components involved, the support matrix, etc.

2. Prepare the source VMs: This involves ensuring the network connectivity of your VMs, certificates installed on your VMs, identifying the networking layout of your source and dependent components, etc.

3. Prepare the target region: You should have the necessary permissions to create resources in the target region including the resources that are not replicated by Site Recovery. For example, permissions for your subscriptions in the target region, available quota in the target region, Site Recovery’s ability to support replication across the source-target regional pair, pre-creation of load balancers, network security groups (NSGs), key vault, etc.

4. Copy data to the target region: Use Azure Site Recovery replication technology to copy data from the source VM to the target region.

5. Test the configuration: Once the replication is complete, test the configuration by performing a failover test to a non-production network.

6. Perform the move: Once you’re satisfied with the testing and you have verified the configuration, you can initiate the actual move to the target region.

7. Discard the resources in the source region: Clean up the resources in the source region and stop replication of data.

Move your Azure VM ‘as is’

If you intend to retain the same source configuration as the target region, you can do so with Azure Site Recovery. Your virtual machine configuration availability SLAs will be the same before and after the move. A single instance VM after the move will come back online as a single instance VM. VMs in an Availability Set after the move will be placed into an Availability Set, and VMs in an Availability Zone will be placed into an Availability Zone within the target region.

Move your Azure virtual machines to increase availability

As many of you know, we offer Availability Zones (AZs), a high availability offering that protects your applications and data from datacenter failures. AZs are unique physical locations within an Azure region and are equipped with independent power, cooling, and networking. To ensure resiliency, there’s a minimum of three separate zones in all enabled regions. With AZs, Azure offers 99.99 percent VM uptime SLA.

You can use Azure Site Recovery to move your single instance VM or VMs in an Availability Set into an Availability Zone, thereby achieving 99.99 percent uptime SLA. You can choose to place your single instance VM or VMs in an Availability Set into Availability Zones when you choose to enable the replication for your VM using Azure Site Recovery. Ideally each VM in an Availability Set should be spread across Availability Zones. The SLA for availability will be 99.99 percent once you complete the move operation.

Continue reading

General availability of Azure Site Recovery Deployment Planner for VMware and Hyper-V

I am excited to announce the general availability (GA) of the Azure Site Recovery Deployment Planner for VMware and Hyper-V. This tool helps VMware and Hyper-V enterprise customers to understand their on-premises networking requirements, Microsoft Azure compute and storage requirements for successful Azure Site Recovery replication, and test failover or failover of their applications.

Apart from understanding infrastructure requirements, our customers also needed a way to estimate the total disaster recovery (DR) cost to Azure. In this GA release, we have added detailed estimated DR cost to Azure for your environment. You can generate a report with the latest Azure prices based on your subscription, the offer that is associated with your subscription, and the target Azure region for the specified currency. The Deployment Planner report gives you cost for compute, storage, network, and Azure Site Recovery licenses.

Key features of the tool

◉ The Deployment Planner can be run without having to install any Azure Site Recovery components to your on-premises environment.

◉ The tool does not impact the performance of production servers, as no direct connection is made to them. All performance data is collected from the Hyper-V server or VMware vCenter Server/VMware vSphere ESXi Server, which hosts the production virtual machines.

What aspects does the Azure Site Recovery Deployment Planner cover?

As you move from a proof of concept to a production rollout of Azure Site Recovery, we strongly recommend running the Deployment Planner. The tool provides following details:

Compatibility assessment

◉ A VM eligibility assessment to protect to Azure with Site Recovery

Network bandwidth need vs. RPO assessment

◉ The estimated network bandwidth that's required for delta replication
◉ The throughput that Site Recovery can get from on-premises to Azure
◉ RPO that can be achieved for a given bandwidth
◉ Impact on the desired RPO if lower bandwidth is provisioned

Microsoft Azure infrastructure requirements

◉ The storage type (standard or premium storage account) requirement for each virtual machine
◉ The total number of standard and premium storage accounts to be set up for replication
◉ The storage-account placement for all virtual machines
◉ The number of Azure cores to be set up before test failover or failover on the subscription
◉ The Azure VM-recommended size for each on-premises VM

On-premises infrastructure requirements

◉ The required free storage on each of volume of Hyper-V storage for successful initial replication and delta replication
◉ Maximum copy frequency to be set for Hyper-V replication
◉ The required number of Configuration Servers and Process Servers to be deployed on-premises for ◉ VMware to Azure scenario

Initial replication batching guidance

◉ Number of virtual machines that can be replicated to Azure in parallel to complete initial replication

Estimated DR cost to Azure

◉ Estimated total DR cost to Azure: compute, storage, network, and Azure Site Recovery license cost
◉ Detail cost analysis per virtual machine
◉ Specifies replication cost and the DR-Drill cost

Factoring future growth

◉ All the above factors are impacted after considering possible future growth of the on-premises workloads with increased usage

How does the Deployment Planner work?

The Deployment Planner has three main modes of operation:

◉ Profiling
◉ Report generation
◉ Throughput calculation

Profiling

In this mode, you profile all the on-premises servers that you want to protect over a few days, e.g. 30 days. The tool stores various performance counters like R/W IOPS, Write IOPS, and data churn, as well as other virtual machine characteristics like number of cores, number/size of disks, number of NICs, ect., by connecting to the Hyper-V server or the VMware vCenter Server/VMware vSphere ESXi Server where the virtual machines are hosted.

Report generation

In this mode, the tool uses the profiled data to generate a deployment planning report in Microsoft Excel format. The report has six to eight sheets based on the virtualization type:

◉ On-premises summary
◉ Recommendations
◉ Virtual machine to storage placement
◉ Compatible VMs
◉ Incompatible VMs
◉ On-premises storage requirement (only for Hyper-V)
◉ Initial replication batching (only for Hyper-V)
◉ Cost estimation

By default, the tool takes the 95th percentile of all profiled performance metrics and includes a growth factor of 30%. Both these parameters, percentile calculation and growth factor, are configurable.

Throughput calculation

In this mode, the tool finds the network throughput that can be achieved from your on-premises environment to Microsoft Azure for replication. This will help you determine what additional bandwidth you need to provision for replication.

With Azure Site Recovery’s promise of full application recovery on Microsoft Azure, through deployment planning is critical for disaster recovery. With the Deployment Planner, we will ensure that both brand new deployments and existing deployments get the best replication experience and application performance when running on Microsoft Azure.

Continue reading