Windows Azure Pack with DR add-on (ASR)

One of the good things with Windows Azure Pack is that it is an extensible solution where we are able to customize, extend and integrate WAP to meet our desired configuration.

I have already covered the majority of the API’s we have available, both from an admin perspective and from a tenant perspective.

These blog posts can be found here:

http://kristiannese.blogspot.no/2014/06/azure-pack-working-with-tenant-public.html

http://kristiannese.blogspot.no/2014/06/working-with-admin-api-in-windows-azure.html

http://kristiannese.blogspot.no/2014/09/how-azure-pack-is-using-service.html

The intention of this blog post is to drive awareness of the solution that Microsoft now has made available.

Offering managed DR for IaaS workload with ASR and Windows Azure Pack

http://azure.microsoft.com/blog/2014/11/12/offering-managed-dr-for-iaas-workloads-with-asr-and-azure-pack/

Many people have requested that Windows Azure Pack should have an integration with Hyper-V Replica, or Azure Site Recovery.

If you are not familiar with Azure Site Recovery as a concept, you can think of it as the umbrella for all the DR capabilities that Microsoft provides, including storage replication that will be available in the Update Rollup 5 for SCVMM (currently in preview). Azure Site Recovery let you use Hyper-V Replica through SCVMM on-premise to either replicate to a secondary datacenter (on-premise) or use Microsoft Azure as your DR target.

No matter what and where you go, the experience will be the same and provide you with consistency.

I will not cover the setup or the actual workflow of the DR integration with WAP since it is very detailed explained in the URL above.

Instead, I would point out the high-level design of this solution and what you really need to think of.

After you have installed Update Rollup 4 for Windows Azure Pack, you will see some small changes in the UI when you drill into the Plan in WAP and explore the VM Cloud services.

This is where we will enable DR as an add-on, meaning that tenants are able to associate that add-on to an existing subscription they have.

The DR add-on will consist of several SMA runbooks that you will have to import into your WAP environment in the Admin Portal.

Once this is done from the tenant side, this will effectively trigger the SMA runbooks that will replicate all the virtual machines running in that subscription to the target environment.

The subscription ID itself will be replicated with all the mapping down towards each and every tenant VM.

However, virtual networks (if using NVGRE) is not replicated. This means the tenant will have to recreate the networking artifacts in the secondary environment, and you – the service provider must perform the initial network mapping in ASR.

The SMA runbooks can be scheduled so that once a new VM is deployed into that particular subscription, the VM will be scheduled for initial replication and be protected.

Now, over to the delicate explanation of the initial design in order to implement this.

In Azure Site Recovery when using DR between on-premises sites, we are doing the mapping at the VMM Cloud level. The Cloud in VMM should contains Hyper-V hosts/clusters within one or more host groups that will be the foundation of the virtual machines and the replica.

As you may be aware of, in Windows Azure Pack when you create hosting plans, these hosting plans that contains VM Services will be bound to a VMM cloud and a VMM server.

In other words, we are not able to replicate with ASR using a single cloud, although we could have two different host groups (primary and replica) within that cloud.

So since we have to have two clouds, we also need two plans. Hence we have an isolation issue to deal with in order to provide DR with a good tenant experience.

The subscription each tenant create will be unique in the environment, and we are not able to use the same subscription twice within an environment. But if we have two subscriptions, then the tenant would have to know which one to use and could easily lead to mistakes.

So in order to keep the subscription ID and its resources, we need to have another Azure Pack environment.

And since we need to have another Azure Pack environment, we also need another instance of Service Provider Foundation (SPF).

So from a tenant perspective during a failover process, they will be redirected to the WAP environment which is currently online, sign in with their credentials and get access to their resources. The only thing that has changed is the URL to the tenant portal itself.

I know it can be hard to absorb this information at first, especially if we are not familiar with the concept of stamp and the actual architecture of the multi-tenant IaaS cloud platform we are dealing with. So I have created some graphics to show each layer and the purpose of each layer.

High-level overview of management stamps with Windows Azure Pack and Azure Site Recovery

Overview of the different layers for the VM Cloud Resource provider in the context of WAP with DR add-on:

Hopefully this makes sense and gives you a better understanding of the design of Windows Azure Pack with DR add-on

Please note that this is a managed DR solution, where the service provider has very clear responsibility.

They need to perform the initial setup, perform all the processes and ensure that testing and planning are compliant with the actual SLA they provides for this solution.