What is the ASR Recovery Plan and how might this work specifically?
Well,
we saw in the previous module that when you're configuring
backup with the Recovery Services vault,
you have the backup policy.
There is a similar policy object in the Recovery Services vault for ASR called
the recovery plan and it's a way to do the orchestration.
Okay.
So let's take a look here.
You might configure your failover environment such
that when you initiate that failover,
the recovery plan initiates a shutdown of your source machines.
Hopefully it makes sense that you want those machines down and
deallocated and offline because you want your failover
environment to become the primary one.
Failover is initiative.
And then if this is a multi‑tier workload,
you might want to deploy the data tier first.
Now what's being deployed?
You have to understand that with our ASR,
it's the storage that is principally being replicated.
The VM configuration is trivial.
It's the storage really that is the most important,
and that in your ASR failover environment,
Azure doesn't actually create the VMs until you do the failover.
Then it will build out those VMs and you determine the order in
which those VMs get built in your recovery plan.
You also can layer in scripts before or after each phase.
So maybe after the database cluster VMs are up,
you can run a PowerShell script to make sure that services
are started and connectivity is working and so on before you
move to the business tier where, again,
you can inject scripts before or after that process,
then maybe lastly, you've got your web front end,
and the idea here is you don't want your business
tier up until your data tier is up,
you don't want your web tier up until your business and data tiers are up.
You see what I mean?
Again, you can inject scripts at any point before or after these processes,
and then at that point,
you're ready to either commit that failover or choose another recovery point.
You see, part of your setup for ASI, I know there is a lot to it,
there is no question,
part of the setup is determining the frequency that
replication snapshots are kept, and when you do a failover,
you can choose if you realize that the most recent snapshot
isn't the best state of your workload,
you can actually do the failover and then choose
another recovery point to failover again.
It isn't until you issue a commit that you can no
longer choose a recovery point, and you'll find at that time,
hopefully, your disaster recovery workload is up and running and functional.
Now, how would you handle a failback?
Let's say the primary environment is repaired, it's back online, what do you do?
Well,
I don't have a separate slide for that so I'll just
walk you through the process.
There is not a simple button that says failback, I'm afraid.
What you're going to do is enable replication,
but in the reverse direction, wait for synchronization to happen.
Now depending upon how long your downtime was, that could be a significant wait.
Once your storage between your failover and your primary
environment is again synchronized,
you would do the same process you see on this slide,
but in the reverse direction.
You see what I mean?
So once you complete that second failover,
you'll find that your primary environment is now again primary
and your secondary is not being replicated to.
So at the end of that "failback",
don't forget to reverse the direction of replication again so that
in the future you can initiate another failover.
You'll see in just a second when we do the demo that you can
conduct and should conduct test failovers.
This is a way for you, again,
to do fire drills so you and your team are familiar with how
to work with failover recovery in ASR, you know how to do the work,
and it becomes more of a muscle memory thing.
Well, here you go.
I surprised myself.
It looks like I do have a separate slide for failback.
Let's go over it now, shall we?
It's good I've already walked you through it verbally.
Let's take a look graphically.
Yes.
So after you've committed your failover and you're ready to failback,
you'll reconfigure replication in the opposite direction,
wait for protected status, initiate a failover in the reverse direction,
commit, and then re‑enable replication in the original direction.
There it is, so I did have it laid out.
Okay, enough theory. Let's get into the demo.