Blobs müssen in einen anderen Account repliziert werden? Change Feed und Object Replication konfigurieren

CloudTrips benötigt automatische Kopien ausgewählter Blobs in einem zweiten Storage Account in einer anderen Region. Azure Object Replication liest den Change Feed des Quellaccounts und kopiert passende Block Blobs, Versionen, Metadaten und Eigenschaften asynchron in einen Zielcontainer.

Quellaccount in West Europe
  └─ Container source-data
       └─ Change Feed protokolliert Blob-Schreibvorgänge
            └─ Object-Replication-Policy
                 └─ Container replica-data in North Europe

Dies ist eine von CloudTrips konfigurierte, einseitige Replikation auf Objektebene. Sie unterscheidet sich von GRS, bei dem Azure den ganzen Account in eine fest zugeordnete Region für serviceverwaltete Disaster Recovery repliziert.

Quellaccount erstellen

Suche nach Storage accounts, wähle Create und trage ein:

Subscription: CloudTrips TEST
Resource group: Create new → rg-cloudtrips-blob-replication-test-weu
Storage account name: stctreplsrcdmytrotest
Region: West Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)

Lasse Hierarchical namespace deaktiviert. Object Replication wird für GPv2- oder Premium-Block-Blob-Accounts unterstützt, funktioniert mit Block Blobs und unterstützt keine Accounts mit hierarchischem Namespace. Erstelle den Account.

Zielaccount erstellen

Erstelle einen weiteren Storage Account in derselben Ressourcengruppe:

Storage account name: stctrepldstdmytrotest
Region: North Europe
Performance: Standard
Redundancy: Locally-redundant storage (LRS)
Hierarchical namespace: Disabled

Beide Accounts befinden sich in demselben Abonnement und Microsoft-Entra-Tenant. Lasse mandantenübergreifende Replikation deaktiviert; sie ist für dieses Lab nicht erforderlich und verringert das Risiko, Daten in einen externen Tenant zu kopieren.

Voraussetzungen der Quelle aktivieren

Öffne stctreplsrcdmytrotest und wähle Data management > Data protection. Aktiviere und speichere:

Enable versioning for blobs: Enabled
Enable blob change feed: Enabled

Der Change Feed ist ein geordnetes, dauerhaftes und schreibgeschütztes Protokoll von Blob- und Metadatenänderungen. Object Replication liest dieses Protokoll, um anstehende Arbeit zu erkennen; es ist nicht selbst die Zielkopie. Change Records werden normalerweise innerhalb einiger Minuten statt als Echtzeit-Eventstream verfügbar.

Versionierung am Ziel aktivieren

Öffne stctrepldstdmytrotest und wähle Data management > Data protection. Aktiviere und speichere:

Enable versioning for blobs: Enabled

Versionierung ist auf beiden Accounts erforderlich, weil Object Replication Blobversionen kopiert und den replizierten Zustand am Ziel unabhängig verfolgt.

Containerpaar erstellen

Erstelle unter Data storage > Containers private Container:

Quellaccount: source-data
Zielaccount:  replica-data
Anonymous access: Private (no anonymous access)

Jede Replikationsregel ordnet genau einen Quellcontainer einem Zielcontainer zu. Der vorher erstellte Zielcontainer verhindert, dass die Policy auf ein fehlendes Ziel verweist.

Object-Replication-Regel erstellen

Wähle im Quellaccount Data management > Object replication > Create replication rules und dann:

Destination subscription: CloudTrips TEST
Destination storage account: stctrepldstdmytrotest
Source container: source-data
Destination container: replica-data

Lasse den Präfixfilter leer, damit jedes Block Blob in source-data berechtigt ist. Erstelle die Regel. Wird sie im Portal vom Quellaccount aus konfiguriert, erstellt Azure automatisch die passende Policy am Zielaccount. Auf beiden Seiten müssen dieselben Policy- und Rule-IDs vorhanden sein.

Object Replication arbeitet asynchron. Die Accounts sind nicht sofort identisch, und der Standardmodus besitzt keine garantierte Abschlusszeit. Nutze ihn nicht als synchrone Schreibbestätigung.

Neues Quell-Blob hochladen

Erstelle nach Aktivierung der Replikationsregel eine lokale Datei:

printf 'CloudTrips replicated object\n' > cloudtrips-replication-test.txt

Öffne den Container source-data des Quellaccounts und lade die Datei als Block Blob hoch. Der Upload nach der Policy-Erstellung macht den Test unabhängig von Optionen für Objekte, die schon vor der Regel existierten.

Öffne die Eigenschaften des Quell-Blobs und prüfe Object replication oder Replication status. Der Status kann zunächst Pending und später Complete anzeigen.

Zielkopie prüfen

Öffne im Zielaccount den Container replica-data und aktualisiere, bis cloudtrips-replication-test.txt erscheint. Öffne oder lade die Datei herunter und bestätige:

CloudTrips replicated object

Erscheint das Blob nicht sofort, warte einige Minuten und aktualisiere. Prüfe, dass Versionierung auf beiden Accounts und Change Feed an der Quelle aktiv sind, beide Container existieren und das Quellobjekt ein Block Blob außerhalb des Archive-Tiers ist.

Die Replikation ist einseitig: Änderungen am Ziel werden nicht zur Quelle zurückkopiert. Object Replication bietet außerdem kein Anwendungs-Failover, DNS-Umschalten oder Konfliktlösung; Clients müssen den passenden Account gezielt lesen.

Bereinigen

Lösche die Replikations-Policy vor einem der Accounts, damit die Beziehung sauber entfernt wird. Öffne im Quellaccount Object replication, wähle die Policy und lösche sie. Lösche danach die eigenständige Ressourcengruppe:

az group delete \
  --name rg-cloudtrips-blob-replication-test-weu \
  --yes

Prüfe, ob sie entfernt wurde:

az group exists --name rg-cloudtrips-blob-replication-test-weu

Erwartetes Ergebnis: false.