Keep in mind the considerations listed in this section while implementing your disaster recovery plan.

  • Business requirements need to align with RTCPOs (Recovery time, capacity, and point objectives) for Apps/VMs tiers. Plan and design accordingly to achieve them using the most adequate replication technology; App Native (e.g., SQL Always On availability group), or non-native (for better orchestration) like VMware SRM (Site Recovery Manager), Azure Site Recovery).
  • A decision should be made as to what the target DR site for the AVS private cloud will be as this will influence which DR tooling is suitable to the environment.
  • Migration from third party locations into AVS will have support through Site Recovery Manager through scale. This is found in their documentation in the future.
  • As of time of writing, VMware Site Recovery Manager is supported to provide DR for AVS private cloud to a secondary AVS private cloud in private preview only.
  • As of time of writing, Azure Site Recovery is the primary DR service that is native to Microsoft and supported to provide DR for AVS private cloud to Azure IaaS. See more at: Prepare Azure Site Recovery resources for disaster recovery of Azure VMware Solution VMs

9840-0826-080359-5

Traffic flow for replication and orchestration traffic using Azure Ste Recovery (ASR)

  • Azure Site Recovery Deployment Planner can be used to begin planning DR to Azure Native.
  • When planning the workloads to start after Azure Site Recovery failover, the recovery plan should include the correct startup order for workloads.
  • Partner Solutions like JetStream Software and HCX (testing purposes only) support disaster recovery scenarios for AVS as well.
  • An analysis and decision should be made which (sub-)set of AVS workloads require protection in case of a DR event. Consider protecting only those workloads critical to business operations to control the costs associated with the DR implementation.
  • Necessary sites, services (e.g., AD, DNS), and connectivity to treat as another site in estate for disaster recovery environment.
  • To enable DR between AVS private clouds in distinct Azure regions, ExpressRoute Global Reach needs to be enabled between both (back-end) ExpressRoute circuits to allow AVS-to-AVS connectivity when required for solutions like VMware SRM and VMware HCX for DR.
  • DR overlapping vs non-overlapping IP addressing.
  • Retain same IP address: The same IP address can be used on the recovered VM as the one allocated to the AVS VMs. For this isolated VLANS / segments in the secondary site will need to be created and ensure none of these isolated VLANS / segments are connected to the environment. DR routes will need to be modified to reflect that the subnet has moved to the secondary site, and new IP address locations.
  • Use different IP address: A different IP address can be used for the recovered VMs. If the VM is moved to a secondary site, the recovery plan within the SRM will detail out the custom IP map that will need to be selected for the change of IP address and in case of ASR a defined VNET will be chosen for new IP allocation.
  • Understanding Partial vs. Full Disaster Recovery (DR)
  • When working with Azure Site Recovery, preparing for full disaster recovery should be understood. This means failing over from AVS into an Azure Native environment.
  • Utilising VMware SRM partial and full DR are supported. This means that running AVS in Region 1 and Region 2, the option to fail some or all of the VMs from primary to secondary regions are supported.
  • The requirement for VM recovery and the IP address retention requirements will define if Partial vs Full DR is possible or not.
  • In order to maintain the IP address and achieve a partial disaster recovery in SRM, gateway of the subnet will need to move to the secondary AVS.
  • Active-Standby DR doesn’t require L2 stretching.