1
00:00:01,040 --> 00:00:05,340
Hyper‑V Replica Deployment and Configuration. The use case for

2
00:00:05,340 --> 00:00:09,740
Hyper‑V Replica is, do we have a faster solution than backup and

3
00:00:09,740 --> 00:00:14,130
restore to protect our VMs? Well, if you know about ASR, you're thinking, well,

4
00:00:14,130 --> 00:00:17,000
yeah, of course. We can do replication and failover.

5
00:00:17,000 --> 00:00:20,600
Well, what if we weren't yet ready to adopt Azure?

6
00:00:20,600 --> 00:00:24,140
And what if we didn't have the budget frankly to pay for that

7
00:00:24,140 --> 00:00:28,680
disaster recovery infrastructure? Can we make do with features

8
00:00:28,680 --> 00:00:30,430
that are built into Windows Server?

9
00:00:30,430 --> 00:00:30,930
Well, of course,

10
00:00:30,930 --> 00:00:36,770
the answer to that is yes. The feature is called Hyper‑V Replica, and some main

11
00:00:36,770 --> 00:00:41,660
use cases here is mainly disaster recovery where you've got,

12
00:00:41,660 --> 00:00:42,360
for instance,

13
00:00:42,360 --> 00:00:46,350
multiple sites in your business and you want to protect the

14
00:00:46,350 --> 00:00:50,550
VMs, the individual Hyper‑V virtual machines, against the

15
00:00:50,550 --> 00:00:55,340
failure of not just the VM itself, but maybe there's an outage at the site level.

16
00:00:55,340 --> 00:01:00,740
What happens is Hyper‑V Replica is an asynchronous replication channel.

17
00:01:00,740 --> 00:01:05,290
Asynchronous means that when a change from the primary VM storage goes

18
00:01:05,290 --> 00:01:08,740
over your communications media to reach the secondary,

19
00:01:08,740 --> 00:01:12,440
the primary doesn't wait before sending another message.

20
00:01:12,440 --> 00:01:13,060
In other words,

21
00:01:13,060 --> 00:01:16,630
it doesn't wait for confirmation that the secondary has

22
00:01:16,630 --> 00:01:18,790
ingested that bit of data and so on.

23
00:01:18,790 --> 00:01:22,710
And so it's a bit on the lazy side as far as replication goes,

24
00:01:22,710 --> 00:01:23,680
but it's faster,

25
00:01:23,680 --> 00:01:27,550
you see. Another point I want you to understand is that with Hyper‑V

26
00:01:27,550 --> 00:01:31,800
Replica, the secondary VM is offline, very much like an Azure Site

27
00:01:31,800 --> 00:01:35,660
Recovery, as a matter of fact. I wouldn't be surprised if Azure Site

28
00:01:35,660 --> 00:01:40,140
Recovery uses Hyper‑V Replica at least in part under the hood, because

29
00:01:40,140 --> 00:01:45,090
remember, I said that Azure Site Recovery doesn't build your VMs until

30
00:01:45,090 --> 00:01:46,940
you initiate a failover.

31
00:01:46,940 --> 00:01:49,190
Similarly, with Hyper‑V Replica,

32
00:01:49,190 --> 00:01:55,100
your secondary VM is off, it is turned off and unavailable, and it

33
00:01:55,100 --> 00:01:58,570
only gets turned on when you initiate a failover,

34
00:01:58,570 --> 00:02:02,560
you see. Another layer, we could say it's more for high

35
00:02:02,560 --> 00:02:08,010
availability, is if we do a combination of failover clustering and

36
00:02:08,010 --> 00:02:12,340
highly available Hyper‑V VMs with Hyper‑V Replica.

37
00:02:12,340 --> 00:02:16,350
That way, you're combining both high availability via clustering and

38
00:02:16,350 --> 00:02:19,660
disaster recovery with Hyper‑V Replica. That's pretty cool.

39
00:02:19,660 --> 00:02:22,520
The takeaway I want you to know here for the exam, we you don't

40
00:02:22,520 --> 00:02:25,040
have to go down that route very far at all.

41
00:02:25,040 --> 00:02:29,030
You just basically have to know that when you're going to configure Hyper‑V

42
00:02:29,030 --> 00:02:33,840
Replica for a VM that's in a Windows Server failover cluster,

43
00:02:33,840 --> 00:02:37,380
you need to stand up a clustered role called Hyper‑V Replica

44
00:02:37,380 --> 00:02:44,000
Broker. That's really the money, so to speak, that I want you to keep in mind.