The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document is an application deployment guide for Azure Site Recovery (ASR) on the top of Cisco Cloud Architecture for Microsoft Cloud Platform (CCA-MCP). While this guide provides an overview on ASR deployment, it is highly recommended to utilize Microsoft professional services and Cisco Advanced Services for DRaaS technology deployment due to the technology complexity and variations on enterprise customer’s needs and requirements.
The guide includes prerequisites for the covered scenarios and explains how to set up a Site Recovery vault, get the Azure Site Recovery Provider installed on source and target VMM servers, register the servers in the vault, configure protection settings for VMM clouds that will be applied to all protected virtual machines, and then enable protection for those virtual machines.
The CCA-MCP infrastructure is the foundation on which cloud services are offered. The base infrastructure consists of a set of data center devices that are setup, connected, and configured prior to adding tenant services.
Service Providers build data centers using physical components to implement compute, storage and data center networking to create a pool of resources used to offer services to tenants. Tenant services are offered using these physical resources, and provisioned and managed using automation software to enable consumption of these services. When tenants are on boarded, cloud containers are created from the pool of resources, to provide a slice of resources that include compute, storage and networking. This container is securely isolated from other tenants that are consuming similar services, thereby providing isolation for multi-tenant services.
Figure 1-1 Cisco Cloud Architecture for the Microsoft Cloud Platform
Enabled cloud services in the CCA-MCP Solution are the Infrastructure as a Service and Platform/Software as a service. Each of these services are described in a service configuration guide, and require the data center physical infrastructure to be built and the resource pools created and ready to onboard these services.
The architecture of this solution uses a layered approach enabling a modular design. This enables scalable solution deployment with expansion capability in modular units.
2. Compute for Tenant workloads
Most organizations consider Disaster Recovery (DR) a complicated process that is troublesome to manage and test. DR planning puts CIOs in a difficult position: most realize that ensuring application continuity in the case of a disaster is valuable to the business, but hesitate at the cost of the additional hardware and software needed, not to mention the time required to develop and test DR plans. Hence, more and more organizations started to subscribe to DRaaS service to reduce costs, complexity, and increase critical business applications availability.
Given the increased complexity of hybrid cloud solutions, service providers often find themselves playing the role of a systems integrator, wrapping together solutions from multiple vendors and providers to stand up a single, unified solution. That complexity also makes it more difficult to provision and monetize value-added services such as Disaster Recovery.
For the first time, Microsoft and Cisco have come together to provide cloud service providers with a joint-engineered, cloud-enabled platform solution that simplifies service delivery. Cisco Cloud Architecture for Microsoft Cloud Platform brings together Cisco’s world-class hardware and Microsoft’s enterprise-ready cloud software into a single, fully-integrated solution, making it easier for cloud providers to deliver cloud services such as DRaaS, while lowering deployment risk, simplifying operations, and improving TCO.
Cisco and Microsoft have invested the time, money and resources to help cloud providers offer their customers:
The below section provides benefits to the Service Providers and their customers
Cisco partnered with Microsoft to build a service provider cloud-based DR solution focused on mission critical workloads, Our primary priority: Make DR available to everyone, available everywhere, and easy to use. Arguably, that’s three primary priorities – and we are pleased to include Microsoft Azure Site Recovery (ASR) with our Cisco Cloud Architecture for Microsoft Cloud Platform. ASR is a data protection and Disaster Recovery solution which can help enterprises protect important services by coordinating the automated replication and recovery of protected instances at a secondary location.
Azure Site Recovery on-premise to on-premise scenario provides a well-documented DRaaS solution for cloud providers. Disaster recovery is simplified and incorporated into the overall design, keeping both tenant and management systems highly available. ASR sends only management metadata to Azure to orchestrate DRaaS setup and recovery. Tenant and management data is transferred directly from the main to the DR site, and never goes to Azure. ASR plans orchestrate the recovery of resources at a designated site (Figure 1-2). ASR further simplifies the disaster recovery process by enabling testing of failovers and restorations of systems.
Figure 1-2 Microsoft Azure Site Recovery
A recovery plan can be used for a planned failover, unplanned failover as well as for DR drills using test failover. A recovery plan continues to address the following needs for the user:
Microsoft’s Azure Site Recovery (ASR) on-premise to on-premise scenario can be applied to both Incloud (IaaS onboarded workloads) and Remote (private cloud workloads) DRaaS use-cases.
The on-premise to on-premise deployment scenario will be covered in this solution guide - Virtual machines running in an environment using Hyper-V can be replicated between two data centers. Azure Site Recovery monitors the health of applications running in the primary site, stores the recovery plan, and executes it when needed. In the event of a site outage at the primary data center, VMs are recovered in an orchestrated fashion to help restore service quickly. This process can also be used for testing recovery, or temporarily transferring services.
The following are the two main use cases for DRaaS service delivery:
Figure 1-3 In-Cloud DRaaS for IaaS Workloads with ASR and Azure Pack
After you've set up protection for virtual machines and physical servers they begin replicating to the secondary location. After replication is in place you can run failovers as the need arises. Site Recovery supports a number of types of failover.
Remote DRaaS for Enterprise Private Cloud Workloads with ASR and Azure Pack
Replicate enterprise private cloud virtual machines to SP cloud site with Hyper-V replication. Users configure and enable protection settings in Azure Site Recovery vaults and VMM. Virtual machine data is replicated from a source Hyper-V host server to a target host server orchestrated through ASR.
This Remote DRaaS ASR scenario has not gone through Cisco validation yet, we can offer the following design considerations:
– Enterprises might not have WAP deployment.
– Even if the enterprise has the user identity on Enterprise WAP will be their Active Directory users which is not available on Service Provider side. To enable access of VMs on the Service Provider WAP, the Service Provider needs to run a script to assign user role on the protected VMs in his DCs.
Figure 1-4 Remote DRaaS for Customer Workloads
Both Remote DRaaS and InCloud DRaaS scenarios utilize on-premise to on-premise ASR deployment based on Hyper-V replica implementation.
Note Network Container type depends on the Data Center architecture we choose for this validation and availability. There is no dependency on the Network container type for validating the ASR functionality.
An Azure account with Azure Site Recovery enabled.
Figure 1-5shows the different communication channels and ports used by Azure Site Recovery for orchestration and replication.
Figure 1-5 On Premises to On Premises
Prerequisites for On-Premises to On-Premises Protection
– At least one VMM host group with at least one Hyper-V host server in each group.
– One or more virtual machines on the host server.
Refer to detailed instructions on planning the environment.
Following are the high level steps required to enable protection of VMs, please following the inbuilt hyperlinks in each step for detailed procedure from Microsoft site:
1. Create a Vault —create a vault in the Azure Site Recovery portal.
2. I nstall and configure the Azure Site Recovery Provider —Install and configure the Azure Site Recovery Provider on the VMM server in each site. The Provider connects the server to the Azure Site Recovery portal.
3. Configure Cloud Settings —Configure protection settings for VMM clouds. The cloud that contains the virtual machines you want to protect is known as the primary cloud. The cloud that contains the Hyper-V host server to which the virtual machines will replicate is known as the secondary cloud. Each cloud can act as a primary cloud protecting a secondary cloud, or as a secondary cloud that’s protected. A cloud can’t be both primary and secondary.
4. Set Up the Runbooks —You configure and schedule a single master runbook to set up Azure Site Recovery protection. This master runbook in turn invokes a number of other runbooks.
5. Configure Plans —On the primary site you enable Azure Site Recovery protection on a public plan or add-on, and create a private plan with the same settings on the secondary site.
6. Tenant Steps —In order to set up virtual machine protection tenants will use the self-service Azure Pack portal to:
– Subscribe to the plan or add-on —Tenants subscribe to a plan or add-on the primary datacenter that has virtual machine protection enabled.
– Create a virtual machine —Tenants create a virtual machine or virtual machine role on the primary site, under the plan subscription.
– Create VM networks —Tenants can create virtual networks on the primary site to specify how replica virtual machines will be connected to networks after failover. When a tenant creates a virtual network a VM network with the same settings is configured on the primary VMM server.
7. Set up Network Mapping —If the tenant has created virtual networks you can set up network mapping between VM networks on the primary and secondary VMM servers. Network mapping:
– Ensures that virtual machines are connected to appropriate VM networks after failover. Replica virtual machines will connect to a secondary network that’s mapped to the primary network.
– Optimally places replica virtual machines on Hyper-V host servers. Replica virtual machines will be placed on hosts that can access mapped VM networks.
If you don’t configure network mapping replicated virtual machines won’t be connected to any VM networks after failover. Read about Network mapping.
8. V erify user Accounts —Before you can replicate virtual machines you’ll need to verify that user credentials associated with the plan or add-on subscription are valid on the primary and secondary sites.
9. D etecting and Replicating Virtual Machines —The runbooks automatically detect plans or add-on subscriptions that have protection enabled. The runbook automatically enables protection for virtual machines in the subscriptions, and initiates the initial replication.
10. Run a Failover —After the initial replication finishes you can run a test, planned, or unplanned failover whenever you need to.
– Test failover—Supports testing without impacting production
– Planned Failover—Supports planned maintenance as well as DR drill with actual failover
– Unplanned Failover—Supports unplanned failover needs like power failures,
The following steps are needed to support In-Cloud DRaaS use case for IaaS workloads. The same procedure described above has to be followed with some additional steps listed below:
Plan and DR Add-On Creation in WAP
For detailed information and procedure on how to enable DR for IaaS Workloads with ASR and Azure Pack refer the Azure blog.
Is ASR secure? What data do you send to Azure?
Yes, ASR is secure. It neither intercepts your application data nor has any information about what is running inside your virtual machines. No Internet connectivity is needed, either from the Hyper-V hosts or the virtual machines.
Since replication is between your own enterprise and service provider sites, no application data is sent to Azure. Only metadata, such as VM or cloud names, that is needed to orchestrate failover, is sent to Azure. ASR does not have the ability to intercept your application data, and that data always remains on-premises.
ASR is ISO 27001:2005-certified, and is in the process of completing its HIPAA, DPA, and FedRAMP JAB assessments.
Compliance requirements require that even metadata from our on-premises environments remains within the same geographic region. Can ASR ensure that we meet that requirement?
Yes. When you create a Site Recovery vault in a region of your choice, we ensure that all metadata that we need to enable and orchestrate your disaster recovery setup remains within that region's geographic boundary.
What versions of Windows Server hosts and clusters are supported?
Windows Server 2012 and Windows Server 2012 R2 can be used when you choose Hyper-V Replica to enable replication and protection between Hyper-V Sites.
What versions of Hyper-V guest operating systems are supported?
The most current list of supported guest operating systems is available in the topic titled About Virtual Machines and Guest Operating Systems.
Is the identity of my tenant shared with Azure?
No. In fact, your tenants do not need access to the ASR portal. Only the service provider administrator performs actions on the ASR portal in Azure.
What if Azure is down? Can I trigger a failover from VMM?
While Azure is designed for service resilience, we like to plan for the worst. ASR is already engineered for failover to a secondary Azure datacenter in accordance with the Azure SLA. We also ensure that even when this happens, your metadata and ASR Vault remain within the same geographic region in which you chose to your vault.
What if my ISP for the primary datacenter also experiences an outage during a disaster? What if my ISP for the secondary datacenter also experiences an outage?
You can use the ASR portal to perform an unplanned failover with a single click. No connectivity from your primary datacenter is needed to perform the failover.
It's likely that applications that need to be running in your secondary datacenter after a failover will need some form of Internet connectivity. ASR assumes that even though the primary site and ISP may be impacted during a disaster, the secondary site’s SCVMM server is still connected to ASR.
Does this solution works for dedicated or shared infrastructure model?
ASR supports both dedicated as well as shared infrastructure models.
Do Tenant identities get shared with Azure?
No, in fact Tenants never have to go to Azure management portal. Only Service Provider admin uses ASR UI in Azure portal.
Will my Tenants get bill from Azure?
No Service Providers will get ASR bill from Microsoft and they will generate Tenant specific bills.
Will Tenant’s application data go to the public cloud?
For Service Provider as target site - application data never goes to Azure. It is always sent encrypted over network link between two data centers.
Performance and scaling testing: