On the Azure platform, the terms LRS, ZRS, GRS, and GZRS are encountered in a wide variety of situations. Oft scheinen deren Bedeutung aber zu wenig Aufmerksamkeit zu erhalten oder werden ganzheitlich missachtet. Especially when it comes to availability, security and service level agreements (SLA) as such. Aus diesem Grund befasst sich dieser Blogbeitrag mit der Bedeutung und den wesentlichen Unterschieden.
Redundancies of the Azure storage system
Basically, the designations are different redundancies of the Azure storage. Essentially, Azure distinguishes between storage in the same Azure region (LRS & ZRS) and storage across regions (GRS & GZRS). The following table provides an overview and is described in more detail later in this article.
|LRS||Local redundant storage||Stores data synchronously three times at one physical location.|
|ZRS||Zone redundant storage||Stores data synchronously three times at three physical locations in the same region.|
|GRS||Geo redundant storage||Saves the data synchronously three times at the primary physical location (LRS) and asynchronously three times in a secondary physical region.|
|GZRS||Geo-zone-redundant storage||Combination of GRS and ZRS. Stores data synchronously three times in three physical locations (zones) in the primary region (ZRS) and additionally asynchronously three times in a single zone in a secondary physical region (GRS).|
The table does not include all available options (such as RA-GRS / Read-access-GRS), but is limited to the basic four options. In the following, these four options are described in more detail and shown graphically to support understanding.
Local redundant storage (LRS)
As shown in the table, with this option the data is stored three times synchronously in one physical location. This means that the data is also bound to this location. Basically, such a "physical location" is called a "zone" and can be thought of as a building, data center or part of it.
A zone is defined by having its own network infrastructure as well as a supply of electricity, climate, etc. So if this zone suffers a complete failure (e.g. fire), the data is affected despite redundancy, because it shares the same "single point of failure" . This creates the risk that the data can no longer be recovered and is therefore lost.
The LRS option is the most performant, but also the one with the least security. So you should consider how critical your data is and if this option is the right one for a productive environment
Zone redundant storage (ZRS)
The table above states that Azure stores data at ZRS synchronously three times distributed over three physical locations in the same region. Compared to LRS, this option therefore breaks out of the individual zone and is enhanced with additional zones in the same region.
This significantly increases safety. If a single physical location (zone) experiences a total failure and another zone in the same region remains undamaged, data availability is still guaranteed. However, if the entire region (e.g. Switzerland North) experiences a total failure, even zone-redundant storage does not protect against loss.
Geo redundant storage (GRS)
If the zone-redundant storage is not sufficient for the requirements, the geo redundant storage (GRS) is available as a further option. With this option, Azure itself breaks down the region boundary and accesses another region in which Microsoft stores the data again. As a result, the data is synchronously available three times in a zone of the primary region, as is the case with LRS. In addition, however, an asynchronous copy of the data finds its way into a single zone of the second (secondary) region, thus providing increased protection.
Two or more regions together each form a geography, with the regions at least 300 miles apart, if possible. Typically, a geography consists of markets or national borders, such as Switzerland. There the two regions "Switzerland North" and "Switzerland" West form the geography "Switzerland". The data do not leave the geography.
Geozonenredundanter Speicher (GZRS)
Even greater protection can be achieved with the combination of GRS and ZRS. If this option is selected, the data is stored both zone redundantly (ZRS) in the primary region (e.g. Switzerland North). In addition, as with GRS, an asynchronous copy is then available in a single zone of the secondary region.
At the time of this article's update, the GZRS option is the most secure. This ensures that the data in the first region is synchronously located in different, independent data centers and additionally in the secondary region as a copy. With this configuration, the risk of serious data loss is extremely low and almost completely eliminated.
Differences of the Service Level Agreement (SLA)
Redundancy of data is certainly a very important factor and should not be disregarded. But in order to make an informed decision of the type to choose, other factors must also be considered. In addition to redundancy, geography, costs and, of course, performance, the service level agreement (SLA) is also a decisive factor, as is the case with all offerings that are purchased as a service. Depending on which storage type is selected (Cool and Hot), Microsoft grants a different SLA for the underlying storage account.
Azure LRS, ZRS, GRS & GZRS does not affect the SLA of the underlying storage account. The following table applies to both read and write accesses of the storage account. Microsoft describes the granted SLA at this link.
|Hot Storage||Cool Storage|
If we only consider the storage in isolation from other services, the choice of redundancy type for the storage account is irrelevant. What is more decisive is whether hot or cool storage is used. In addition to the storage account, however, there are specific data redundancy SLAs to consider.
The storage account defines the SLA for read and write accesses. On the other hand, the selected data redundancy (LRS, ZRS, GRS, GZRS) defines the SLA for the durability of the stored data.
|LRS||99,999999999 % (11 mal die 9)|
|ZRS||99,9999999999 % (12 mal die 9)|
|GRS||99,99999999999999 % (16 mal die 9)|
|GZRS||99,99999999999999 % (16 mal die 9)|
Microsoft now summarizes the SLA percentages very clearly in a consolidated table under this link. Both for the storage account, as well as for the different types of data redundancy.
Sources: https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy?WT.mc_id=AZ-MVP-5004129 https://azure.microsoft.com/global-infrastructure/geographies/?WT.mc_id=AZ-MVP-5004129#overview https://azure.microsoft.com/support/legal/sla/storage/v1_5/?WT.mc_id=AZ-MVP-5004129 https://docs.microsoft.com/de-ch/azure/storage/common/storage-redundancy?WT.mc_id=AZ-MVP-5004129#geo-redundant-storage