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:
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
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
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.
