Demystifying Azure storage data redundancy options
LRS, ZRS, GRS, RA-GRS, GZRS, RA-GZRS: Take your pick. If you know which one to go for, then you can stop reading this article. Otherwise, read on.
One of the first option you have to choose from when creating an Azure storage account is the redundancy configuration. Microsoft offers 4+2 types of replication, and these can be a bit confusing when you look at them:
- LRS: Locally redundant storage
- ZRS: Zone-redundant storage
- GRS: Geo-redundant storage
- GZRS: Geo-zone-redundant storage
- RA-GRS: Read-access Geo-redundant storage
- RA-GZRS: Read-access Geo-zone-redundant storage
In my view, there are two main reasons why it is better to pick one that best fits your use case and workloads:
- Design for failure: in alignment with Azure well-architected framework, especially on the Reliability pillar.
- While possible, switching redundancy configuration later on can be a troublesome for some scenarios.
To start with, understand these two key points:
- Regardless of which redundancy option you choose, Azure Storage never stores only one copy of your data. Even if you choose the least redundant option, your data is always replicated three times in the primary region, this is the minimum.
- Any option with a letter “G” (for Geo) in it indicates that you have your data geo-replicated across to the paired secondary region and by default, you cannot read from this replica in the secondary region unless you opt for the RA (Read Access) option.
Next, look at these options depending on whether or not Azure Availability Zone (AZ) is used. If you are in a region that does not support Azure Availability Zones, then you’ll be looking at either LRS, GRS or RA-GRS only.
The diagram above shows you how your data is replicated depending on the option you choose
- LRS (Locally Redundant Storage) means that your data is within 1 region, 1 datacentre. Microsoft makes 3 copies of your data, spreading them across different fault domains in 1 datacentre. This is the cheapest option but is also the most risky one in terms of redundancy because if the data centre fails (e.g. flooding, fire, prolonged power outage), then your data is lost.
- GRS (Geo-Redundant Storage) means that you have another 3 copies (essentially another LRS) in a paired secondary region geo-replicated asynchronously. With GRS, you essentially have 6 copies of your data. This way, you are protected in case a region goes down, but you are still at the mercy of all 3 copies of your data stored within one datacentre within a region. With GRS, you cannot perform read on the secondary region. It purely serve for failover purpose.
- RA-GRS (Read-Access Geo-Redundant storage) is essentially GRS that allows you to perform read on the secondary region. This is better for applications which requires high availability or one that requires many read requests.
If you are in a region that supports Availability Zones, then you can choose from all 6, including ZRS, GZRS and RA-GZRS.
- ZRS (Zone-Redundant Storage) stores 3 copies of your data spreading them across 3 different availability zones within the primary region and it does so synchronously. This means you have 1 copy of your data in each datacentre with independent power, cooling and networking. This is much better than LRS because if 1 data centre fails, you still have the other 2 within the region. You also don’t run into the issue with asynchronous replication across regions.
- GZRS (Geo-Zone Redundant Storage) is essentially ZRS, but your data is also geo-replicated across to the paired secondary region. In this secondary region, your data is replicated using LRS. As with GRS, the secondary region purely serve for failover. You cannot read from it unless you manually fail over.
- RA-GZRS (Read-Access Geo-Zone Redundant Storage) is GZRS what enables you to read from the secondary region. Similar to RA-GRS, This is better for applications which requires high availability or one that requires many read requests.
For further reading, see https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy