Azure Site Recovery – Ask Me Anything – Session Summary

On Tuesday, January 22, 2019, between the hours of 11:30 AM and 1:00 PM Eastern Standard Time (EST), the Azure Site Recovery (ASR) team hosted an “Ask Me Anything” (AMA) session on Twitter.

This is a session where individuals from the Azure Site Recovery Engineering team are available on hand to answer any questions we may have.

Similar to my Azure Backup – Ask Me Anything – Session Summary blog post, here is a summary of some of the responses from the Azure Site Recovery team, which provides insight into what’s coming in the not-too-distant future! I’ve tried to group/organize the points into categories as best I could, and highlighted keywords to help you skim the content.

PS: If you would like to review the session in full, questions asked, etc. here is the direct Twitter link.

Migrations

  • Working on bringing a feature that will allow migrations without using on-premises licenses (i.e. without Software Assurance) and be able to pay for on-demand licensing (i.e. for Windows, SQL Server, etc.)
  • During replication, compression is included to reduce the data transfer volumes and corresponding cost by up to 50% on average, although results may vary from workload to workload.

Replication

  • In reference to a question about having to delete/restart replication just to change replication policies, storage types, vCenter, etc. the Azure Site Recovery team commented: “We are exploring opportunities to change the storage type without requiring to restart replication, but changing vCenter or Replication Policy are not in the plans”.
  • At present, there are no plans to provide the ability to schedule when replications occur. This ask will be added to the future roadmap.
  • The Azure-to-Azure replication scenario supports generating recovery points every 5 minutes. You can read more about this here: Replication policy
  • There are currently no plans to provide an active-active (aka hot-hot, or live High Availability) replication feature in ASR.
  • There are currently no plans to support using ASR to migrate on-premises Active Directory (AD) into Azure AD. This will be added as a requested feature on the backlog.
  • Work is occurring to improve the failover readiness checks and will leverage the article (Prepare a Windows VHD or VHDX to upload to Azure) to enhance the capability.
  • Additional details will be added to the documentation on Add Azure Automation runbooks to recovery plans, to facilitate a better way to view variables injected into automation scripts as part of a recovery plan.
  • The feature/ability to hot-add/remove protected disks will be released in this quarter (Q1 CY2019) for the Azure-to-Azure scenario.
  • ASR performs continuous replication, and so the required IOPS of the target disk should be the same for the source. This is why ASR restricts the replicated disks to have the same configuration on post-failover.
  • The current Application Consistent replication recovery point only supports 60 minutes. There are no immediate plans to lower this limit, but it will be “taken as input” for the ASR team to consider. For sensitive systems like SQL Server, please review the following article: Set up disaster recovery for SQL Server.
  • Since the majority of customer adoption is focused on the on-premises to Azure scenario, most of the innovation is going into that area. However, there are still improvements that are being shipped for the on-premises to on-premises scenario, including support for the latest OSes (i.e. Windows Server 2016), with Windows Server 2019 coming soon.
  • The ASR team is continuously making replication more resilient to intermittent failures through collected telemetry. This is in response to the ask of having a self-healing feature (i.e. when connections to Storage accounts occur).

Failover/Failback

  • Managed Disks are supported fully for both failover and failback in the Azure-to-Azure and VMware-to-Azure scenarios. The support for HyperV-to-Azure is in the backlog
  • The ASR team is investigating the scenario whereby, in an Azure-to-Azure failover, we can include a feature/ability to disconnect a VM from one Recovery Services Vault (RSV), and reconnect to another RSV (especially for Backup), so that data isn’t egressing from one Azure Region to another.
  • ASR’s testing failover interval is currently defaulted to 180 days. There are no current plans to allow the customization of this, but this will be added as a feature request to the backlog.

Other

  • There are plans and work being done to enhance the support that ASR has to include network resources (i.e. Load Balancers, Public IPs, Network Security Groups (NSGs), Application Security Groups (ASGs), etc.) in the coming milestones.
  • Functionality is being worked on, to improve the Extension Update Settings feature, to allow the selection of an existing Azure Automation account.
  • Work is underway to remove the limitation around the Resource Group that a Virtual Machine is in not being in the same geography as the VM itself, which causes ASR to reject the VM as a replication candidate.
  • Although not in the present plans, the ASR team will add the request to have “ASR Reports” (similar to the option currently available with Azure Backup), to the feature ask backlog.
  • The ASR and Azure Backup team are exploring the possibility of integrating the 2 services together (similar to how Veeam has backup and DR in a single tool). This will hopefully allow us to replicate and backup data with a single data transmission versus multiple.
  • Although Azure Migrate is a tool that focuses on the assessment of workloads, while using ASR for the actual migration activity, there are no plans to re-brand ASR to Azure Migrate or remove/break the relationship with Azure Backup via the Recovery Services Vault (RSV) service/platform.
  • Enhancements to the Azure Monitor and Log Analytics solutions are being looked at, and are in the near-term roadmap for updates.
  • Additional work is occurring to make the alerting more granular. The ASR team is interested in capturing some examples to ensure they validate all of the requirements.

Conclusion

A big THANK YOU goes out to the Azure Site Recovery team, and their efforts to answer everyone’s questions. I, for one, truly appreciate how interactive, engaged, and supportive this Microsoft team is; with its Clients, Partners, and their Partner’s Customers.

%d bloggers like this: