Storage braucht Zonen- oder Regionsresilienz? ZRS und GRS vergleichen und konfigurieren

Veröffentlicht am:

Bei einem Zonenausfall soll die Anwendung weiterlaufen; bei einem Regionsausfall braucht sie eine Kopie an einem anderen Standort. Azure Storage bietet dafür unterschiedliche Replikationsoptionen.

Option Speicherorte der Kopien Verhalten bei Ausfällen
ZRS — Zone-redundant storage Synchrone Kopien über Verfügbarkeitszonen einer Region Storage bleibt bei einem Zonenausfall verfügbar.
GRS — Geo-redundant storage Lokale Kopien in der primären Region, asynchron in eine sekundäre Region kopiert Regionale Wiederherstellung erfolgt per Account-Failover; aktuelle Schreibvorgänge können verloren gehen.

GZRS kombiniert Zonenredundanz mit einer regionalen Kopie. RA-GRS erlaubt vor dem Failover Lesezugriffe auf den sekundären Endpunkt; dessen Daten können verzögert sein.

Zwei Storage Accounts erstellen

Öffne im Azure-Portal Storage accounts → Create. Verwende für beide Accounts:

Resource group: rg-cloudtrips-redundancy-test-weu
Region: West Europe
Performance: Standard
ZRS account name: stctzrsdmytrotestweu
GRS account name: stctgrsdmytrotestweu

Wähle weltweit eindeutige Namen aus Kleinbuchstaben und Zahlen. Erstelle den ersten Account mit Redundancy: ZRS, den zweiten mit Redundancy: GRS. Lasse bei GRS den sekundären Lesezugriff deaktiviert. Der hierarchische Namespace bleibt für dieses Lab deaktiviert.

Zonenredundanz prüfen

Öffne den ZRS-Account und Data management → Redundancy.

Redundancy-Seite des ZRS-Accounts mit zonenredundantem Speicher in der primären Region

Prüfe die Einstellung ZRS. Azure verwaltet die Kopien über mehrere Zonen; die Anwendung verwendet bei einem Zonenausfall weiterhin denselben Account-Endpunkt.

Georedundanz prüfen

Öffne die Redundancy-Seite des GRS-Accounts und suche die primäre und sekundäre Region.

Redundancy-Seite des GRS-Accounts mit primärer und sekundärer Region sowie Replikationsstatus

Prüfe die Einstellung GRS und die von Azure zugewiesene sekundäre Region. Georeplikation erfolgt asynchron: Ein bestätigter Schreibvorgang kann noch auf die Übertragung warten. Ein ungeplantes Failover macht die sekundäre Kopie zur primären; aktuelle Schreibvorgänge können dabei verloren gehen. Bei regulärem GRS wird diese Kopie nach dem Failover für Anwendungen zugänglich. RA-GRS (Read-Access GRS) erlaubt der Anwendung auch vor dem Failover Lesezugriffe auf die sekundäre Kopie über einen separaten Endpunkt. Schreibzugriffe gehen weiterhin an die primäre Region; sekundäre Lesezugriffe können ältere Daten liefern. So kann eine für den sekundären Endpunkt konfigurierte Anwendung bei einem Ausfall der primären Region weiterhin etwa einen Produktkatalog anzeigen, während sie auf das Failover wartet.

Diese Seiten bestätigen die Konfiguration; ein Ausfalltest wäre eine separate Übung.

Bereinigen

Öffne Resource groups → rg-cloudtrips-redundancy-test-weu → Delete resource group, bestätige den Namen und lösche die Gruppe. Prüfe, dass sie aus der Liste verschwindet.