Bewerten von Datenredundanzoptionen für Azure Storage

  • 7 Minuten

Für die meisten Organisationen ist die Datenverfügbarkeit entscheidend für den Erfolg.

Angenommen, Ihre Kunden hatten in der Vergangenheit in seltenen Fällen Probleme, auf Musikstreams zuzugreifen. Als Sie sich diese Probleme näher angesehen haben, konnten Sie feststellen, dass diese Probleme während Ausfällen aufgetreten sind, die die gesamte Region betroffen haben. Diese Fälle sind selten aufgetreten, allerdings hatten sie eine große Wirkung.

Zur Verbesserung der Datenverfügbarkeit Ihres Unternehmens entschließen Sie sich dazu, Informationen zu den Replikationsoptionen zu sammeln, die für Azure Storage zur Verfügung stehen.

Hier lernen Sie die verschiedenen Replikationsoptionen für Azure Storage kennen. Sie erfahren, wie diese funktionieren und wann sie eingesetzt werden können. Außerdem erfahren Sie, wie Sie zwischen diesen Optionen wechseln bzw. Ihre Daten entsprechend migrieren können.

Replikationsoptionen für Azure Storage

In Azure Storage gibt es mehrere Optionen für die Replikation. Die Entscheidung für eine Option hängt davon ab, welchen Grad an Resilienz Sie benötigen.

Lokal redundanter Speicher

Illustration that shows three copies of blob data stored in the same datacenter with LRS.

Beim lokal redundanten Speicher (LRS) werden Ihre Daten dreimal in verschiedenen Hardwareracks eines Rechenzentrums innerhalb einer Region kopiert. Selbst wenn ein Hardwarefehler auftritt oder im Rechenzentrum Wartungsarbeiten durchgeführt werden, sorgt dieser Replikationstyp dafür, dass Ihre Daten zur Verwendung verfügbar sind.

LRS schützt Sie jedoch nicht vor einem rechenzentrumsweiten Ausfall. Wenn das Rechenzentrum ausfällt, könnten Sie Ihre Daten verlieren.

Georedundanter Speicher

Illustration that shows blob data copied three times to two different datacenters with GRS.

Beim georedundanten Speicher (GRS) werden Ihre Daten dreimal innerhalb einer Region kopiert sowie dreimal in eine sekundäre Region, die mit der primären Region gekoppelt ist. So steht die sekundäre Region zur Nutzung bereit, sollte die primäre Region ausfallen.

Georedundanter Speicher mit Lesezugriff

Bei GRS ist die sekundäre Region nur für Lesezugriff verfügbar, wenn es in der primären Region zu einem Fehler kommt. Wenn Sie Lesevorgänge für die sekundäre Region ausführen möchten, obwohl in der primären Region kein Fehler vorliegt, können Sie als Replikationstyp den georedundanten Speicher mit Lesezugriff (RA-GRS) verwenden.

Zonenredundanter Speicher

Illustration of data copied to three storage clusters in separate availability zones with ZRS.

Beim zonenredundanten Speicher (ZRS) werden Ihre Daten in drei Speichercluster in einer einzelnen Region kopiert. Jeder Cluster befindet sich an einem anderen physischen Standort und gilt als einzelne Verfügbarkeitszone. Jeder Cluster verwendet eigene Versorgungsunternehmen für Netzwerk und Strom. Wenn es in einem Rechenzentrum zu einem Ausfall kommt, ist der Zugriff auf Ihre Daten über eine andere Verfügbarkeitszone derselben Azure-Region weiterhin möglich.

Da sich alle Verfügbarkeitszonen in einer einzelnen Region befinden, schützt ZRS Ihre Daten nicht vor einem regionsweiten Ausfall.

Geozonenredundanter Speicher

Geozonenredundanter Speicher (GZRS) kombiniert die Vorteile der Hochverfügbarkeit von ZRS mit GRS. Bei diesem Replikationstyp werden Ihre Daten in drei Verfügbarkeitszonen einer Region kopiert. Außerdem werden die Daten dreimal in eine sekundäre Region repliziert, die mit der primären Region gekoppelt ist. So sind Ihre zonenredundanten Daten auch vor einem regionsweiten Ausfall geschützt.

Geozonenredundanter Speicher mit Lesezugriff

Geozonenredundanter Speicher mit Lesezugriff (RA-GZRS) verwendet dieselbe Replikationsmethode wie GZRS, ermöglicht Ihnen jedoch Lesevorgänge aus der sekundären Region. Wenn Sie Lesevorgänge für Daten ausführen möchten, die in die sekundäre Region repliziert wurden, obwohl in Ihrer primären Region keine Downtime herrscht, verwenden Sie RA-GZRS als Replikationstyp.

GZRS und RA-GZRS stehen aktuell in den folgenden Regionen zur Verfügung:

  • Südafrika, Norden
  • Australien (Osten)
  • Asien, Osten
  • Japan, Osten
  • Korea, Mitte
  • Asien, Südosten
  • Indien, Mitte
  • Frankreich, Mitte
  • Deutschland, Westen-Mitte
  • Nordeuropa
  • Norwegen, Osten
  • Schweden, Mitte
  • Schweiz, Norden
  • UK, Süden
  • Europa, Westen
  • Kanada, Mitte
  • USA (Mitte)
  • East US
  • USA (Ost) 2
  • USA Süd Mitte
  • USA, Westen 2
  • USA, Westen 3
  • US Gov Virginia
  • Brasilien, Süden

Regionspaare

Von einer gekoppelten Region wird dann gesprochen, wenn eine Azure-Region mit einer anderen Region am selben geografischen Standort gekoppelt wird, um vor regionalen Ausfällen schützen zu können. Gekoppelte Regionen werden für die Replikationstypen GRS und GZRS verwendet.

Illustration that shows a hierarchy of geography, regional pair, region, and datacenters.

Unten finden Sie eine Liste einiger der Regionen, die miteinander gekoppelt sind. Sie können die vollständige Liste unter Gekoppelte Azure-Regionen abrufen.

Region Region
Asien Asien, Osten Asien, Südosten
Australien Australien (Osten) Australien, Südosten
Kanada Kanada, Mitte Kanada, Osten
China China, Norden China, Osten
Europa Europa, Norden (Irland) Europa, Westen (Niederlande)
Japan Japan, Osten Japan, Westen
Nordamerika East US USA (Westen)
Südafrika Südafrika, Norden Südafrika, Westen
UK UK, Westen UK, Süden

Anwendungsfälle nach Replikationstyp

In der folgenden Tabelle wird zusammengefasst, wie viele Datenkopien Sie pro Replikationstyp erhalten, und wann Sie den jeweiligen Typ verwenden sollten.

Replikationstyp Exemplare Anwendungsfall
LRS 3 Daten sind hochverfügbar, sie müssen aus Compliancegründen jedoch im lokalen Rechenzentrum verbleiben.
GRS 6 Apps haben Zugriff auf die Daten, selbst wenn eine gesamte Region ausfällt.
RA-GRS 6 Apps können Lesevorgänge für mehrere geografische Standorte durchführen. Sie können die Daten für Benutzer also über einen Standort verfügbar machen, der sich jeweils in deren Nähe befindet.
ZRS 3 Dieser Typ eignet sich, wenn Sie Redundanz an mehreren physischen Standorten benötigen, die Daten aus Compliancegründen jedoch eine Region nicht verlassen dürfen.
GZRS 6 Die App kann selbst dann auf Daten zugreifen, wenn die primäre Region und das Rechenzentrum Ihrer sekundären Region ausgefallen sind, aber Sie nur bei einem Ausfall der primären Region aus der sekundären Region lesen möchten.
RA-GZRS 6 Dieser Typ eignet sich, wenn Sie regelmäßig Lesevorgänge für die Daten in der sekundären Region durchführen möchten, beispielsweise um die Daten für Benutzer über einen für sie näheren Standort verfügbar zu machen. Dies ist möglich, auch wenn in Ihrer primären Region ein Rechenzentrum aktiv ist.

Wechseln zwischen Replikationsstrategien

Sie können die Replikationsstrategie für Speicherkonten ändern. Der dafür erforderliche Prozess hängt von der aktuellen Replikationsstrategie für Ihr Konto ab. Wenn Sie z. B. eine Migration von einem Speicherkonto mit LRS durchführen möchten, haben Sie zwei Möglichkeiten:

  • Verschieben oder kopieren Sie Ihre Daten manuell in ein neues Konto mit GZRS.
  • Ändern Sie den Replikationstyp zunächst in „GRS/RA-GRS“, und richten Sie dann eine Anfrage an den Azure-Support, um eine Livemigration zu GZRS durchzuführen.

Konvertieren eines Kontos

Wenn Sie ein ZRS-Konto verwenden, können Sie es so konvertieren, dass GZRS verwendet wird. Das Konvertieren eines Kontos erfolgt über das Azure-Portal, die Azure CLI oder über Azure PowerShell.

Verwenden Sie beispielsweise den folgenden Befehl, um Ihr Konto mithilfe von Azure PowerShell in GZRS zu konvertieren:

Set-AzStorageAccount -ResourceGroupName <resource-group> -AccountName <storage-account> -SkuName "Standard_GZRS"

Wechseln des Replikationstyps im Azure-Portal

Sie können den Replikationstyp Ihres Kontos auch im Azure-Portal wechseln. Beispiel: Um von ZRS zu GZRS zu wechseln, navigieren Sie zu Ihrem Speicherkonto, wählen Sie Redundanz aus, und ändern Sie den Replikationstyp.

Screenshot of the storage account configuration, where you can change the replication type from ZRS to GZRS.

Livemigration

Sie können auch eine Livemigration verwenden, um Ihre Daten in ein Konto zu migrieren, für das ZRS, GZRS oder RA-GZRS genutzt wird. Livemigrationen eignen sich, wenn Downtime oder Datenverluste vermieden werden sollen. Die Dauer Ihrer Livemigration hängt im Allgemeinen von der Menge der Daten in Ihrem Konto ab.

Richten Sie für eine Livemigration eine entsprechend Anfrage an den Azure-Support im Azure-Portal.

Screenshot of an example Azure support ticket where you can request the service: storage account management, problem type: data migration, and problem subtype: migrate to ZRS, GRS, or RA-GZRS.

Sie werden dann von einem Supportmitarbeiter zur Livemigrationsanfrage kontaktiert.

Es gibt jedoch einige Einschränkungen für Livemigrationen. Beispiel:

  • Anders als bei einer manuellen App wissen Sie nicht genau, wann eine Livemigration abgeschlossen ist.
  • Daten können nur in dieselbe Region migriert werden.
  • Livemigration wird nur für Daten unterstützt, die in Standardspeicherkontotypen gespeichert sind.
  • Wenn Ihr Konto eine große Dateifreigabe enthält, wird die Livemigration zu GZRS nicht unterstützt.

Manuelle Migration

Manuelle Migration ist flexibler als Livemigration. Wenn Sie beispielsweise die zeitliche Planung kontrollieren möchten, können Sie eine manuelle Migration verwenden, wenn sie zu einem bestimmten Datum abgeschlossen sein muss.

Für eine manuelle Migration könnten Sie das AzCopy-Hilfsprogramm oder eines der zahlreichen verfügbaren Drittanbietertools verwenden.

Mithilfe von AzCopy können Sie beispielsweise den folgenden Befehl in Ihrem Terminal ausführen, durch den alle Blobs, Verzeichnisse und Container in Ihrem Speicherkonto in ein anderes kopiert werden.

azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/?<your-SAS-token>'
'https://<destination-storage-account-name>.blob.core.windows.net/' --recursive