Lastly, we have Storage Replica.
And Storage Replica is a disaster recovery solution,
again, baked directly into Windows Server,
where you can replicate entire volumes between servers or clusters.
And you can configure that replication to be either synchronous or asynchronous.
Synchronous means that every write operation on the primary won't be
committed until it's committed on the secondary.
This method assumes that you have a low latency network
to be able to support that; otherwise,
you're creating a blocking situation on the primary
server or the primary cluster.
If you want to risk potential data loss,
you can do asynchronous Storage Replica,
and this is data mirroring across, again,
the use case is across a higher latency link.
And the main business cases for using Storage Replica are,
for instance, in failover clustering,
you can do a stretched or replicated cluster,
or you can just create redundancy for server storage.
Microsoft says in their docs that the server‑to‑server Storage
Replica idea could be used as a replacement,
where you might have in the past used the distributed
file system or DFSR replication.
Storage Replica represents a way to do that, perhaps in a more streamlined way.
I would say that Storage Replica in Windows Server is roughly
analogous to the high availability ideas we have in Azure VMs with
availability sets and availability zones.
But note that all of this stuff that we're learning about in
this lesson deals with Windows Server,
regardless of whether we're in Azure or on‑prem.
I mean, in Azure, you can mount disks.
I've shown you how to do that previously.
You can mount VHD files to your Azure VM,
and then you sign into your VM, and you can initialize and format,
create volumes with or without storage spaces.
So the stuff we're learning here,
although it seems like it's all Windows server on‑prem,
you can implement this stuff in the cloud too.
Of course,
the cloud gives you extra options beyond what you
get within the operating system.
Let me show you three topology diagrams.
Again, the attribution in the Microsoft Docs is in the lower, left corner.
The idea is you could use Storage Replica within a single cluster where
you need high availability for an entire cluster,
particularly using another site, say as a disaster recovery region.
So we're synchronizing the shared storage in New York in this example,
and we're able to configure automatic failover to New Jersey because that
shared storage subsystem is synchronized via Storage Replica.
Another idea is cluster‑to‑cluster.
Now this is where you've got two separate clusters,
and maybe your Los Angeles cluster is your production one and Las
Vegas is being used for test and development.
You see what I mean?
This does not support automatic failover,
but you could do a manual failover if you wanted to.
And lastly, independent of a failover cluster,
you can always configure server‑to‑server Storage Replica,
where you're replicating a volume from one machine to another.
Notice that we're using the Server Message Block protocol.
Now, the exam doesn't get into the networking and all of that and prerequisites.
We're not going to go real deep on this.
I'm going to do a demo of Storage Spaces and Storage Spaces Direct,
but all I'm going to do with Storage Replica is give
you what you need for the AZ‑800.
And the main thing there is just understanding from a high
view how you set up that replication.
Now, in terms of tools to do this, you've always got PowerShell,
that's what I'm going to show you,
but you also can do Storage Replica in Windows Admin Center.
I'm showing you some PowerShell here for two reasons.
One, it's a primary way to configure Storage Replica.
And number two,
I want to remind you that you do need to know PowerShell to
be successful on your AZ‑800 and AZ‑801 Windows Server
Hybrid Administrator certification.
And it's, I would say, an intermediate level of PowerShell.
On the first line,
I'm creating a variable called Servers that references my two nodes.
This, again, is going to be outside of a failover cluster,
just singleton server to singleton server volume replication.
And then I'm using the PowerShell pipeline to do a ForEach loop,
installing the appropriate Windows features.
We'll need Storage‑Replica, FS‑FileServer, and we'll need to restart.
Once we come back from the restart,
we can test to make sure that these two servers,
or clusters if you're doing cluster replica,
support the volume replica feature.
So we've got Test‑SRTopology,
and you notice here that we've got the Source and DestinationVolumeName.
In this code, I'm using v as the mount for that.
But notice there's a Source and DestinationLogVolume,
and that's, I'm denoting l.
Note that you're going to have to have a separate
volume to track transaction log entries.
This is a transaction based, whether you're doing synchronous or asynchronous.
The log volume should very much be solid state.
This is directly from the Microsoft Docs because the
replication for it to succeed,
you need those entries shipped to the
DestinationLogVolume as quickly as you can.
So the log volume doesn't have to be huge.
Eight gigs, I think, is the default log volume size.
And remember, if you're using Storage Spaces,
you can easily create tiered storage and create a right‑sized log
volume for each source that you want to replicate.
That's the test.
And assuming that works,
you then can use New‑SRPartnership to actually stand up the Storage Replica. Now let's do a demo and then wrap up.