Objektreplikation für Blockblobs

Die Objektreplikation kopiert Blockblobs asynchron zwischen einem Quellspeicherkonto und einem Zielkonto. Folgende Szenarien werden unter anderem von der Objektreplikation unterstützt:

• Minimieren der Wartezeit. Die Objektreplikation kann die Wartezeit für Leseanforderungen verringern, indem Clients die Nutzung von Daten aus einer Region ermöglicht wird, die sich in größerer physischer Nähe befindet.
• Erhöhen der Effizienz für Computeworkloads: Bei der Objektreplikation können Computeworkloads dieselben Sätze von Blockblobs in verschiedenen Regionen verarbeiten.
• Optimieren der Datenverteilung. Sie können Daten an einem einzigen Standort verarbeiten bzw. analysieren und dann nur die Ergebnisse in zusätzliche Regionen replizieren.
• Optimieren der Kosten. Nachdem Ihre Daten repliziert wurden, können Sie die Kosten senken, indem Sie sie mithilfe von Lebenszyklus-Verwaltungsrichtlinien auf die Archivebene verschieben.

Das folgende Diagramm zeigt, wie die Objektreplikation Blockblobs aus einem Quellspeicherkonto in einer Region in Zielkonten in zwei verschiedenen Regionen repliziert.

Informationen zum Konfigurieren der Objektreplikation finden Sie unter Konfigurieren der Objektreplikation.

Voraussetzungen und Vorbehalte für die Objektreplikation

Die Objektreplikation erfordert, dass außerdem die folgenden Azure Storage-Funktionen aktiviert sind:

• Änderungsfeed: Muss für das Quellkonto aktiviert sein. Informationen zum Aktivieren des Änderungsfeeds finden Sie unter Aktivieren und Deaktivieren des Änderungsfeeds.
• Blobversionsverwaltung: Muss für das Quell- und das Zielkonto aktiviert sein. Informationen zum Aktivieren der Versionsverwaltung finden Sie unter Aktivieren und Verwalten der Blobversionsverwaltung.

Durch das Aktivieren des Änderungsfeeds und der Blobversionsverwaltung können zusätzliche Kosten entstehen. Weitere Informationen finden Sie auf der Seite Azure Storage – Preise.

Die Objektreplikation wird für Speicherkonten vom Typ „Universell V2“ und für Blockblobkonten vom Typ „Premium“ unterstützt. Sowohl Quell- als auch Zielkonten müssen Blockblobkonten des Typs „Universell V2“ oder „Premium“ sein. Die Objektreplikation unterstützt nur Blockblobs. Anfügeblobs und Seitenblobs werden nicht unterstützt.

Die Objektreplikation wird für Konten unterstützt, die mit entweder von Microsoft oder kundenseitig verwalteten Schlüsseln verschlüsselt sind. Weitere Informationen zu kundenseitig verwalteten Schlüsseln finden Sie unter Verwendung von kundenseitig verwalteten Schlüsseln für die Azure Storage-Verschlüsselung.

Die Objektreplikation wird für Blobs im Quellkonto, die mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt sind, nicht unterstützt. Weitere Informationen zu vom Kunden bereitgestellten Schlüsseln finden Sie unter Angeben eines Verschlüsselungsschlüssels bei Stellen einer Anforderung für Blob Storage.

Ein vom Kunden verwalteter Failover wird weder für das Quell- noch für das Zielkonto in einer Objektreplikationsrichtlinie unterstützt.

Die Objektreplikation wird für Blobs, die mithilfe der Data Lake Storage-APIs hochgeladen werden, nicht unterstützt.

Funktionsweise der Objektreplikation

Bei der Objektreplikation werden Blockblobs in einem Container entsprechend den von Ihnen konfigurierten Regeln asynchron kopiert. Der Inhalt des Blobs, alle dem Blob zugeordneten Versionen sowie die Metadaten und Eigenschaften des Blobs werden aus dem Quellcontainer in den Zielcontainer kopiert.

Blobversionsverwaltung

Die Objektreplikation erfordert, dass die Blobversionsverwaltung sowohl für das Quell- als auch das Zielkonto aktiviert ist. Wenn ein repliziertes Blob im Quellkonto geändert wird, wird vor der Änderung eine neue Blobversion im Quellkonto erstellt, die den vorherigen Zustand des Blobs widerspiegelt. Die aktuelle Version im Quellkonto spiegelt die neuesten Updates wider. Sowohl die aktuelle Version als auch vorherige Versionen werden in das Zielkonto repliziert. Weitere Informationen zur Auswirkung von Schreibvorgängen auf Blobversionen finden Sie unter Versionsverwaltung für Schreibvorgänge.

Wenn für Ihr Speicherkonto Objektreplikationsrichtlinien wirksam sind, können Sie die Blobversionsverwaltung für dieses Konto nicht deaktivieren. Sie müssen alle Objektreplikationsrichtlinien für das Konto löschen, bevor Sie die Blobversionsverwaltung deaktivieren.

Löschen eines Blobs im Quellkonto

Wenn ein Blob im Quellkonto gelöscht wird, wird die aktuelle Version des Blobs zu einer früheren Version, und es gibt keine aktuelle Version mehr. Alle vorhandenen vorherigen Versionen des Blobs bleiben erhalten. Dieser Status wird in das Zielkonto repliziert. Weitere Informationen zur Auswirkung von Löschvorgängen auf Blobversionen finden Sie unter Versionsverwaltung für Löschvorgänge.

Momentaufnahmen

Die Objektreplikation unterstützt keine Blobmomentaufnahmen. Beliebige Momentaufnahmen für ein Blob im Quellkonto werden nicht in das Zielkonto repliziert.

Blobindextags

Die Objektreplikation kopiert die Indextags des Quellblobs nicht in das Zielblob.

Blobtiering

Die Objektreplikation wird unterstützt, wenn sich das Quell- und das Zielkonto in der Ebene „Heiß“ oder „Kalt“ befinden. Quell- und Zielkonten befinden sich möglicherweise in unterschiedlichen Ebenen. Die Objektreplikation schlägt jedoch ein fehl, wenn ein Blob im Quell- oder Zielkonto in die Archivzugriffsebene verschoben wurde. Weitere Informationen zu Blobebenen finden Sie unter Zugriffsebenen für Blobdaten.

Unveränderliche Blobs

Unveränderlichkeitsrichtlinien für Azure Blob Storage umfassen zeitbasierte Aufbewahrungsrichtlinien und Aufbewahrungrichtlinien für juristische Zwecke. Wenn eine Unveränderlichkeitsrichtlinie für das Zielkonto wirksam ist, kann die Objektreplikation betroffen sein. Weitere Informationen zu Unveränderlichkeitsrichtlinien finden Sie unter Speichern unternehmenskritischer Blobdaten mit unveränderlichem Speicher.

Wenn eine Unveränderlichkeitsrichtlinie auf Containerebene für einen Container im Zielkonto in Kraft ist und ein Objekt im Quellcontainer aktualisiert oder gelöscht wird, kann der Vorgang für den Quellcontainer erfolgreich sein, aber die Replikation dieses Vorgangs in den Zielcontainer ist nicht erfolgreich. Weitere Informationen dazu, welche Vorgänge mit einer Unveränderlichkeitsrichtlinie, die einem Container zugeordnet ist, nicht zulässig sind, finden Sie unter Szenarien mit Bereich auf Containerebene.

Wenn eine Unveränderlichkeitsrichtlinie auf Versionsebene für eine Blobversion im Zielkonto in Kraft ist und ein Lösch- oder Aktualisierungsvorgang für die Blobversion im Quellcontainer ausgeführt wird, kann der Vorgang für das Quellobjekt erfolgreich sein, aber die Replikation dieses Vorgangs in das Zielobjekt ist nicht erfolgreich. Weitere Informationen dazu, welche Vorgänge mit einer Unveränderlichkeitsrichtlinie, die einem Container zugeordnet ist, nicht zulässig sind, finden Sie unter Szenarien mit Bereich auf Versionsebene.

Objektreplikationsrichtlinien und -regeln

Wenn Sie die Objektreplikation konfigurieren, erstellen Sie eine Replikationsrichtlinie, in der das Quellspeicherkonto und das Zielkonto angegeben werden. Eine Replikationsrichtlinie enthält mindestens eine Regel, die einen Quellcontainer und einen Zielcontainer angibt sowie anzeigt, welche Blockblobs im Quellcontainer repliziert werden.

Nachdem Sie die Objektreplikation konfiguriert haben, überprüft Azure Storage den Änderungsfeed für das Quellkonto regelmäßig und repliziert asynchron alle Schreib- oder Löschvorgänge in das Zielkonto. Die Replikationswartezeit hängt von der Größe des Blockblobs ab, das repliziert wird.

Replikationsrichtlinien

Wenn Sie die Objektreplikation konfigurieren, wird über den Azure Storage-Ressourcenanbieter eine Replikationsrichtlinie für das Zielkonto erstellt. Nachdem die Replikationsrichtlinie erstellt wurde, weist Azure Storage ihr eine Richtlinien-ID zu. Anschließend müssen Sie diese Replikationsrichtlinie dem Quellkonto mithilfe der Richtlinien-ID zuordnen. Die Richtlinien-ID muss für das Quell- und das Zielkonto identisch sein, damit die Replikation stattfinden kann.

Ein Quellkonto kann in maximal zwei Zielkonten repliziert werden, mit einer einzigen Richtlinie für jedes Zielkonto. Ebenso kann ein Konto als Zielkonto für maximal zwei Replikationsrichtlinien dienen.

Die Quell- und Zielkonten dürfen sich in derselben oder in unterschiedlichen Regionen befinden. Sie können sich auch in demselben oder in unterschiedlichen Abonnements befinden. Optional können die Quell- und Zielkonten in unterschiedlichen Microsoft Entra enthalten sein. Für jedes Paar aus Quell- und Zielkonto darf nur eine Replikationsrichtlinie erstellt werden.

Replikationsregeln

Replikationsregeln geben an, wie Azure Storage Blobs aus einem Quellcontainer in einen Zielcontainer repliziert. Sie können für jede Replikationsrichtlinie bis zu 1000 Replikationsregeln angeben. Jede Replikationsregel definiert einen einzelnen Quell- und Zielcontainer, und jeder Quell- und Zielcontainer kann nur in einer Regel verwendet werden. Dies bedeutet, dass maximal 1000 Quellcontainer und 1000 Zielcontainer an einer einzelnen Replikationsrichtlinie teilnehmen können.

Beim Erstellen einer Replikationsregel werden standardmäßig nur neue Blockblobs kopiert, die anschließend dem Quellcontainer hinzugefügt werden. Sie können angeben, dass sowohl neue als auch vorhandene Blockblobs kopiert werden, oder Sie können einen benutzerdefinierten Kopierumfang definieren, der Blockblobs kopiert, die ab einem bestimmten Zeitpunkt erstellt wurden.

Sie können ferner einen oder mehrere Filter als Teil einer Replikationsregel angeben, um Blockblobs anhand eines Präfixes zu filtern. Wenn Sie ein Präfix angeben, werden nur Blobs in den Zielcontainer kopiert, die mit diesem Präfix im Quellcontainer übereinstimmen.

Die Quell- und Zielcontainer müssen beide vorhanden sein, bevor Sie sie in einer Regel angeben können. Nachdem Sie die Replikationsrichtlinie erstellt haben, sind Schreibvorgänge im Zielcontainer nicht zulässig. Alle Versuche, in den Zielcontainer zu schreiben, schlagen mit dem Fehlercode 409 (Konflikt) fehl. Wenn Sie in einen Zielcontainer schreiben möchten, für den eine Replikationsregel konfiguriert ist, müssen Sie entweder die für diesen Container konfigurierte Regel löschen oder die Replikationsrichtlinie entfernen. Lese- und Löschvorgänge im Zielcontainer sind zulässig, wenn die Replikationsrichtlinie aktiv ist.

Sie können den Vorgang Blobebene festlegen für einen Blob im Zielcontainer aufrufen, um ihn auf die Archivebene zu verschieben. Weitere Informationen zur Archivebene finden Sie unter Archivzugriffsebene für Blobdaten.

Richtliniendefinitionsdatei

Eine Objektreplikationsrichtlinie wird durch eine JSON-Datei definiert. Sie können die Richtliniendefinitionsdatei aus einer vorhandenen Objektreplikationsrichtlinie abrufen. Sie können auch eine Objektreplikationsrichtlinie erstellen, indem Sie eine Richtliniendefinitionsdatei hochladen.

Beispiel für eine Richtliniendefinitionsdatei

Im folgenden Beispiel wird eine Replikationsrichtlinie für das Zielkonto mit einer einzigen Regel definiert, die eine Übereinstimmung mit dem Präfix b sucht und die Mindesterstellungszeit für Blobs festlegt, die repliziert werden sollen. Denken Sie daran, die Werte in eckigen Klammern durch Ihre eigenen Werte zu ersetzen:

{
  "properties": {
    "policyId": "default",
    "sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-028T00:00:00Z"
        }
      }
    ]
  }
}

Angeben vollständiger Ressourcen-IDs für das Quell- und das Zielkonto

Geben Sie beim Erstellen der Richtliniendefinitionsdatei die vollständigen Azure Resource Manager-Ressourcen-IDs für die Einträge sourceAccount und destinationAccount an, wie im Beispiel im vorherigen Abschnitt gezeigt. Informationen zum Ermitteln der Ressourcen-ID für ein Speicherkonto finden Sie unter Abrufen der Ressourcen-ID für ein Speicherkonto.

Die vollständige Ressourcen-ID weist folgendes Format auf:

/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>

Die Richtliniendefinitionsdatei erforderte zuvor nur den Kontonamen anstelle der vollständigen Ressourcen-ID für das Speicherkonto. Mit der Einführung der Sicherheitseigenschaft AllowCrossTenantReplication in Version 2021-02-01 der REST-API des Azure Storage-Ressourcenanbieters müssen Sie jetzt die vollständige Ressourcen-ID für alle Objektreplikationsrichtlinien bereitstellen, die erstellt werden, solange die mandantenübergreifende Replikation für ein von der Replikationsrichtlinie betroffenes Speicherkonto nicht zulässig ist. Azure Storage verwendet die vollständige Ressourcen-ID, um zu überprüfen, ob sich das Quell- und das Zielkonto innerhalb desselben Mandanten befinden. Weitere Informationen zum Verhindern von Richtlinien für die mandantenübergreifende Replikation finden Sie unter Verhindern der Replikation zwischen Microsoft Entra-Mandanten.

Die Angabe des Kontonamens wird weiterhin unterstützt, wenn die mandantenübergreifende Replikation für ein Speicherkonto zulässig ist. Als bewährte Methode empfiehlt Microsoft jedoch, immer die vollständige Ressourcen-ID anzugeben. Alle früheren Versionen der REST-API des Azure Storage-Ressourcenanbieters unterstützen die Verwendung des vollständigen Ressourcen-ID-Pfads in Objektreplikationsrichtlinien.

In der folgenden Tabelle wird beschrieben, was geschieht, wenn Sie eine Replikationsrichtlinie unter Angabe der vollständigen Ressourcen-ID im Vergleich zum Kontonamen in Szenarien erstellen, in denen die mandantenübergreifende Replikation für das Speicherkonto zulässig oder nicht zulässig ist.

Angeben der Richtlinien- und Regel-IDs

In der folgenden Tabelle sind die Werte zusammengefasst, die in den einzelnen Szenarien in der Richtliniendefinitionsdatei für policyId und ruleId verwendet werden müssen.

Verhindern der Replikation über Microsoft Entra-Mandanten hinweg

Ein Microsoft Entra-Mandant (Azure AD) ist eine dedizierte Microsoft Entra ID-Instanz, die eine Organisation für die Identitäts- und Zugriffsverwaltung darstellt. Jedes Azure-Abonnement verfügt über eine Vertrauensbeziehung zu einem einzelnen Microsoft Entra-Mandanten. Alle Ressourcen in einem Abonnement, einschließlich Speicherkonten, sind demselben Microsoft Entra-Mandanten zugeordnet. Weitere Informationen finden Sie unter Was ist Microsoft Entra ID?

Die mandantenübergreifende Replikation ist für neue Konten, die ab dem 15. Dezember 2023 erstellt werden, standardmäßig deaktiviert. Wenn Ihre Sicherheitsrichtlinien erfordern, dass Sie die Objektreplikation auf Speicherkonten innerhalb desselben Mandanten beschränken, können Sie die mandantenübergreifende Replikation verhindern, indem Sie die Sicherheitseigenschaft AllowCrossTenantReplication (Vorschau) festlegen. Wenn Sie die mandantenübergreifende Objektreplikation für ein Speicherkonto deaktivieren, erfordert Azure Storage für jede Objektreplikationsrichtlinie, die mit diesem Speicherkonto als Quell- oder Zielkonto konfiguriert ist, dass sich sowohl das Quell- als auch das Zielkonto in demselben Microsoft Entra-Mandanten befinden. Weitere Informationen zum Verhindern der mandantenübergreifenden Objektreplikation finden Sie unter Verhindern der Objektreplikation zwischen Microsoft Entra-Mandanten.

Um die mandantenübergreifende Objektreplikation für ein Speicherkonto zu verhindern, legen Sie die Eigenschaft AllowCrossTenantReplication auf false fest. Wenn für das Speicherkonto derzeit keine Richtlinien für die mandantenübergreifende Objektreplikation gelten, verhindert das Festlegen der Eigenschaft AllowCrossTenantReplication auf false die zukünftige Konfiguration von Richtlinien für die mandantenübergreifende Objektreplikation, bei denen dieses Speicherkonto als Quelle oder Ziel verwendet wird.

Wenn das Speicherkonto derzeit an mindestens einer Richtlinie für die mandantenübergreifende Objektreplikation beteiligt ist, kann die Eigenschaft AllowCrossTenantReplication nicht auf false festgelegt werden. Sie müssen die vorhandenen mandantenübergreifenden Richtlinien löschen, bevor Sie die mandantenübergreifende Replikation unterbinden können.

Standardmäßig ist die AllowCrossTenantReplication-Eigenschaft für Speicherkonten, die ab dem 15. Dezember 2023 erstellt werden, standardmäßig auf „false“ festgelegt. Für Speicherkonten, die vor dem 15. Dezember 2023 erstellt wurden, gilt Folgendes: Wenn der Wert der Eigenschaft AllowCrossTenantReplication für ein Speicherkonto null oder true lautet, können autorisierte Benutzer*innen Richtlinien zur mandantenübergreifenden Objektreplikation mit diesem Konto als Quelle oder Ziel konfigurieren. Weitere Informationen zum Konfigurieren mandantenübergreifender Richtlinien finden Sie unter Konfigurieren der Objektreplikation für Blockblobs.

Mithilfe von Azure Policy können Sie eine Gruppe von Speicherkonten überwachen, um sicherzustellen, dass die Eigenschaft AllowCrossTenantReplication festgelegt ist und die mandantenübergreifende Objektreplikation verhindert wird. Sie können Azure Policy auch zum Erzwingen von Governance für eine Gruppe von Speicherkonten verwenden. Beispielsweise können Sie eine Richtlinie mit der Auswirkung „Deny“ erstellen, um einen Benutzer am Erstellen eines Speicherkontos zu hindern, für das die Eigenschaft AllowCrossTenantReplication auf true festgelegt ist. Ebenso können Sie damit verhindern, dass ein Benutzer ein vorhandenes Speicherkonto ändert, indem er dessen Eigenschaftswert auf true festlegt.

Replikationsstatus

Sie können den Replikationsstatus für ein Blob im Quellkonto überprüfen. Weitere Informationen finden Sie unter Überprüfen des Replikationsstatus eines Blobs.

Wenn der Replikationsstatus für ein Blob im Quellkonto auf einen Fehler hinweist, untersuchen Sie die folgenden möglichen Ursachen:

• Stellen Sie sicher, dass die Objektreplikationsrichtlinie im Zielkonto konfiguriert ist.
• Überprüfen Sie, ob das Zielkonto noch existiert.
• Überprüfen Sie, ob der Zielcontainer noch vorhanden ist.
• Vergewissern Sie sich, dass der Zielcontainer nicht gerade gelöscht wird oder wurde. Das Löschen eines Containers kann bis zu 30 Sekunden dauern.
• Überprüfen Sie, ob der Zielcontainer weiterhin an der Richtlinie für die Objektreplikation teilnimmt.
• Wenn das Quellblob im Rahmen eines Schreibvorgangs mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt wurde, tritt bei der Objektreplikation ein Fehler auf. Weitere Informationen zu vom Kunden bereitgestellten Schlüsseln finden Sie unter Angeben eines Verschlüsselungsschlüssels bei Stellen einer Anforderung für Blob Storage.
• Überprüfen Sie, ob das Quell- oder Zielblob auf die Archivebene verschoben wurde. Archivierte Blobs können nicht über die Objektreplikation repliziert werden. Weitere Informationen zur Archivebene finden Sie unter Archivzugriffsebene für Blobdaten.
• Stellen Sie sicher, dass der Zielcontainer oder das Zielblob nicht durch eine Unveränderlichkeitsrichtlinie geschützt ist. Denken Sie daran, dass ein Container oder Blob eine Unveränderlichkeitsrichtlinie von seinem übergeordneten Element erben kann. Weitere Informationen zu Unveränderlichkeitsrichtlinien finden Sie in der Übersicht über unveränderliche Speicher für Blobdaten.

Featureunterstützung

Die Unterstützung für dieses Features kann durch die Aktivierung von Data Lake Storage Gen2, dem Network File System (NFS) 3.0-Protokoll oder dem SSH File Transfer Protocol (SFTP) beeinträchtigt werden. Wenn Sie eine dieser Funktionen aktiviert haben, lesen Sie bitte den Abschnitt Unterstützung der Blob Storage-Funktion in Azure Storage-Konten, um die Unterstützung für dieses Features zu bewerten.

Abrechnung

Für die Konfiguration der Objektreplikation fallen keine Kosten an. Dies umfasst die Aufgabe zur Aktivierung des Änderungsfeeds, zur Aktivierung der Versionsverwaltung und zum Hinzufügen der Replikationsrichtlinien. Die Objektreplikation verursacht jedoch Kosten für Lese- und Schreibtransaktionen in den Quell- und Zielkonten sowie Gebühren für ausgehenden Datenverkehr für die Replikation von Daten aus dem Quellkonto in das Zielkonto und Lesegebühren für den Prozessänderungsfeed.

Hier sehen Sie eine Aufschlüsselung der Kosten. Informationen zum Preis der einzelnen Kostenkomponenten finden Sie unter Preise für Azure Blob Storage.

¹ Wenn Sie die Ebene eines Blobs oder einer Version auf dem Quellkonto nicht geändert haben, werden Ihnen die eindeutigen Datenblöcke in diesem Blob und seinen Versionen in Rechnung gestellt. Siehe Preise und Abrechnung für Blobversionsverwaltung. Auf dem Zielkonto für eine Version werden Ihnen alle Blöcke einer Version in Rechnung gestellt, unabhängig davon, ob diese Blöcke eindeutig sind.

² Dies umfasst nur Blobversionen, die seit Abschluss der letzten Replikation erstellt wurden.

³ Die Objektreplikation kopiert die gesamte Version in das Ziel (nicht nur die eindeutigen Blöcke der Version). Diese Übertragung verursacht Kosten für den Netzwerkausgang. Weitere Informationen finden Sie unter Bandbreite – Preise.

Nächste Schritte

• Konfigurieren der Objektreplikation
• Verhindern der Objektreplikation über Microsoft Entra-Mandanten hinweg
• Blobversionsverwaltung
• Unterstützung für Änderungsfeeds in Azure Blob Storage