Azure Storage-Redundanz

Azure Storage speichert immer mehrere Kopien Ihrer Daten, um sie vor geplanten und ungeplanten Ereignissen zu schützen. Zu diesen Ereignissen gehören vorübergehende Hardwarefehler, Netzwerk- oder Stromausfälle sowie Naturkatastrophen. Redundanz stellt sicher, dass Ihr Speicherkonto seine Ziele für Verfügbarkeit und Dauerhaftigkeit selbst bei Ausfällen erfüllt.

Berücksichtigen Sie bei der Entscheidung, welche Redundanzoption für Ihr Szenario am besten geeignet ist, die Kompromisse zwischen geringeren Kosten und höherer Verfügbarkeit. Anhand der folgenden Faktoren können Sie bestimmen, welche Redundanzoption Sie auswählen sollten:

• Replikation Ihrer Daten in der primären Region.
• Ob Ihre Daten von einer primären Region in eine sekundäre, geografisch entfernte Region repliziert werden, um Schutz vor regionalen Ausfällen zu bieten (Georeplikation).
• Ob Ihre Anwendung Lesezugriff auf die replizierten Daten in der sekundären Region benötigt, wenn die primäre Region ausfällt (Georeplikation mit Lesezugriff).

Die Dienste, in denen Azure Storage enthalten ist, werden über eine allgemeine Azure-Ressource, ein Speicherkonto, verwaltet. Das Speicherkonto stellt einen freigegebenen Speicherpool dar, der zum Bereitstellen von Speicherressourcen wie Blobcontainern (Blob Storage), Dateifreigaben (Azure Files), Tabellen (Table Storage) oder Warteschlangen (Queue Storage) verwendet werden kann. Weitere Informationen zu Azure Storage-Konten finden Sie unter Speicherkonto – Übersicht.

Die Redundanzeinstellung für ein Speicherkonto wird für alle Speicherdienste freigegeben, die durch dieses Konto verfügbar gemacht werden. Bei allen in demselben Speicherkonto bereitgestellten Speicherressourcen gibt es dieselbe Redundanzeinstellung. Sie sollten verschiedene Arten von Ressourcen in separaten Speicherkonten isolieren, wenn sie unterschiedliche Redundanzanforderungen haben.

Redundanz in der primären Region

Daten in einem Azure Storage-Konto werden immer dreimal in der primären Region repliziert. Azure Storage bietet zwei Optionen für die Replikation Ihrer Daten in der primären Region:

• Lokal redundanter Speicher (LRS): Die Daten werden synchron innerhalb eines einzelnen physischen Standorts in der primären Region kopiert. LRS ist die kostengünstigste Replikationsoption, wird jedoch nicht für Anwendungen empfohlen, die Hochverfügbarkeit oder Dauerhaftigkeit erfordern.
• Zonenredundanter Speicher (ZRS): Die Daten werden synchron über drei Azure-Verfügbarkeitszonen hinweg in der primären Region kopiert. Für Anwendungen, die Hochverfügbarkeit erfordern, empfiehlt Microsoft die Verwendung von ZRS in der primären Region und auch das Replizieren in eine sekundäre Region.

Lokal redundanter Speicher

Bei lokal redundantem Speicher (LRS) im wird Ihr Speicherkonto innerhalb eines einzelnen Rechenzentrums in der primären Region repliziert. LRS stellt eine Dauerhaftigkeit von mindestens 99,999999999 % (11 Neunen) für Objekte in einem bestimmten Jahr bereit.

LRS ist die kostengünstigste Redundanzoption und bietet im Vergleich zu anderen Optionen die geringste Dauerhaftigkeit. LRS schützt Ihre Daten vor Serverrack- und Laufwerkfehlern. Bei einem Katastrophenfall wie einem Brand oder einer Überschwemmung in einem Rechenzentrum ist es jedoch möglich, dass alle Replikate in einem Speicherkonto mit LRS verloren gehen oder nicht mehr wiederhergestellt werden können. Zur Minimierung dieses Risikos wird empfohlen, zonenredundanten Speicher (ZRS), georedundanten Speicher (GRS) oder geozonenredundanten Speicher (GZRS) zu verwenden.

Schreibanforderungen an ein Speicherkonto, das LRS verwendet, erfolgen synchron. Die Schreibanforderung wird erst dann erfolgreich zurückgegeben, nachdem die Daten in alle drei Replikate geschrieben wurden.

Das folgende Diagramm zeigt, wie Ihre Daten mit LRS innerhalb eines einzelnen Rechenzentrums repliziert werden:

LRS ist eine gute Wahl für die folgenden Szenarien:

• Wenn Ihre Anwendung Daten speichert, die bei Datenverlust problemlos wiederhergestellt werden können, können Sie LRS verwenden.
• Wenn Ihre Anwendungen aufgrund von Data Governance-Anforderungen auf die Replikation von Daten innerhalb einer Region beschränkt ist, können Sie einen LRS in Betracht ziehen. In einigen Fällen können sich die gepaarten Regionen, über die die Daten georepliziert werden, in einer anderen Region befinden. Weitere Informationen zu gekoppelten Regionen finden Sie unter Azure-Regionen.
• Wenn in Ihrem Szenario nicht verwaltete Azure-Datenträger verwendet werden, können Sie LRS verwenden. Es ist zwar möglich, ein Speicherkonto für nicht verwaltete Azure-Datenträger zu erstellen, in dem GRS verwendet wird, doch dies wird aufgrund von potenziellen Konsistenzproblemen bei der asynchronen Georeplikation nicht empfohlen.

Zonenredundanter Speicher

Bei zonenredundantem Speicher (ZRS) wird Ihr Speicherkonto synchron über drei Azure-Verfügbarkeitszonen hinweg in der primären Region repliziert. Jede Verfügbarkeitszone ist ein getrennter physischer Standort mit unabhängigen Stromversorgungs-, Kühlungs- und Netzwerkgeräten. Der ZRS bietet Dauerhaftigkeit für Speicherressourcen von mindestens 99,9999999999 % (12 Neuner) für ein bestimmtes Jahr.

Wenn Sie den ZRS nutzen, kann auf Ihre Daten weiterhin mit Lese- und Schreibvorgängen zugegriffen werden, auch wenn eine Zone nicht mehr verfügbar ist. Wenn eine Zone nicht mehr verfügbar ist, führt Azure Netzwerkupdates durch, z. B. durch die Festlegung neuer DNS-Ziele (Domain Name System). Diese Updates können sich möglicherweise auf Ihre Anwendung auswirken, wenn Sie auf Daten zugreifen, bevor die Updates abgeschlossen sind. Halten Sie beim Entwerfen von Anwendungen für ZRS die Vorgehensweisen für vorübergehende Fehler ein. Dazu gehört u. a. die Implementierung von Wiederholungsrichtlinien mit exponentiellem Backoff.

Schreibanforderungen an ein Speicherkonto, das ZRS verwendet, erfolgen synchron. Die Schreibanforderung wird erst dann erfolgreich zurückgegeben, nachdem die Daten in alle Replikate in den drei Verfügbarkeitszonen geschrieben wurden. Wenn eine Verfügbarkeitszone vorübergehend nicht verfügbar ist, gibt der Vorgang den Status „erfolgreich“ zurück, nachdem die Daten in alle verfügbaren Zonen geschrieben wurden.

Microsoft empfiehlt die Verwendung von ZRS in der primären Region für Szenarien, die Hochverfügbarkeit erfordern. Der ZRS wird auch zum Einschränken der Datenreplikation auf eine bestimmte Region empfohlen, um die Anforderungen der Data Governance zu erfüllen.

Microsoft empfiehlt die Verwendung von ZRS für Azure Files-Workloads. Wenn eine Zone nicht mehr zur Verfügung steht, ist keine Neueinbindung von Azure-Dateifreigaben auf den verbundenen Clients erforderlich.

Das folgende Diagramm zeigt, wie Ihre Daten mit ZRS über Verfügbarkeitszonen in der primären Region hinweg repliziert werden:

ZRS bietet hervorragende Leistung, geringe Latenz und Resilienz für Ihre Daten, wenn diese vorübergehend nicht verfügbar sind. ZRS selbst kann Ihre Daten jedoch möglicherweise nicht vollständig vor einer regionalen Katastrophe schützen, durch die mehrere Zonen dauerhaft betroffen sind. Geozonenredundanter Speicher (GZRS) verwendet ZRS in der primären Region und georepliziert Ihre Daten außerdem in eine sekundäre Region. GZRS ist in vielen Regionen erhältlich und wird zum Schutz vor regionalen Katastrophen empfohlen.

Die Archivspeicherebene für Blob Storage wird bei ZRS-, GZRS- oder RA-GZRS-Konten zurzeit nicht unterstützt. Nicht verwaltete Datenträger unterstützen kein ZRS oder GZRS.

Weitere Informationen dazu, welche Regionen ZRS unterstützen, finden Sie unter Azure-Regionen mit Verfügbarkeitszonen.

Standardspeicherkonten

ZRS wird bei allen Azure Storage-Diensten über Speicherkonten vom Typ „Standard ‚Universell V2‘“ unterstützt, einschließlich:

• Azure Blob Storage (heiße und kalte Blockblobs, Anfügeblobs, Seitenblobs ohne Datenträger)
• Azure Files (alle Standardebenen: „transaktionsoptimiert“, „heiß“ und „kalt“)
• Azure Table Storage
• Azure Queue Storage

Eine Liste der Regionen, die zonenredundanten Speicher (ZRS) für Standardkonten unterstützen, finden Sie unter Azure-Regionen, die zonenredundanten Speicher (ZRS) für Standardspeicherkonten unterstützen.

Premium-Blockblobkonten

ZRS wird bei Premium-Blockblobs-Konten unterstützt. Weitere Informationen zu Premium-Blockblobs finden Sie unter Premium-Blockblob-Speicherkonten.

Eine Liste der Regionen, die zonenredundanten Speicher (ZRS) für Premium-Blockblobkonten unterstützen, finden Sie unter Azure-Regionen, die zonenredundanten Speicher (ZRS) für Premium-Blockblobkonten unterstützen.

Premium-Dateifreigabekonten

ZRS wird bei Premium-Dateifreigaben (Azure Files) durch die Speicherkontoart FileStorage unterstützt.

Eine Liste der Regionen, die zonenredundanten Speicher (ZRS) für Premium-Dateifreigabekonten unterstützen, finden Sie unter Azure Files: Zonenredundanter Speicher für Premium-Dateifreigaben.

Verwaltete Datenträger

ZRS wird für verwaltete Datenträger mit den folgenden Einschränkungen unterstützt.

Eine Liste der Regionen, die zonenredundanten Speicher (ZRS) für verwaltete Datenträger unterstützen, finden Sie unter Regionale Verfügbarkeit.

Redundanz in einer sekundären Region

Redundanzoptionen können dazu beitragen, eine hohe Dauerhaftigkeit für Ihre Anwendungen zu gewährleisten. In vielen Regionen können Sie die Daten innerhalb Ihres Speicherkontos in eine sekundäre Region kopieren, die Hunderte von Kilometern von der primären Region entfernt ist. Das Kopieren Ihres Speicherkontos in eine sekundäre Region stellt sicher, dass Ihre Daten auch bei einem kompletten Ausfall der Region oder einer Katastrophe, bei der die primäre Region nicht wiederhergestellt werden kann, erhalten bleiben.

Wenn Sie ein Speicherkonto erstellen, wählen Sie die primäre Region für das Konto aus. Die gekoppelte sekundäre Region wird basierend auf der primären Region bestimmt und kann nicht geändert werden. Weitere Informationen zu von Azure unterstützten Regionen finden Sie unter Azure-Regionen.

Azure Storage bietet zwei Optionen für das Kopieren Ihrer Daten in eine sekundäre Region:

• Georedundanter Speicher (GRS): Die Daten werden synchron dreimal innerhalb eines einzelnen physischen Standorts in der primären Region mit LRS kopiert. Anschließend werden die Daten asynchron an einen einzelnen physischen Standort in der sekundären Region kopiert. In der sekundären Region werden Ihre Daten dreimal mit LRS synchron kopiert.
• Geozonenredundanter Speicher (GZRS): Die Daten werden mit ZRS synchron über drei Azure-Verfügbarkeitszonen hinweg in der primären Region kopiert. Anschließend werden die Daten asynchron an einen einzelnen physischen Standort in der sekundären Region kopiert. In der sekundären Region werden Ihre Daten dreimal mit LRS synchron kopiert.

Bei GRS oder GZRS sind die Daten in der sekundären Region nicht für Lese- oder Schreibzugriffe verfügbar, sofern kein Failover in die primäre Region ausgeführt wird. Für den Lesezugriff in der sekundären Region konfigurieren Sie Ihr Speicherkonto für die Verwendung von georedundantem Speicher mit Lesezugriff (RA-GRS) oder geozonenredundantem Speicher mit Lesezugriff (RA-GZRS). Weitere Informationen finden Sie unter Lesezugriff auf Daten in der sekundären Region.

Wenn die primäre Region nicht verfügbar ist, können Sie ein Failover in die sekundäre Region ausführen. Nachdem das Failover abgeschlossen ist, wird die sekundäre Region zur primären Region, und Sie können Daten lesen und schreiben. Weitere Informationen zur Notfallwiederherstellung und zum Failover in die sekundäre Region finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Georedundanter Speicher

Bei georedundantem Speicher (GRS) werden die Daten synchron dreimal innerhalb eines einzelnen physischen Standorts in der primären Region mit LRS kopiert. Anschließend werden Ihre Daten asynchron an einen physischen Standort in einer sekundären Region kopiert, die Hunderte von Kilometern von der primären Region entfernt ist. Der GRS bietet Dauerhaftigkeit für Speicherressourcen von mindestens 99,99999999999999 % (16 Neuner) für ein bestimmtes Jahr.

Ein Schreibvorgang wird zunächst an den primären Speicherort übertragen und mit LRS repliziert. Anschließend wird das Update asynchron in die sekundäre Region repliziert. Wenn Daten in den sekundären Speicherort geschrieben werden, werden sie dort auch mit LRS repliziert.

Das folgende Diagramm zeigt, wie Ihre Daten mit GRS oder RA-GRS repliziert werden:

Geozonenredundanter Speicher

Mit geozonenredundantem Speicher (GZRS) wird die Hochverfügbarkeit durch Redundanz über Verfügbarkeitszonen hinweg mit dem Schutz vor regionalen Ausfällen kombiniert, der durch Georeplikation geboten wird. Die Daten in einem GZRS-Konto werden über drei Azure-Verfügbarkeitszonen in der primären Region kopiert. Zum Schutz vor regionalen Notfällen werden sie auch in eine sekundäre geografische Region repliziert. Microsoft empfiehlt die Verwendung von GZRS für Anwendungen, die maximale Konsistenz, Dauerhaftigkeit und Verfügbarkeit, hervorragende Leistung und Resilienz bei der Notfallwiederherstellung erfordern.

Mit einem GZRS-Konto können Sie weiterhin Daten lesen und schreiben, wenn eine Verfügbarkeitszone nicht verfügbar oder nicht wiederherstellbar ist. Außerdem bleiben Ihre Daten auch bei einem regionalen Komplettausfall oder einer Katastrophe, nach der die primäre Region nicht mehr wiederhergestellt werden kann, beständig gespeichert. Der GZRS bietet eine Dauerhaftigkeit von mindestens 99,99999999999999 % (16 Neuner) für Objekte in einem bestimmten Jahr.

Das folgende Diagramm zeigt, wie Ihre Daten mit GZRS oder RA-GZRS repliziert werden:

Nur Speicherkonten vom Typ „Standard, Universell V2“ unterstützen GZRS. Alle Azure Storage-Dienste unterstützen GZRS, einschließlich:

• Azure Blob Storage (heiße und kalte Blockblobs, Seitenblobs ohne Datenträger)
• Azure Files (alle Standardebenen: „transaktionsoptimiert“, „heiß“ und „kalt“)
• Azure Table Storage
• Azure Queue Storage

Eine Liste der Regionen, die geozonenredundanten Speicher (GZRS) unterstützen, finden Sie unter Azure-Regionen, die geozonenredundanten Speicher (GZRS) unterstützen.

Lesezugriff auf Daten in der sekundären Region

Georedundanter Speicher (mit GRS oder GZRS) repliziert Ihre Daten an einen anderen physischen Standort in der sekundären Region, um sie vor regionalen Ausfällen zu schützen. Wenn ein Konto für GRS oder GZRS konfiguriert ist, können Benutzer*innen oder Anwendungen bei einem Ausfall der primären Region nicht direkt auf die Daten in der sekundären Region zugreifen, es sei denn, es findet ein Failover statt. Der Failover-Prozess aktualisiert den von Azure Storage bereitgestellten DNS-Eintrag, so dass die Speicherdienstendpunkte in der sekundären Region zu den neuen primären Endpunkten für Ihr Speicherkonto werden. Während des Failovervorgangs können Sie nicht auf Ihre Daten zugreifen. Nach Abschluss des Failovers können Sie Daten in der neuen primären Region lesen und schreiben. Weitere Informationen finden Sie unter Funktionsweise kundenseitig verwalteter Speicherkontofailover zur Wiederherstellung nach einem Ausfall.

Wenn Ihre Anwendungen eine hohe Verfügbarkeit erfordern, können Sie Ihr Speicherkonto für den Lesezugriff auf die sekundäre Region konfigurieren. Wenn Sie Lesezugriff auf die sekundäre Region aktivieren, sind Ihre Daten jederzeit aus der sekundären Region für Lesevorgänge verfügbar, auch dann, falls die primäre Region nicht mehr verfügbar ist. Konfigurationen mit georedundantem Speicher mit Lesezugriff (RA-GRS) oder geozonenredundantem Speicher mit Lesezugriff (RA-GZRS) ermöglichen den Lesezugriff auf die sekundäre Region.

Entwerfen von Anwendungen für den Lesezugriff am sekundären Standort

Wenn Ihr Speicherkonto für den Lesezugriff in der sekundären Region konfiguriert ist, können Sie Ihre Anwendungen so entwerfen, dass sie nahtlos zum Lesen von Daten in der sekundären Region wechseln, wenn die primäre Region aus irgendeinem Grund nicht verfügbar ist.

Die sekundäre Region ist für den Lesezugriff verfügbar, nachdem Sie RA-GRS oder RA-GZRS aktiviert haben. Diese Verfügbarkeit ermöglicht es Ihnen, Ihre Anwendung im Voraus zu testen, um sicherzustellen, dass sie während eines Ausfalls ordnungsgemäß von der sekundären Region gelesen wird. Weitere Informationen zum Entwerfen Ihrer Anwendungen für die Nutzung von Georedundanz finden Sie unter Verwenden von Georedundanz zum Entwerfen von hoch verfügbaren Anwendungen.

Wenn der Lesezugriff auf den sekundären Endpunkt aktiviert ist, kann Ihre Anwendung sowohl von den sekundären als auch von den primären Endpunkten gelesen werden. Der sekundäre Endpunkt fügt das Suffix -secondary an den Kontonamen an. Wenn Ihr primärer Endpunkt für Blob Storage z. B. myaccount.blob.core.windows.net ist, lautet Ihr sekundärer Endpunkt myaccount-secondary.blob.core.windows.net. Die Zugriffsschlüssel für das Speicherkonto sind für die primären und sekundären Endpunkte identisch.

Planen für den Fall von Datenverlusten

Da die Daten asynchron von der primären zur sekundären Region repliziert werden, bleibt die sekundäre Region bei Schreibvorgängen in der Regel hinter der primären Region zurück. Wenn sich in der primären Region eine Katastrophe ereignet, ist es wahrscheinlich, dass einige Daten verloren gehen und dass die Dateien innerhalb eines Verzeichnisses oder Containers nicht mehr konsistent sind. Weitere Informationen zum Planen für den Fall potenzieller Datenverluste finden Sie unter Datenverlust und -inkonsistenzen.

Zusammenfassung der Redundanzoptionen

In den Tabellen in den folgenden Abschnitten werden die für Azure Storage verfügbaren Redundanzoptionen zusammengefasst.

Parameter für Dauerhaftigkeit und Verfügbarkeit

In der folgenden Tabelle werden die Schlüsselparameter für die einzelnen Redundanzoptionen beschrieben:

Weitere Informationen finden Sie unter Vereinbarung zum Servicelevel für Speicherkonten.

Dauerhaftigkeit und Verfügbarkeit nach Ausfallszenario

In der folgenden Tabelle wird gezeigt, ob Ihre Daten in einem bestimmten Szenario dauerhaft und verfügbar sind, aufgeschlüsselt nach dem Redundanztyp Ihres Speicherkontos:

¹ Ein Kontofailover ist erforderlich, um die Schreibverfügbarkeit wiederherzustellen, wenn die primäre Region nicht mehr verfügbar ist. Weitere Informationen finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Unterstützte Azure Storage-Dienste

In der folgenden Tabelle werden die Redundanzoptionen, die von den einzelnen Azure Storage-Diensten unterstützt werden, dargestellt.

¹ Standard-Dateifreigaben werden für LRS und ZRS unterstützt. Die Standarddateifreigaben werden für GRS und GZRS unterstützt, solange sie kleiner oder gleich 5 TiB sind.
² Premium-Dateifreigaben werden für LRS und ZRS unterstützt.
³ Bei verwalteten ZRS-Datenträgern gibt es bestimmte Einschränkungen. Ausführliche Informationen finden Sie im Artikel zu Redundanzoptionen für verwaltete Datenträger im Abschnitt Einschränkungen.

Unterstützte Speicherkontotypen

In der folgenden Tabelle wird gezeigt, welche Redundanzoptionen bei den einzelnen Speicherkontotypen unterstützt werden. Weitere Informationen zu Speicherkontotypen finden Sie unter Speicherkontoübersicht.

¹ Konten dieses Typs, für die ein hierarchischer Namespace aktiviert ist, unterstützen auch die angegebene Redundanzoption.

Alle Daten eines Speicherkontos werden gemäß der Redundanzoption für das Speicherkonto kopiert. Es werden Objekte einschließlich Blockblobs, Anfügeblobs, Seitenblobs, Warteschlangen, Tabellen und Dateien kopiert.

Daten in allen Ebenen, einschließlich der Archivebene, werden während der Georeplikation immer von der primären Region in die sekundäre kopiert. Die Archivebene für Blob Storage wird derzeit für LRS-, GRS- und RA-GRS-Konten unterstützt, aber nicht für ZRS-, GZRS- oder RA-GZRS-Konten. Weitere Informationen zu Blobebenen finden Sie unter Zugriffsebenen für Blobdaten.

Nicht verwaltete Datenträger unterstützen kein ZRS oder GZRS.

Die Preise für die verschiedenen Redundanzoptionen finden Sie unter Azure Storage – Preise.

Datenintegrität

Azure Storage überprüft regelmäßig die Integrität der gespeicherten Daten mithilfe von Cyclic Redundancy Checks (CRCs). Wenn eine Datenbeschädigung erkannt wird, wird sie unter Verwendung von redundanten Daten repariert. Azure Storage berechnet auch die Prüfsummen für den gesamten Netzwerkdatenverkehr, um eine Beschädigung von Datenpaketen beim Speichern oder Abrufen von Daten zu erkennen.

Weitere Informationen

• Ändern der Redundanzoption für ein Speicherkonto
• Georeplikation (GRS/GZRS/RA-GRS/RA-GZRS)
  • Überprüfen der Eigenschaft „Letzte Synchronisierung“ für ein Speicherkonto
  • Notfallwiederherstellung und Speicherkontofailover
• Preise
  • Blob Storage
  • Azure Files
  • Table Storage
  • Queue Storage
  • Azure Disks