Auf der Azure Plattform trifft man die Bezeichnungen LRS, ZRS, GRS und GZRS in verschiedensten Situationen an. Oft scheinen deren Bedeutung aber zu wenig Aufmerksamkeit zu erhalten oder werden ganzheitlich missachtet. Besonders wenn es um die Verfügbarkeit, Sicherheit und Service-Level Agreements (SLA) als solches geht. Aus diesem Grund befasst sich dieser Blogbeitrag mit der Bedeutung und den wesentlichen Unterschieden.
Updated: 15.07.2022
Redundanzen des Azure Speichers
Grundsätzlich handelt es sich bei den Bezeichnungen um verschiedene Redundanzen des Azure Speichers (Storage). Im Wesentlichen unterscheidet Azure zwischen Speicher in der gleichen Azure Region (LRS & ZRS) und Speicher regionsübergreifend (GRS & GZRS). Folgende Tabelle schafft einen Überblick und wird später in diesem Beitrag ausführlicher beschrieben.
Kürzel | Name | Redundanz |
LRS | Lokalredundanter Speicher | Speichert Daten synchron dreimal an einem physikalischen Ort. |
ZRS | Zonenredundanter Speicher | Speichert Daten synchron dreimal an drei physikalischen Orten in der gleichen Region. |
GRS | Georedundanter Speicher | Speichert die Daten synchron dreimal am primären physikalischen Ort (LRS) und asynchron dreimal in einer sekundären physikalischen Region. |
GZRS | Geozonenredundanter Speicher | Kombination aus GRS und ZRS. Speichert Daten synchron dreimal an drei physikalischen Orten (Zonen) in der primären Region (ZRS) und zusätzlich asynchron dreimal in einer einzelnen Zone in einer sekundären physikalischen Region (GRS). |
Die Tabelle beinhaltet nicht alle verfügbaren Optionen (wie bspw. RA-GRS / Read-access-GRS), sondern beschränkt sich auf die grundlegenden vier Optionen. Folgend werden diese vier Optionen näher beschrieben und zur Unterstützung des Verständnisses grafisch dargestellt.
Lokalredundanter Speicher (LRS)
Wie in der Tabelle ersichtlich sind die Daten bei dieser Option dreimal synchron an einem physikalischen Ort gespeichert. Das bedeutet, dass die Daten auch an diesen Standort gebunden sind. Grundsätzlich spricht man bei einem solchen «physikalischen Ort» von einer «Zone» und kann sich dies als Gebäude, Datencenter oder Teil davon vorstellen.

Eine Zone definiert sich indem sie über eine eigene Netzwerkinfrastruktur als auch Versorgung von Strom, Klima, usw. verfügt. Wenn diese Zone also einen Komplettausfall erleidet (bspw. Feuer), so sind die Daten trotz Redundanz betroffen, da sie den gleichen «single point of failure» teilen. Dadurch besteht die Gefahr, dass die Daten nicht mehr wiederhergestellt werden können und demzufolge verloren sind.
Die LRS Option ist zwar die performanteste, doch auch die mit der geringsten Sicherheit. Man sollte sich also genau überlegen wie kritisch die Daten sind und ob diese Option die richtige für eine produktive Umgebung ist
Zonenredundanter Speicher (ZRS)
Die oben dargestellte Tabelle sagt aus, dass Azure die Daten bei ZRS synchron dreimal verteilt über drei physikalischen Orten in der gleichen Region speichert. Im Vergleich zu LRS bricht diese Option also aus der einzelnen Zone aus und wird mit weiteren Zonen in der gleichen Region ergänzt.

Die Sicherheit wird dadurch massgebend erhöht. Erfährt ein einzelner physikalischer Ort (Zone) einen Totalausfall und eine andere Zone in der gleichen Region bleibt unbeschädigt, so ist die Datenverfügbarkeit weiterhin gewährleistet. Erfährt jedoch die komplette Region (bspw. Switzerland North) einen Totalausfall, so schützt auch zonenredundanter Speicher nicht vor Verlust.
Georedundanter Speicher (GRS)
Reicht der zonenredundante Speicher den gestellten Anforderungen nicht aus, so steht als weitere Option der georedundante Speicher (GRS) zur Verfügung. Bei dieser Option bricht Azure selbst die Regionsgrenze auf und greift auf eine weitere Region zu, in der Microsoft die Daten erneut speichert. Dadurch stehen die Daten synchron dreimal in einer Zone der primären Region zur Verfügung, so wie das bei LRS der Fall ist. Zusätzlich findet aber eine asynchrone Kopie der Daten den Weg in eine einzige Zone der zweiten (sekundären) Region und gewährt so erhöhten Schutz.

Zwei oder mehrere Regionen zusammen bilden jeweils eine Geografie, wobei die Regionen mindestens 300 Meilen auseinanderliegen, wenn möglich. Typischerweise handelt es sich bei einer Geografie um Märkte oder Landesgrenzen, wie bspw. die Schweiz. Dort bilden die beiden Regionen «Switzerland North» und «Switzerland» West die Geografie «Switzerland». Die Daten verlassen die Geografie nicht.
Geozonenredundanter Speicher (GZRS)
Noch grösseren Schutz kann mit der Kombination von GRS und ZRS erreicht werden. Bei der Wahl dieser Option werden die Daten sowohl Zonenredundant (ZRS) in der primären Region gespeichert (bspw. Switzerland North). Zusätzlich steht dann wie bei GRS noch eine asynchrone Kopie in einer einzelnen Zone der sekundären Region zur Verfügung.

Zum Zeitpunkt des Updates dieses Artikels, bildet die GZRS Option die grösste Sicherheit. Es ist somit sichergestellt, dass sich die Daten in der ersten Region synchron in verschiedenen, unabhängigen Datenzentren befinden und zusätzlich noch in der sekundären Region als Kopie. Mit dieser Konfiguration ist das Risiko für einen schwerer Datenverlust äusserst gering und beinahe komplett auszuschliessen.
Unterschiede des Service-Level Agreement (SLA)
Die Redundanz der Daten ist sicherlich ein sehr wichtiger Faktor und nicht zu missachten. Doch um einen fundierten Entscheid des zu wählenden Typs zu fällen, müssen auch weitere Faktoren beachtet werden. Nebst Redundanz, Geografie, Kosten und natürlich Leistungsfähigkeit ist wie bei allen Angeboten die als Service bezogen werden, das Service-Level Agreement (SLA) mitentscheidend. Abhängig davon welcher Speicher-Typ gewählt wird (Cool und Hot), gewährt Microsoft ein anderes SLA für den unterliegenden Storage Account.
Storage Account
Keinen Einfluss hat Azure LRS, ZRS, GRS & GZRS auf das SLA des unterliegenden Storage Accounts. Die folgende Tabelle betrifft die Lese- als auch Schreibzugriffe des Storage Accounts. Microsoft beschreibt das gewährte SLA unter diesem Link.
Hot Speicher | Cool Speicher | |
LRS | 99.9% | 99% |
ZRS | 99.9% | 99% |
GRS | 99.9% | 99% |
GZRS | 99.9% | 99% |
Betrachtet man also nur den Speicher isoliert von anderen Services, so spielt die Wahl des Redundanz-Typ für den Storage Account keine Rolle. Entscheidender ist, ob Hot oder Cool Speicher verwendet wird. Zusätzlich zum Storage Account gibt es aber noch spezifisch die SLAs der Datenredundanz zu berücksichtigen.
Datenredundanz
Der Storage Account definiert das SLA für Lese- und Schreibzugriffe. Hingegen definiert die gewählte Datenredundanz (LRS, ZRS, GRS, GZRS) das SLA für die Beständigkeit der gespeicherten Daten.
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 fasst die SLA-Prozentsätze inzwischen unter diesem Link sehr übersichtlich zusammen in einer konsolidierten Tabelle. Sowohl für den Storage Account, als auch für die unterschiedlichen Typen der Datenredundanz.
Quellen: 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
Can you comment on naming of the Storage Account especially when fail over to the other region is required in a Disaster scenario? We use GRS because our third-party application will not let us change the BLOB storage location name without re-installing.
Not sure if I got your question right. But yes, you can not rename an azure Storage Account (Azure Resources in general). If that’s a need, I’m afraid you have to go through a migration.
– Creation of a new storage account with appropriate name
– Migrate data to the new storage account (with azcopy for example)
If your question is more related to what to use for disaster scenario, it depends on your appetite for risk / criticality. With GRS you’re fine and shouldn’t experience data loss due to technical issues. But if your primary region is down, you will not be able to access the data. If this is a need, you might want to use RA-GRS, which allows read access to your secondary region (async).
Hope this does answer your question and does help.
Best
Hi Yannic,
Thanks for this article !!!
You may want to add the GZRS and RA-GZRS which are new.
Best regards
Nicolas
Hello Nicolas,
Thank you a lot for your comment. In a first stage I’ll focus on mainly on the basic 3 options, as RA is generally just additional read access on the copies. But fair point, GZRS in fact is a very interesting one, which I should add in a second version of this article. Thank you for your valuable feedback, I’ll let you know as soon as it’s done.
Best,
Yannic
Finally, I did the update of this post. Hope it does help 🙂