Azure Storage-Redundanz

Azure Storage speichert immer mehrere Kopien Ihrer Daten, damit sie vor geplanten und ungeplanten Ereignissen geschützt sind – von vorübergehend auftretenden Hardwarefehlern über Netzwerk- oder Stromausfälle bis hin zu schweren 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:

  • Wie Ihre Daten in der primären Region repliziert werden.
  • Ob Ihre Daten in eine zweite Region repliziert werden, die von der primären Region geografisch entfernt ist, 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 aus irgendeinem Grund nicht mehr zur Verfügung steht (Georeplikation mit Lesezugriff).

Hinweis

Die in diesem Artikel beschriebenen Features und die regionale Verfügbarkeit sind auch für Konten mit einem hierarchischen Namespace (Azure Blob Storage) verfügbar.

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. Möglicherweise möchten Sie 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.

Hinweis

Microsoft empfiehlt die Verwendung von ZRS in der primären Region für Azure Data Lake Storage Gen2-Workloads.

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 in einem Rechenzentrum (Feuer, Überschwemmung usw.) gehen jedoch eventuell alle Replikate in einem Speicherkonto, das LRS verwendet, verloren oder können nicht mehr wiederhergestellt werden. 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:

Diagram showing how data is replicated in a single data center with LRS

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 sich für LRS entscheiden.
  • Wenn Ihre Anwendungen aufgrund von Datengovernancevorschriften auf die Replikation von Daten innerhalb eines Lands/einer Region beschränkt ist, können Sie LRS verwenden. In einigen Fällen können sich die gekoppelten Regionen, in denen die Daten georepliziert werden, in einem anderen Land oder 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 abonnieren. 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 eine Dauerhaftigkeit für Speicherressourcen von mindestens 99,9999999999 % (12 mal die 9) über einen Zeitraum von einem Jahr.

Auf Ihre Daten kann mit ZRS weiterhin von 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. Diese Updates können sich 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.

Microsoft empfiehlt die Verwendung von ZRS in der primären Region für Szenarien, die Hochverfügbarkeit erfordern. ZRS wird auch zum Einschränken der Replikation von Daten auf ein bestimmtes Land oder eine bestimmte Region empfohlen, um die Anforderungen an die Datengovernance 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:

Diagram showing how data is replicated in the primary region with ZRS

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 nicht vor einem regionalen Notfall schützen, bei dem mehrere Zonen dauerhaft betroffen sind. Für den Schutz vor regionalen Notfällen empfiehlt Microsoft die Verwendung von geozonenredundantem Speicher (GZRS), der ZRS in der primären Region verwendet und die Daten in eine sekundäre Region georepliziert.

Die Archivspeicherebene für Blob Storage wird bei ZRS-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, Seitenblobs ohne Datenträger)
  • Azure Files (alle Standardebenen: „transaktionsoptimiert“, „heiß“ und „kalt“)
  • Azure Table Storage
  • Azure Queue Storage

ZRS für Speicherkonten vom Typ „Universell V2“ steht für eine Teilmenge von Azure-Regionen zur Verfügung:

  • (Afrika) Südafrika, Norden
  • (Asien-Pazifik) Australien, Osten
  • (Asien-Pazifik) Indien, Mitte
  • (Asien-Pazifik) Asien, Osten
  • (Asien-Pazifik) Japan, Osten
  • (Asien-Pazifik) Südkorea, Mitte
  • (Asien-Pazifik) Indien, Süden
  • (Asien-Pazifik) Asien, Südosten
  • (Europa) Frankreich, Mitte
  • (Europa) Deutschland, Westen-Mitte
  • (Europa) Europa, Norden
  • (Europa) Norwegen, Osten
  • (Europa) Schweden, Mitte
  • (Europa) Schweiz, Norden
  • (Europa) Vereinigtes Königreich, Süden
  • (Europa) Europa, Westen
  • (Nordamerika) Kanada, Mitte
  • (Nordamerika) USA, Mitte
  • (Nordamerika) USA, Osten
  • (Nordamerika) USA, Osten 2
  • (Nordamerika) USA, Süden-Mitte
  • (Nordamerika) US Gov Virginia
  • (Nordamerika) USA, Westen 2
  • (Nordamerika) USA, Westen 3
  • (Südamerika) Brasilien, Süden

Premium-Blockblobkonten

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

Premium-Blockblobs sind in einer Teilmenge von Azure-Regionen verfügbar:

  • (Asien-Pazifik) Australien, Osten
  • (Asien-Pazifik) Asien, Osten
  • (Asien-Pazifik) Japan, Osten
  • (Asien-Pazifik) Asien, Südosten
  • (Europa) Frankreich, Mitte
  • (Europa) Europa, Norden
  • (Europa) Europa, Westen
  • (Europa) Vereinigtes Königreich, Süden
  • (Nordamerika) USA, Osten
  • (Nordamerika) USA, Osten 2
  • (Nordamerika) USA, Westen 2
  • (Nordamerika) USA, Süden-Mitte
  • (Südamerika) Brasilien, Süden

Premium-Dateifreigabekonten

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

ZRS für Premium-Dateifreigaben ist für eine Teilmenge von Azure-Regionen verfügbar:

  • (Asien-Pazifik) Australien, Osten
  • (Asien-Pazifik) Japan, Osten
  • (Asien-Pazifik) Asien, Südosten
  • (Europa) Frankreich, Mitte
  • (Europa) Europa, Norden
  • (Europa) Europa, Westen
  • (Europa) Vereinigtes Königreich, Süden
  • (Nordamerika) USA, Osten
  • (Nordamerika) USA, Osten 2
  • (Nordamerika) USA, Westen 2
  • (Nordamerika) USA, Süden-Mitte
  • (Südamerika) Brasilien, Süden

Redundanz in einer sekundären Region

Bei Anwendungen, die hohe Dauerhaftigkeit erfordern, können Sie die Daten in Ihrem Speicherkonto zusätzlich in eine sekundäre Region kopieren, die Hunderte von Kilometern von der primären Region entfernt ist. Wenn Ihr Speicherkonto in eine sekundäre Region kopiert wird, sind Ihre Daten dauerhaft gespeichert, selbst bei einem regionalen Komplettausfall oder einem Notfall, nach dem die primäre Region nicht mehr wiederhergestellt werden kann.

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.

Hinweis

Der Hauptunterschied zwischen GRS und GZRS besteht in der Art, wie Daten in der primären Region repliziert werden. In der sekundären Region werden die Daten immer dreimal synchron mithilfe von LRS repliziert. LRS in der sekundären Region schützt Ihre Daten vor Hardwareausfällen.

Mit GRS oder GZRS sind die Daten in der sekundären Region nicht für Lese- oder Schreibzugriffe verfügbar, sofern kein Failover in die sekundä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 wieder Daten lesen und schreiben. Weitere Informationen zur Notfallwiederherstellung und zum Failover in die sekundäre Region finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Wichtig

Da Daten asynchron in die sekundären Region repliziert werden, kann ein Fehler, der sich auf die primäre Region auswirkt, zu Datenverlusten führen, wenn die primäre Region nicht wiederhergestellt werden kann. Das Intervall zwischen den letzten Schreibvorgängen in der primären Region und dem letzten Schreibvorgang in der sekundären Region wird als RPO (Recovery Point Objective) bezeichnet. Die RPO gibt den Zeitpunkt an, auf den Daten wiederhergestellt werden können. Die Azure Storage-Plattform weist normalerweise einen RPO-Wert von weniger als 15 Minuten auf, obwohl es zurzeit keine SLA zur Dauer der Replikation von Daten in die sekundäre Region gibt.

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 eine Dauerhaftigkeit für Speicherressourcen von mindestens 99,99999999999999 % (16 mal die 9) über einen Zeitraum von einem 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:

Diagram showing how data is replicated with GRS or RA-GRS

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. Daten in einem GZRS-Speicherkonto werden über drei Azure-Verfügbarkeitszonen in die primäre Region kopiert sowie auch in eine sekundäre geografische Region zum Schutz vor regionalen Notfällen. 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-Speicherkonto können Sie weiterhin Daten lesen und schreiben, wenn eine Verfügbarkeitszone nicht verfügbar oder nicht wiederherstellbar ist. Außerdem sind Ihre Daten auch bei einem regionalen Komplettausfall oder einem Notfall, nach dem die primäre Region nicht mehr wiederhergestellt werden kann, beständig gespeichert. GZRS ist darauf ausgelegt, für Objekte eine Dauerhaftigkeit von mindestens 99,99999999999999 Prozent (16 Neunen) in einem bestimmten Jahr bereitzustellen.

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

Diagram showing how data is replicated with GZRS or RA-GZRS

Nur Speicherkonten vom Typ „Standard, Universell V2“ unterstützen GZRS. GZRS wird von allen Azure Storage-Diensten unterstützt, 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

GZRS ist für eine Teilmenge von Azure-Regionen verfügbar:

  • (Afrika) Südafrika, Norden
  • (Asien-Pazifik) Australien, Osten
  • (Asien-Pazifik) Asien, Osten
  • (Asien-Pazifik) Japan, Osten
  • (Asien-Pazifik) Südkorea, Mitte
  • (Asien-Pazifik) Asien, Südosten
  • (Asien-Pazifik) Indien, Mitte
  • (Europa) Frankreich, Mitte
  • (Europa) Europa, Norden
  • (Europa) Norwegen, Osten
  • (Europa) Schweden, Mitte
  • (Europa) Schweiz, Norden
  • (Europa) Vereinigtes Königreich, Süden
  • (Europa) Europa, Westen
  • (Nordamerika) Kanada, Mitte
  • (Nordamerika) USA, Mitte
  • (Nordamerika) USA, Osten
  • (Nordamerika) USA, Osten 2
  • (Nordamerika) USA, Süden-Mitte
  • (Nordamerika) USA, Westen 2
  • (Nordamerika) USA, Westen 3
  • (Nordamerika) US Gov Virginia
  • (Südamerika) Brasilien, Süden

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. Bei einem für GRS oder GZRS konfigurierten Konto können Benutzer oder Anwendungen nicht direkt auf die Daten in der sekundären Region zugreifen, es sei denn, es kommt zu einem Failover. Der Failovervorgang aktualisiert den von Azure Storage bereitgestellten DNS-Eintrag, sodass der sekundäre Endpunkt zum neuen primären Endpunkt für Ihr Speicherkonto wird. 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 zu Failover und Notfallwiederherstellung finden Sie unter Funktionsweise eines Kontofailovers.

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.

Achtung

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. Im Falle eines Notfalls in der primären Region würden wahrscheinlich einige Daten verloren gehen. Weitere Informationen zum Planen für den Fall potenzieller Datenverluste finden Sie unter Vorhersehen von Datenverlust.

Hinweis

Azure Files unterstützt nicht georedundanten Speicher mit Lesezugriff (RA-GRS) oder geozonenredundanten Speicher mit Lesezugriff (RA-GZRS).

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 steht für Lesezugriff zur Verfügung, nachdem Sie RA-GRS oder RA-GZRS aktiviert haben, sodass Sie Ihre Anwendung vorab testen können, um sicherzustellen, dass sie bei einem Ausfall ordnungsgemäß aus der sekundären Region liest. 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 Lesezugriff auf den sekundären Standort aktiviert ist, kann Ihre Anwendung sowohl vom sekundären Endpunkt als auch vom primären Endpunkt 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.

Überprüfen der Eigenschaft für die letzte Synchronisierung

Da Daten asynchron in die sekundären Region repliziert werden, liegt die sekundäre Region oft hinter der primären Region zurück. Wenn in der primären Region ein Fehler auftritt, wurden sämtliche Schreibvorgänge im primären Replikat wahrscheinlich noch nicht in die sekundäre Region repliziert.

Um zu ermitteln, welche Schreibvorgänge in die sekundäre Region repliziert wurden, kann Ihre Anwendung die Eigenschaft Letzte Synchronisierung für Ihr Speicherkonto überprüfen. Alle Schreibvorgänge, die vor der letzten Synchronisierungszeit in die primäre Region geschrieben wurden, wurden erfolgreich in die sekundäre Region repliziert, sodass sie für das Lesen aus der sekundären Region zur Verfügung stehen. Alle Schreibvorgänge, die nach der letzten Synchronisationszeit in die primäre Region geschrieben wurden, können ggf. in die sekundäre Region repliziert worden sein (oder auch nicht), sodass sie möglicherweise nicht für Lesevorgänge zur Verfügung stehen.

Sie können den Wert der Eigenschaft Last Sync Time (Letzte Synchronisierungszeit) mit Azure PowerShell, der Azure CLI oder einer der Azure Storage-Clientbibliotheken abfragen. Die Eigenschaft Last Sync Time ist ein GMT-Datums-/Uhrzeitwert. Weitere Informationen finden Sie unter Überprüfen der Eigenschaft „Letzte Synchronisierung“ für ein Speicherkonto.

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:

Parameter LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Prozentuale Dauerhaftigkeit von Objekten über ein bestimmtes Jahr mindestens 99,999999999 % (11 mal die 9) mindestens 99,9999999999 % (12 mal die 9) mindestens 99,99999999999999 % (16 mal die 9) mindestens 99,99999999999999 % (16 mal die 9)
Verfügbarkeit für Leseanforderungen Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) für GRS

Mindestens 99,99 % (99,9 % für die kalten oder Archivzugriffsebenen) für RA-GRS
Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) für GZRS

Mindestens 99,99 % (99,9 % für die kalten oder Archivzugriffsebenen) für RA-GZRS
Verfügbarkeit für Schreibanforderungen Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen) Mindestens 99,9 % (99 % für die kalten oder Archivzugriffsebenen)
Die Anzahl der Datenkopien, die auf separaten Knoten gespeichert werden. Drei Kopien innerhalb einer Region Drei Kopien in separaten Verfügbarkeitszonen innerhalb einer einzelnen Region Sechs Kopien insgesamt, darunter drei in der primären Region und drei in der sekundären Region Sechs Kopien insgesamt, darunter drei über separate Verfügbarkeitszonen in der primären Region und drei lokal redundante Kopien in der sekundären Region

Weitere Informationen finden Sie in der Vereinbarung zum Servicelevel (SLA) für Storage-Konten.

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:

Ausfallszenario LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Ein Knoten innerhalb eines Rechenzentrums steht nicht mehr zur Verfügung. Ja Ja Ja Ja
Ein gesamtes Rechenzentrum (zonal oder nicht zonal) ist nicht mehr verfügbar. Nein Ja Ja1 Ja
Ein regionsweiter Ausfall in der primären Region Nein Nein Ja1 Ja1
Wenn die primäre Region nicht verfügbar ist, ist der Lesezugriff in der sekundären Region verfügbar. Nein Nein Ja (mit RA-GRS) Ja (mit RA-GZRS)

1 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 wird dargestellt, welche Redundanzoptionen von den einzelnen Azure Storage-Diensten unterstützt werden.

LRS ZRS GRS RA-GRS GZRS RA-GZRS
Blob Storage (einschließlich Data Lake Storage)
Queue Storage
Tabellenspeicher
Azure Files1,2
Verwaltete Azure-Datenträger
Seitenblobs
Blob Storage (einschließlich Data Lake Storage)
Queue Storage
Tabellenspeicher
Azure Files1,2
Verwaltete Azure-Datenträger3
Blob Storage (einschließlich Data Lake Storage)
Queue Storage
Tabellenspeicher
Azure Files1
Blob Storage (einschließlich Data Lake Storage)
Queue Storage
Table Storage
Blob Storage (einschließlich Data Lake Storage)
Queue Storage
Tabellenspeicher
Azure Files1
Blob Storage (einschließlich Data Lake Storage)
Queue Storage
Tabellenspeicher

1 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.
2 Premium-Dateifreigaben werden für LRS und ZRS unterstützt.
3 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.

Speicherkontotypen LRS ZRS GRS/RA-GRS GZRS/RA-GZRS
Empfohlen Standard, Universell V2 (StorageV2)1

Premium-Blockblobs (BlockBlobStorage)1

Premium-Dateifreigaben (FileStorage)

Premium-Seitenblobs (StorageV2)
Standard, Universell V2 (StorageV2)1

Premium-Blockblobs (BlockBlobStorage)1

Premium-Dateifreigaben (FileStorage)
Standard, Universell V2 (StorageV2)1 Standard, Universell V2 (StorageV2)1
Vorversion Standard, Universell V1 (Storage)

Legacy-Blob (BlobStorage)
Standard, Universell V1 (Storage)

Legacy-Blob (BlobStorage)

1 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 kopiert. Weitere Informationen zu Blobebenen finden Sie unter Zugriffsebenen „Heiß“, „Kalt“ und „Archiv“ für Blobdaten.

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

Hinweis

Azure Disk Storage Premium unterstützt derzeit nur lokal redundanten Speicher (LRS). Blockblob-Speicherkonten unterstützen lokal redundanten Speicher (LRS) und zonenredundanten Speicher (ZRS) in bestimmten Regionen.

Unterstützung für kundenverwaltetes Kontofailover

Alle georedundanten Angebote unterstützen ein von Microsoft verwaltetes Failover bei einem Notfall in der primären Region. Darüber hinaus unterstützen einige Kontotypen ein kundenverwaltetes Kontofailover, wie in der folgenden Tabelle dargestellt. Unterstützte Kontotypen müssen Azure Resource Manager-Bereitstellungen verwenden. Weitere Informationen zur Notfallwiederherstellung und zum kundenverwalteten Failover finden Sie unter Notfallwiederherstellung und Speicherkontofailover.

Typ des Failovers GRS/RA-GRS GZRS/RA-GZRS
Kundenverwaltetes Failover Universell V2-Konten
Universell V1-Konten
Legacy-Blob Storage-Konten
Allgemeines Konto vom Typ „General Purpose v2“
Von Microsoft verwaltetes Failover Alle Kontotypen Allgemeines Konto vom Typ „General Purpose v2“

Hinweis

Kundenverwaltetes Kontofailover wird in Konten mit einem hierarchischen Namespace (Azure Data Lake Storage Gen2) noch nicht unterstützt. Weitere Informationen finden Sie unter Verfügbare Blob Storage-Features in Azure Data Lake Storage Gen2.

Im Falle eines Notfalls, der sich auf die primäre Region auswirkt, verwaltet Microsoft das Failover für Konten mit einem hierarchischen Namespace. Weitere Informationen finden Sie unter Microsoft-verwaltetes Failover.

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