This next slide has one of my favorite Microsoft Docs diagrams,
and it shows an implementation of ASR in a, well, we could look
at it, it's mentioned in the small text here, Primary Site
(On‑Premise). That's incorrect.
It should be On‑Premises. But we just as well can look at this topology as
Azure to Azure. Let's pretend that on the left our primary site is an Azure
virtual network running in our primary region, and then our VMs that
comprise our workload on the right, our failover site, may just as well be a
VNet in another Azure region.
I do want to say though, again though, you can go from on‑prem to Azure,
from Azure to on‑prem, from Azure to Azure. It's very flexible. But the
idea of the workload means that you're replicating not one, but all the
machines that make up your workload, and you're replicating the VM
configuration, which isn't that large, but principally the storage,
which is large, and that's going to be the lion's share of the
time, getting the storage on those machines synchronized from
your primary site to your Azure failover site, right? So that is
some of the mechanics. Now, you might be thinking,
well, okay, the private IP addresses that we're using in the primary site,
we're going to have to duplicate those in the failover site because
we want to mirror the environment, right? And yes,
that is right.
Remember in Azure that you can absolutely have overlapping address ranges
on VNets because VNets are air gapped from each other.
Of course, you're not going to be able to create a peering
between VNets that have overlapping addresses.
But a big question would be, well,
let's say that this is an Azure‑to‑Azure situation, and our primary site is
in East US, and our failover site is in West Us, and there is a failure on
Microsoft's side where the primary goes down.
How in the world are we going to scramble?
What exactly happens?
Well,
this solution is not required, but it's a really clever one
where we're using Azure Traffic Manager.
This is an OSI layer 7 DNS‑based load balancer, and we would use
this as the ultimate endpoint for our application.
Why?
Well, we can place both of these deployments,
that is our primary and our failover, behind the Traffic Manager's
endpoints, and we can configure Traffic Manager to route all
traffic to our primary and only use the secondary in the event
that the primary is unreachable, you see.
So that's a really nice solution.
If, for instance, you have regional application gateways or load balancers
in front of each of your environments, again, you would plug those in as endpoints in your Traffic Manager, and away you go