1
00:00:01,140 --> 00:00:01,570
All right.

2
00:00:01,570 --> 00:00:06,040
So in our Test failover, we verify the direction East to West.

3
00:00:06,040 --> 00:00:13,340
We choose our Recovery Point and what our destination virtual network is.

4
00:00:13,340 --> 00:00:16,480
And I agree with this warning that's recommended that your

5
00:00:16,480 --> 00:00:19,730
test failover go to a different VNet, absolutely.

6
00:00:19,730 --> 00:00:22,970
And that's all there is to performing the failover operation.

7
00:00:22,970 --> 00:00:26,790
And we can follow that by looking into our jobs engine.

8
00:00:26,790 --> 00:00:29,700
There's a separate list of jobs for Site Recovery

9
00:00:29,700 --> 00:00:32,610
jobs than there is for Backup jobs.

10
00:00:32,610 --> 00:00:37,990
And we can see here step by step that Azure is following the steps of this plan.

11
00:00:37,990 --> 00:00:39,350
Now at this point,

12
00:00:39,350 --> 00:00:44,500
Azure is dynamically building a new VM or at least turning it

13
00:00:44,500 --> 00:00:47,330
on and starting it up and verifying it.

14
00:00:47,330 --> 00:00:50,830
And the idea is that this replica will subsume,

15
00:00:50,830 --> 00:00:54,300
or take over, the original virtual machine.

16
00:00:54,300 --> 00:00:57,810
Let me go to my other browser tab, and let's go to Virtual machines.

17
00:00:57,810 --> 00:01:01,400
And we can see here, what machine is it again, is it web2?

18
00:01:01,400 --> 00:01:02,540
Yes, web2.

19
00:01:02,540 --> 00:01:05,850
And in this case, it's actually an Azure Virtual Machine.

20
00:01:05,850 --> 00:01:07,490
Let me refresh the view.

21
00:01:07,490 --> 00:01:10,260
And web2 is running now.

22
00:01:10,260 --> 00:01:15,340
Let me do a hard refresh to see if that makes a difference, still running.

23
00:01:15,340 --> 00:01:17,790
But we should find at the end of the process that

24
00:01:17,790 --> 00:01:20,860
web2 running in the East is down,

25
00:01:20,860 --> 00:01:25,210
and we'll have another web2 running in West in a

26
00:01:25,210 --> 00:01:28,540
disaster recovery virtual network.

27
00:01:28,540 --> 00:01:29,660
All right, what have we got?

28
00:01:29,660 --> 00:01:33,040
Well, let me highlight them to make it easier for you to see.

29
00:01:33,040 --> 00:01:37,010
I want you to notice that we've got our web2‑test running in the West,

30
00:01:37,010 --> 00:01:38,040
and that's fine.

31
00:01:38,040 --> 00:01:40,450
But the fact that web2, the original VM,

32
00:01:40,450 --> 00:01:43,560
is running is actually completely expected.

33
00:01:43,560 --> 00:01:45,330
I misspoke a moment ago.

34
00:01:45,330 --> 00:01:48,840
We have to remember that in performing a test failover,

35
00:01:48,840 --> 00:01:51,620
we don't want to perturb the production environment.

36
00:01:51,620 --> 00:01:56,060
So we'll only issue the shutdown command to the source machines when

37
00:01:56,060 --> 00:01:58,920
we're doing an actual honest‑to‑goodness failover.

38
00:01:58,920 --> 00:02:01,240
That's an important point to consider.

39
00:02:01,240 --> 00:02:05,350
So that just took two minutes or so to failover in Azure VM.

40
00:02:05,350 --> 00:02:10,440
Can you expect a longer recovery time objective with on‑prem?

41
00:02:10,440 --> 00:02:12,600
Well, that's going to be more variable, of course,

42
00:02:12,600 --> 00:02:14,970
depending upon your internet connection,

43
00:02:14,970 --> 00:02:17,970
but it should be pretty well on par because remember,

44
00:02:17,970 --> 00:02:19,600
all of those VMs,

45
00:02:19,600 --> 00:02:23,120
their storage and configuration from on‑prem have been enumerated.

46
00:02:23,120 --> 00:02:28,240
And one of the nice things about the Hyper‑V Site Recovery Provider

47
00:02:28,240 --> 00:02:35,750
and the VMware Appliance is that it helps Azure model the size of VM

48
00:02:35,750 --> 00:02:40,670
that it creates in Azure in your failover environment to be on par

49
00:02:40,670 --> 00:02:41,930
with what you have on‑prem.

50
00:02:41,930 --> 00:02:42,810
As a matter of fact,

51
00:02:42,810 --> 00:02:47,090
that's what that ASR deployment planner gives you in much more detail.

52
00:02:47,090 --> 00:02:51,430
It shows you in advance what Microsoft recommends in terms of

53
00:02:51,430 --> 00:02:54,300
things like Premium versus Standard storage,

54
00:02:54,300 --> 00:02:57,740
VM size, and so on, and so forth.

55
00:02:57,740 --> 00:03:00,130
Okay, so let's step out of this interface here.

56
00:03:00,130 --> 00:03:04,080
Let's click X, whoops, took me right out of where I wanted to be.

57
00:03:04,080 --> 00:03:07,290
Let's go back to our recovery‑vault in the West,

58
00:03:07,290 --> 00:03:13,240
and let's go back to Protected items, Replicated items.

59
00:03:13,240 --> 00:03:14,330
And let's go back here,

60
00:03:14,330 --> 00:03:18,060
and notice that we've got a Cleanup test failover pending.

61
00:03:18,060 --> 00:03:20,040
So if we go back to web2,

62
00:03:20,040 --> 00:03:23,140
notice that we don't have an option to Change recovery

63
00:03:23,140 --> 00:03:27,620
point or reverse replication direction, it's just a case of okay,

64
00:03:27,620 --> 00:03:32,810
we verified that that VM to the web2‑test machine is

65
00:03:32,810 --> 00:03:34,390
up and running; everything is fine.

66
00:03:34,390 --> 00:03:36,570
So let's go ahead and clean it up.

67
00:03:36,570 --> 00:03:37,770
Testing is complete.

68
00:03:37,770 --> 00:03:38,960
Go ahead and delete.

69
00:03:38,960 --> 00:03:40,040
Great.

70
00:03:40,040 --> 00:03:43,940
Well, once this process finishes, we can do a real failover,

71
00:03:43,940 --> 00:03:46,140
and that's going to require a bit more work.

72
00:03:46,140 --> 00:03:46,850
Why?

73
00:03:46,850 --> 00:03:49,410
Well, that's where these other buttons come into play.

74
00:03:49,410 --> 00:03:52,270
Because when we finished the real failover,

75
00:03:52,270 --> 00:03:56,390
we're going to then, once we've reestablished our source environment,

76
00:03:56,390 --> 00:03:59,750
we're going to need to turn protection or turn

77
00:03:59,750 --> 00:04:03,040
replication back on in the reverse direction,

78
00:04:03,040 --> 00:04:08,010
resynchronize, and then do another failover in that opposite direction.

79
00:04:08,010 --> 00:04:11,250
I went through all of this, I know, already, but let's face it,

80
00:04:11,250 --> 00:04:15,110
a core principle of adult education sometimes is repetition.

81
00:04:15,110 --> 00:04:16,440
Would you agree?

82
00:04:16,440 --> 00:04:20,430
So now that that's all cleaned up, let's actually go back to Virtual machines.

83
00:04:20,430 --> 00:04:22,820
Do a good old page refresh.

84
00:04:22,820 --> 00:04:26,420
Yep, so our web2‑test is gone and our web2 is fine.

85
00:04:26,420 --> 00:04:28,750
So now let's do a real business failover.

86
00:04:28,750 --> 00:04:31,230
Again, we've got our Failover direction.

87
00:04:31,230 --> 00:04:35,230
We've got our Recovery Point, Shutdown machine before beginning failover.

88
00:04:35,230 --> 00:04:37,540
That's exactly what we want to see.

89
00:04:37,540 --> 00:04:38,270
So once again,

90
00:04:38,270 --> 00:04:43,090
we can go to the appropriate job page and we can follow this process,

91
00:04:43,090 --> 00:04:47,820
which, again, remember, operates the same regardless of where those sources are.

92
00:04:47,820 --> 00:04:52,090
We're following the recovery plan step by step, phase by phase.

93
00:04:52,090 --> 00:04:56,770
I don't have any scripts injected, but we could if we needed them.

94
00:04:56,770 --> 00:04:57,840
By the way,

95
00:04:57,840 --> 00:05:02,000
I've found that the test failover is especially useful because it

96
00:05:02,000 --> 00:05:07,670
gives you a safe sandbox to test those pre and/or post‑action

97
00:05:07,670 --> 00:05:10,640
scripts that we've mentioned a few times.

98
00:05:10,640 --> 00:05:13,970
All right, so once again, it looked about 3 minutes or so,

99
00:05:13,970 --> 00:05:16,120
and that failover is complete.

100
00:05:16,120 --> 00:05:20,380
So let's again go back over to Virtual Machines, do another refresh here.

101
00:05:20,380 --> 00:05:22,360
And we can see, as I had mentioned,

102
00:05:22,360 --> 00:05:26,440
that the original VM that's running in East is stopped and deallocated.

103
00:05:26,440 --> 00:05:30,940
The replica in West is running and functional.

104
00:05:30,940 --> 00:05:35,180
So at this point, our failover is complete from an infrastructure standpoint.

105
00:05:35,180 --> 00:05:39,640
So the question next would be, how do we do a failback?

106
00:05:39,640 --> 00:05:41,760
And as we've already learned,

107
00:05:41,760 --> 00:05:45,460
it's just simply reenabling replication and failing

108
00:05:45,460 --> 00:05:47,200
over in the reverse direction.

109
00:05:47,200 --> 00:05:50,240
So once again, I know I'm kind of clicking around here,

110
00:05:50,240 --> 00:05:54,580
let's go back into our westus vault, back to Replicated items.

111
00:05:54,580 --> 00:05:57,540
Take a look at our web2 machine.

112
00:05:57,540 --> 00:06:00,040
Failover is completed.

113
00:06:00,040 --> 00:06:03,610
And the idea, actually, I probably should go to the Recovery Plan,

114
00:06:03,610 --> 00:06:06,770
which is what I used, I think, at least I hope I did.

115
00:06:06,770 --> 00:06:13,640
Come out of here and let's go down to Recovery Plans, dr‑plan.

116
00:06:13,640 --> 00:06:18,930
Ah, well it looks like I did that test failover using the plan.

117
00:06:18,930 --> 00:06:21,440
I cleaned up at the VM level,

118
00:06:21,440 --> 00:06:26,640
so this is something that is bound to happen to most people

119
00:06:26,640 --> 00:06:28,840
when you're first getting started with this.

120
00:06:28,840 --> 00:06:32,240
I'm not getting started, so I don't have an excuse, by the way.

121
00:06:32,240 --> 00:06:36,780
So let me come out of here, and let's go back to that single VM.

122
00:06:36,780 --> 00:06:40,340
The reason I'm not concerned and why I'm not going to remove

123
00:06:40,340 --> 00:06:42,570
this part of the demo is actually twofold.

124
00:06:42,570 --> 00:06:43,130
One,

125
00:06:43,130 --> 00:06:46,250
I want to give you the confidence that real world is

126
00:06:46,250 --> 00:06:49,240
real world and mistakes happen,

127
00:06:49,240 --> 00:06:54,920
unexpected events happen; it can't be perfect all the time for sure.

128
00:06:54,920 --> 00:06:55,990
And number two,

129
00:06:55,990 --> 00:06:59,590
I want to just underscore the fact of that difference of working

130
00:06:59,590 --> 00:07:03,340
from the context of the Recovery Plan if you have a multi‑machine

131
00:07:03,340 --> 00:07:06,030
workload versus the individual machines,

132
00:07:06,030 --> 00:07:08,480
which you can find under Replicated items.

133
00:07:08,480 --> 00:07:12,580
And in my case, it's fine because I do just have the one VM.

134
00:07:12,580 --> 00:07:15,240
So let's go into web2's interface here.

135
00:07:15,240 --> 00:07:17,910
And this is what I was talking about earlier.

136
00:07:17,910 --> 00:07:22,680
The fact that if you do a failover of a plan or an individual VM,

137
00:07:22,680 --> 00:07:28,200
you can then change the recovery point and redeploy the virtual

138
00:07:28,200 --> 00:07:32,840
machine using a different synchronization snapshot.

139
00:07:32,840 --> 00:07:35,330
I don't want to do that, so I will close out.

140
00:07:35,330 --> 00:07:40,700
And then the idea is when you're ready to move forward then we can commit,

141
00:07:40,700 --> 00:07:44,860
which would then not allow us to change the recovery point anymore.

142
00:07:44,860 --> 00:07:45,420
That's fine.

143
00:07:45,420 --> 00:07:46,790
We'll commit that failover.

144
00:07:46,790 --> 00:07:51,010
And at that point, we go on ahead and correct our source environment.

145
00:07:51,010 --> 00:07:54,430
We're going to fast forward because this is obviously a synthetic demo

146
00:07:54,430 --> 00:07:58,080
environment that assuming the East US is back online,

147
00:07:58,080 --> 00:08:02,140
how do we do a failback operation here?

148
00:08:02,140 --> 00:08:05,010
Well, we're going to want to do, what we're going to want to do,

149
00:08:05,010 --> 00:08:09,900
rather, is to re‑protect our workload, verify the settings,

150
00:08:09,900 --> 00:08:12,530
which is the original environment of the workload.

151
00:08:12,530 --> 00:08:13,540
That's fine.

152
00:08:13,540 --> 00:08:16,760
And all of this is happening under the hood with the JSON template.

153
00:08:16,760 --> 00:08:20,190
You might have seen in passing in the notification

154
00:08:20,190 --> 00:08:23,640
bell it mentioned ARM templates.

155
00:08:23,640 --> 00:08:28,540
All right, well, I'm waiting for synchronization to take place here in the West.

156
00:08:28,540 --> 00:08:30,410
So let me select here one more time,

157
00:08:30,410 --> 00:08:32,620
and let me just walk you through the rest of it.

158
00:08:32,620 --> 00:08:37,310
So I completed reprotection, and now it's going through a resynchronization.

159
00:08:37,310 --> 00:08:40,670
In order to finish this, to failback,

160
00:08:40,670 --> 00:08:45,290
I would do once protected as my listed status.

161
00:08:45,290 --> 00:08:48,600
I'll do another failover in the reverse direction,

162
00:08:48,600 --> 00:08:50,260
commit that failover,

163
00:08:50,260 --> 00:08:59,000
re‑protect one final time so that I'm going from the primary to the dr site, and then I think we're ready to go.