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 Latenz. 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 einzelnen Ort verarbeiten oder analysieren und dann nur die Ergebnisse in zusätzliche Regionen replizieren.
• Optimieren der Kosten. Nachdem Ihre Daten repliziert wurden, können Sie die Kosten reduzieren, indem Sie sie mithilfe von Lebenszyklusverwaltungsrichtlinien in 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.

Das Aktivieren von Änderungsfeeds und blob-Versionsverwaltung kann zusätzliche Kosten verursachen. 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 in Konten mit aktiviertem hierarchischen Namespace noch nicht unterstützt.

Die Objektreplikation wird für Blobs, die mithilfe von 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.

Wichtig

Da Block blob-Daten asynchron repliziert werden, werden das Quellkonto und das Zielkonto nicht sofort synchronisiert.

OR unterstützt jetzt die Prioritätsreplikation, die die Replikation aller Vorgänge in einer OR-Richtlinie priorisiert. Wenn die OR-Prioritätsreplikation aktiviert ist, wird die Replikationsleistung aller Vorgänge verbessert. Wenn sich das Quell- und Zielkonto einer Replikationsrichtlinie auf demselben Kontinent befindet, repliziert die OR-Prioritätsreplikation auch 99,0% von Objekten innerhalb von 15 Minuten für unterstützte Workloads. Die Featureleistung wird mit einem Service Level Agreement (SLA) garantiert. Weitere Informationen finden Sie in den SLA-Bedingungen und im Artikel zur Prioritätsreplikation der Objektreplikation.

Sie können auch den Replikationsstatus im Quell-BLOB überprüfen, um zu ermitteln, ob die Replikation abgeschlossen ist. Weitere Informationen finden Sie unter Überprüfen des Replikationsstatus eines Blobs.

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 Ihr Speicherkonto Objektreplikationsrichtlinien in Kraft hat, 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.

Hinweis

Nur Blobs werden an das Ziel kopiert. Die Versions-ID eines Blobs wird nicht kopiert. Nachdem ein Blob am Zielspeicherort platziert wurde, wird eine neue Versions-ID zugewiesen.

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 eines Blobs im Quellkonto werden nicht in das Zielkonto repliziert.

Blobindextags

Die Objektreplikation kopiert die Indextags des Quell-BLOB nicht in das Ziel-BLOB.

Blobtiering

Die Objektreplikation wird unterstützt, wenn sich die Quell- und Zielkonten in einer beliebigen Onlineebene befinden (heiß, kühl oder kalt). Die Quell- und Zielkonten können sich in verschiedenen Ebenen befinden. Die Objektreplikation schlägt jedoch ein fehl, wenn ein Blob im Quell- oder Zielkonto in die Archivzugriffsebene verschoben wird. 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 der Zielcontainer über eine Richtlinie zur Unveränderlichkeit auf Containerebene verfügt, können Änderungen an Objekten im Quellcontainer, z. B. Aktualisierungen oder Löschungen, weiterhin erfolgreich sein. Diese Änderungen können jedoch aufgrund der Unveränderlichkeitseinschränkung möglicherweise nicht in den Zielcontainer repliziert werden. 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 Blob-Version eines Zielkontos über eine aktive Richtlinie für die Unveränderlichkeit auf Versionsebene verfügt, kann ein Lösch- oder Aktualisierungsvorgang, der für die Blob-Version des entsprechenden Quellcontainers ausgeführt wird, erfolgreich sein. Die Replikation dieses Vorgangs auf das Zielobjekt schlägt jedoch fehl. 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 eine oder mehrere Regeln, die einen Quell- und Zielcontainer angeben und angeben, welche Quell-BLOBs 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 nicht mehr als zwei Replikationsrichtlinien dienen.

Die Quell- und Zielkonten befinden sich möglicherweise in derselben Region oder in verschiedenen Regionen. Sie befinden sich möglicherweise auch im selben Abonnement oder in anderen Abonnements. Optional befinden sich die Quell- und Zielkonten möglicherweise in verschiedenen Microsoft Entra-Mandanten. Für jedes Quellkonto-/Zielkontopaar kann nur eine Replikationsrichtlinie erstellt werden.

Replikationsregeln

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

Nachdem Sie eine Replikationsregel erstellt haben, werden vorhandene Blobs ignoriert. Nur neue Block-Blobs, die nach Erstellen der Regel hinzugefügt werden, werden standardmäßig kopiert. Sie können jedoch angeben, dass sowohl neue als auch vorhandene Blockblobs kopiert werden. Sie können auch einen benutzerdefinierten Kopierbereich definieren, der alle block-Blobs kopiert, die nach einer bestimmten Zeit 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, die mit diesem Präfix im Quellcontainer übereinstimmen, in den Zielcontainer kopiert.

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.

Um in einen Zielcontainer mit einer Replikationsregel zu schreiben, müssen Sie zuerst die Replikation deaktivieren. Sie können die Regel deaktivieren, indem Sie sie entweder für diesen Container löschen oder die gesamte 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.

Hinweis

Das Ändern der Zugriffsebene eines Blobs im Quellkonto ändert nicht die Zugriffsebene dieses Blobs im Zielkonto.

Richtliniendefinitionsdatei

Eine JSON-Datei wird verwendet, um eine Objektreplikationsrichtlinie zu definieren. Sie können die Richtliniendefinitionsdatei aus einer vorhandenen Objektreplikationsrichtlinie abrufen oder 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 Regel festgelegt. Die Regel zielt auf Blobs mit dem Präfix b ab und gibt eine minimale Erstellungszeit für die Replikation an. 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"
        }
      }
    ]
  }
}

Geben Sie vollständige Ressourcen-IDs für Quell- und Zielkonten an.

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.

Obwohl die Verwendung nur des Kontonamens für die mandantenübergreifende Replikation weiterhin unterstützt wird, empfiehlt Microsoft die Verwendung der vollständigen Ressourcen-ID als bewährte Methode. Alle früheren Versionen der REST-API des Azure Storage-Ressourcenanbieters unterstützen die Verwendung des vollständigen Ressourcen-ID-Pfads in Objektreplikationsrichtlinien.

Die folgende Tabelle zeigt, wie sich das Verhalten der Replikationsrichtlinie unterscheidet, wenn Sie eine vollständige Ressourcen-ID im Vergleich zu einem Kontonamen verwenden. Der Vergleich hängt davon ab, ob die mandantenübergreifende Replikation für das Speicherkonto zulässig ist.

Speicherkontobezeichner in der Richtliniendefinition	Mandantenübergreifende Replikation zulässig	Mandantenübergreifende Replikation unzulässig
Vollständige Ressourcen-ID	Richtlinien für denselben Mandanten können erstellt werden. Mandantenübergreifende Richtlinien können erstellt werden.	Richtlinien für denselben Mandanten können erstellt werden. Mandantenübergreifende Richtlinien können nicht erstellt werden.
Nur Kontoname	Richtlinien für denselben Mandanten können erstellt werden. Mandantenübergreifende Richtlinien können erstellt werden.	Es können weder Richtlinien für denselben Mandanten noch mandantenübergreifende Richtlinien erstellt werden. Ein Fehler tritt auf, weil Azure Storage nicht verifizieren kann, dass sich Quell- und Zielkonten in demselben Mandanten befinden. Der Fehler weist darauf hin, dass Sie in der Richtliniendefinitionsdatei die vollständige Ressourcen-ID für die Einträge sourceAccount und destinationAccount angeben müssen.

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.

Wenn Sie die Richtliniendefinitionsdatei für dieses Konto erstellen...	Legen Sie die Richtlinien-ID auf diesen Wert fest	Legen Sie die Regel-IDs auf diesen Wert fest
Zielkonto	Zeichenfolgenwert default. Azure Storage erstellt den Richtlinien-ID-Wert für Sie.	Eine leere Zeichenfolge. Azure Storage erstellt die Regel-ID-Werte für Sie.
Quellkonto	Der Wert der Richtlinien-ID, der zurückgegeben wird, wenn Sie die Richtliniendefinitionsdatei für das Zielkonto herunterladen.	Die Werte der Regel-IDs, die zurückgegeben werden, wenn Sie die Richtliniendefinitionsdatei für das Zielkonto herunterladen.

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?

Standardmäßig ist die mandantenübergreifende Replikation für neue Konten deaktiviert, die ab dem 15. Dezember 2023 erstellt wurden. 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, erzwingt Azure Storage eine zusätzliche Anforderung. Für jede Objektreplikationsrichtlinie, die dieses Speicherkonto als Quelle oder Ziel verwendet, müssen beide Konten zum gleichen Microsoft Entra-Mandanten gehören. 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 auf "false" für ein Speicherkonto festgelegt, das ab dem 15. Dezember 2023 erstellt wurde. Für Speicherkonten, die vor dem 15. Dezember 2023 erstellt wurden, wenn der Wert der AllowCrossTenantReplication-Eigenschaft für ein Speicherkonto null oder wahr ist, können autorisierte Benutzer mandantenübergreifende Objektreplikationsrichtlinien 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. Sie können beispielsweise eine Richtlinie mit dem deny Effekt erstellen, um zu verhindern, dass ein Benutzer ein Speicherkonto erstellt, bei dem die AllowCrossTenantReplication-Eigenschaft auf "true" festgelegt ist, oder ein vorhandenes Speicherkonto ändern, um den Eigenschaftswert auf "true" zu ändern.

Replikationsmetriken

Die Objektreplikation unterstützt zwei Metriken, um Ihnen Einblicke in den Replikationsfortschritt zu bieten:

• Ausstehende Vorgänge für die Replikation: Gesamtanzahl der ausstehenden Replikationsvorgänge vom Quell- zum Zielspeicherkonto, die für die einzelnen Zeitabschnitte ausgegeben wurden
• Ausstehende Bytes für die Replikation: Summe der ausstehenden Replikationsbytes von Quell- zu Zielspeicherkonten, die für die einzelnen Zeitabschnitte ausgegeben wurden

Jede der zuvor aufgeführten Metriken kann mit der Dimension von Zeit-Buckets angezeigt werden. Diese Aufschlüsselung ermöglicht Einblicke in die Anzahl von Bytes oder Vorgängen, für welche die Replikation pro Zeitabschnitt ausstehen, wie folgt:

• 0-5 Minuten
• 5-10 Minuten
• 10-15 Minuten
• 15-30 Minuten
• 30 Minuten-2 Stunden
• 2-8 Stunden
• 8-24 Stunden
• >24 Stunden

Das folgende Beispielbild zeigt die Metrik für den ausstehenden Vorgang und die Bytes der vorherigen sieben Tage.

Sie können Replikationsmetriken für das Quellkonto für die Überwachung ausstehender Bytes und ausstehender Vorgänge aktivieren. Weitere Informationen finden Sie unter Konfigurieren von Replikationsmetriken.

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.

Hinweis

Während die Replikation ausgeführt wird, gibt es keine Möglichkeit, den Prozentsatz oder replizierte Daten zu ermitteln.

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.
• Stellen Sie sicher, dass der Zielcontainer nicht gelöscht wurde und sich nicht im Prozess der Löschung befindet. 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 Quell-BLOB mit einem vom Kunden bereitgestellten Schlüssel als Teil eines Schreibvorgangs verschlüsselt ist, schlägt die Objektreplikation fehl. 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 Ziel-BLOB auf die Archivebene verschoben wird. 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 Blob nicht durch eine Unveränderbarkeitsrichtlinie 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

Es gibt keine Kosten zum Konfigurieren der Objektreplikation, einschließlich der Aufgabe, den Änderungsfeed zu aktivieren, die Versionsverwaltung zu aktivieren und Replikationsrichtlinien hinzuzufügen. Bei der Objektreplikation entstehen jedoch Kosten für Lese- und Schreibvorgänge für die Quell- und Zielkonten. Kosten für die Replikation von Daten vom Quellkonto auf das Zielkonto entstehen ebenfalls, wie auch Lesekosten bei der Verarbeitung des Änderungsfeeds.

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

Kosten für die Aktualisierung eines Blobs im Quellkonto	Kosten für die Replikation von Daten im Zielkonto
Transaktionskosten eines Schreibvorgangs	Transaktionskosten zum Lesen eines Änderungsfeed-Datensatzes
Speicherkosten für das Blob und die einzelnen Blobversionen1	Transaktionskosten zum Lesen des Blobs und der Blobversionen2
Kosten für das Hinzufügen eines Änderungsfeed-Datensatzes	Transaktionskosten zum Schreiben des Blobs und der Blobversionen2
Datenabrufkosten für kühle und kalte Stufen	Speicherkosten für das Blob und die einzelnen Blobversionen1
	Kosten des Netzwerkausgangs3

¹ Wenn die Ebene eines BLOBs oder einer Version im Quellkonto nicht geändert wurde, 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.

Tipp

Um das Risiko einer unerwarteten Rechnung zu verringern, aktivieren Sie die Objektreplikation in einem Konto, das nur wenige Objekte enthält. Messen Sie dann die Auswirkungen auf die Kosten, bevor Sie das Feature in einer Produktionsumgebung aktivieren.

Nächste Schritte

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