Okay, haven't found any VMs.
I'm not exactly sure what that is,
maybe my on‑premises VMware machines haven't been online all that long,
but this is where you can enumerate all of the virtual machines that have
been detected on your local or off‑cloud environment,
okay?
And then you bring in again replication metadata and then let it rip.
I know I'm being relatively schematic.
I'm doing that intentionally because the Azure architecture exams get into
the weeds much more so, so does the Azure Administrator,
then does the AZ‑801.
For AZ‑801, you need to know the basic workflow.
That when you're doing Hyper‑V,
you just install that recovery provider on your Hyper‑V hosts.
You don't need a separate appliance.
If you're protecting on‑premises VMware,
you'll need them orchestrated with vCenter,
and you will have a local virtual machine appliance that
helps you with inventory and so on.
And you're specifying those machines that comprise your workload and
where the recovery environment is going to be.
I'm assuming that we're all going to failover into Azure.
Now, if your machines are already in Azure arranged in a workload,
your prep step's already finished,
so you can go right to enabling replication by specifying your source,
what VMs you want to protect,
and then the replication settings as you can see here,
all right?
Now, as you can imagine,
it's going to take the longest amount of time for that initial replication to
happen between your source and disaster recovery environments.
Let me head on over into my westus recovery services vault,
and we'll come down under Protected Items,
Replicated Items, and see what we have here.
It looks like I have just a single virtual machine that is in a
healthy replication state, and it is protected,
which means that its storage and configuration are synchronized with this vault.
That's going to be my disaster recovery environment here.
So if we give it a click, we can come into its details here.
And the idea is that you can come in and inspect each VM,
but unless you specifically want to failover just a single virtual machine,
this isn't the interface for it.
Please understand, it took me a little while when I was first learning this.
If you have a workload, you're going to want to failover the recovery plan,
not the individual machines.
Let me show you what I mean.
Let me close out of here.
And if we come down under Manage, Recovery Plans,
let's create a new recovery plan right now.
I'll call this dr‑plan1.
The source is in East US, target is in West US,
Resource Manager deployment, and we can select the items here,
there's my web2.
But again, the idea is this would be your collection.
Maybe you have three web servers, three business servers,
and six database servers, you can do a multi select here.
I just have a simple, single VM environment, nothing too complicated.
And also the abstraction of Azure Resource Manager means that this interface
is the same regardless of whether web2 is running on‑prem,
in another cloud, or as a native Azure virtual machine.
In some sense, it doesn't matter.
Let's click OK, and then let's click Create to build that recovery plan.
The recovery plan is going to give us an anchor point to conduct our failovers,
and it's also going to give us the opportunity to customize.
Let's click in here, and speaking of which,
let's click Customize to customize the behavior of the failover.
Notice that the first step is always, all groups shut down.
The idea is that when you're conducting a failover,
you want to make sure that all the source machines are powered down.
Now if you have a regional failure or a data center outage,
then they're down anyway,
so this first phase isn't going to make that big of a difference.
So all groups shut down, and there's just the one machine in it right now.
Notice that when you open the ellipsis, you can choose pre and post actions,
and you can do that for all of your stages.
What that means, let me go to pre‑action here for a moment,
is that you can insert either a script or you can just
provide action instructions that your engineers will see in
the UI when they initiate a failover, okay?
More useful though it seems to me would be to use a script.
The script could, for example, verify services are started,
verify file system artifacts,
it can just serve as a nice check or a fix‑up step either before
and/or after each phase during your failover.
Now,
the catch here is that you store your scripts in an Azure Automation account.
You can't just upload a script ad hoc,
it has to be a runbook that's registered in an Automation Account,
so that's the idea.
I don't have any here and sort of barking at me here,
no runbooks found, yeah, it's empty, so it's not showing anything.
But, you know, you have your auto account,
you upload your scripts to it and specify it here.
Not that big of a deal,
but I just want you to see that that's how you would expand the capabilities of
what's happening before and/or after each of these stages.
Okay, so the next stage is all groups failover where,
in this case, it's just the one machine.
But notice that you can create groups,
and you can change group identifications of selected virtual machines.
The idea here is that you'll want to orchestrate all the VMs that
are in each class of your workload into a group.
You might have a database group, a business group,
and a web front end group, for example.
And then, very importantly,
you can control the order in which those groups failover and then start up.
You see what I mean?
You might want your database tier up and running before your
API tier and both of those tiers up and running before you
bring up your web front end.
Now I said this earlier in the lesson, but please remember that at this point,
my web2 VM is not actually running in West US, it's just that the
configuration is securely stored here in the recovery plan,
and it's basically in a replicated state.
It is in a replicated state, but it's turned off,
very much like Hyper‑V Replica acts like,
and you'll see that in the next module actually,
okay?
So these controls allow you to, if I select web2 here,
we can remove, we can move.
UI is a little bit tough to get used to,
to be totally honest,
but that's how you work with creating the actual plan for your failover.
Now when it comes to failing over, you can do test or real.
I'm going to jump right to real,
so I can show you the business point of view here.
Remember test does do a failover,
but it allows you to clean up the built environment with a single mouse click.
And it tells us here that it's recommended,
are you sure you want to embrace this risk and skip Test Failover?
I do.
Now actually it looks like Azure is not allowing me to bypass that,
so I guess Microsoft is really feeling strongly about us doing a Test Failover.
So here we go, let's do a Test Failover.
And once again,
I want you to see that we're doing a failover of the recovery plan, not an individual machine.