Hey Cloud Gurus.
Welcome to our lesson on implementing data redundancy.
In this lesson, we'll start with an overview
of what we mean by data redundancy.
We'll then take a look at our options for primary region
redundancy, and then how we accomplish
secondary region redundancy.
We'll then wrap everything up in a review.
This will be a high-level overview of data redundancy.
These concepts are something you should already
be familiar with as an Azure professional.
They're baked into Azure Storage in general,
not just the portions dealing with data engineering.
And so we're going to keep it high level,
but make sure you know the fundamentals of the options
and how they compare to one another.
As an overview of Azure Storage,
it is replicated by default.
It automatically creates multiple copies of your data.
And this is built right into the service.
So you don't have to worry about a single copy
of your data being compromised.
This makes you ready in the event of failures,
helping you meet your availability and durability targets.
Azure Storage has several options for how to go about this,
allowing you to have it your own way.
You can weigh the trade-offs between lower costs
and higher availability and pick the solution
that works best for your need.
First, let's talk about protecting home base,
or in other words, your primary region.
This is where you first create your resources.
The default level of protection we talked about is LRS,
locally redundant storage.
This creates 3 synchronous copies
within a single physical location,
so inside of 1 data center.
It's the lowest cost option for redundancy,
but also has the lowest availability.
This protects you against rack or drive failures.
But if something happens to the entire data center,
such as a fire,
then all 3 copies of your data are still lost.
If you're not comfortable with that,
there is also ZRS, zone redundant storage,
and this has 3 synchronous copies across Azure
availability zones in this region.
And so even if that 1 data center is compromised,
you still have copies in 2 other data centers.
As a bonus tip, this is what Microsoft recommends for using
Azure Data Lake Storage Gen2.
If we look at these 2 options visually for LRS,
we have our data center
and the 3 copies of the data within there.
And while that gives some peace of mind about avoiding
failures, you can see that this data center
is the only thing housing our data.
So in ZRS we have a similar setup.
There's a single copy in a data center
in Availability Zone 1, but then we also have another
synchronous copy in Availability Zone 2
and Availability Zone 3.
And so you can easily see how this would give you more peace
of mind for your critical applications.
However, this is all still in 1 region
in your primary region.
Sometimes you need to take it up a notch.
If you have a disaster that affects an entire region,
and so all of the data centers within that region go down,
ZRS by itself is not enough to protect you.
For this, we have GRS, or geo-redundant storage,
and this is basically LRS plus an asynchronous copy
to a single physical location in a secondary zone.
And so you still get the 3 copies within 1 data center
and your primary zone,
and then another 3 copies using LRS in another region.
Notice that that copy is asynchronous
to the secondary region, whereas the copies in your primary
region are synchronous,
meaning they all happen at the same time.
Asynchronous can lag behind the synchronous copies some.
If GRS does not meet your needs, you can step it up
from there and go to GZRS, or geo-zone-redundant storage.
And in this case, ZRS is used in the primary region
for your synchronous copies, and then similar to GRS,
an asynchronous copy to a single physical location
in the secondary region is made.
And so the primary differentiator between these two
is not what happens in the secondary region.
Either way, that's a LRS copy of the data.
The difference is in the primary region.
One uses LRS there, the other ZRS.
It should also be noted that you don't choose
the secondary region.
When you create your storage account,
you select the primary region,
but then the paired secondary region is chosen for you
based on the primary region that you chose.
And this cannot be changed.
That's all handled by Microsoft.
It should also be noted that your secondary copies
are not readable until you fail over to them.
If you need those copies to be readable,
then you're going to need to use the RA version
of these options, RA-GRS and RA-GZRS,
the RA standing for read access.
Again, let's take a look at these visually.
And so with GRS, we have our primary region,
and within there, we have our LRS, 3 copies of the data
within 1 data center.
However, we want data in the secondary region as well.
And so we use geo-replication and create a second LRS
set of copies in Datacenter 2
that is located in that secondary region.
And if we want to have read access to that,
we enable RA-GRS for a cost, of course.
And with GZRS, again, we have our primary region,
but this time we have ZRS in play there.
And so we have our data spread across 3 different
availability zones within that region.
Again, we want to copy data to the secondary region.
And so we use geo-replication to create an LRS set
of 3 copies in a separate data center of that region.
And just as before, if we need those copies to be readable,
we need to use RA-GZRS again for a higher cost.
By way of review, LRS creates 3 copies
in 1 data center, whereas ZRS spreads the copies
across 3 availability zones in the primary region.
GRS uses LRS and the primary region,
and then implements LRS in a secondary region.
Similarly, GZRS is ZRS in the primary
plus LRS in the secondary.
Both of these options for secondary region replication
will use LRS in that secondary region.
The differentiation is whether they use LRS or ZRS
in the primary region.
And if we need the ability for our secondary copies
to be readable, we need to use RA-GRS or RA-GZRS.
And remember that each of these comes with different costs
associated with them.
LRS is going to be your cheapest option,
but also have the lowest durability.
And as you add more durability,
you're also going to add more costs.
And so every situation will be a balance
between the amount of durability you need
and the cost to implement it.
Thank you for joining me for this lesson
on implementing data redundancy.
Again, these are not concepts that are exclusive
to data engineering, and so you should already have
a good base understanding of them,
but I hope this is a good refresher and helps you understand
how to best protect your data from disasters.
That's it for now, when you're ready,
I'll see you in the next video.