Objektreplikation für Blockblobs

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

• Minimierung der Latenz. Objektreplikation reduziert die Latenz bei Leseanfragen, indem Clients Daten aus einer Region in näherer physischer Nähe konsumieren können.
• Erhöhen der Effizienz für Computeworkloads. Bei der Objektreplikation können Computeworkloads dieselben Sätze von Blockblobs in verschiedenen Regionen verarbeiten.
• Optimieren Sie die Datenverteilung. Sie können Daten an einem einzelnen Ort verarbeiten oder analysieren und dann nur die Ergebnisse in zusätzliche Regionen replizieren.
• Kostenoptimierung. Nachdem Ihre Daten repliziert wurden, können Sie Kosten senken, indem Sie sie mithilfe von Lebenszyklus-Management-Richtlinien 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

Für die Objektreplikation ist es erforderlich, dass auch die folgenden Azure Storage-Funktionen aktiviert sind:

• Feed ändern: Im Quellkonto aktivieren. Informationen zum Aktivieren des Änderungsfeeds finden Sie unter Enable und Deaktivieren des Änderungsfeeds.
• Blob-Versionierung: Aktivieren Sie sie sowohl im Quell- als auch im Zielkonto. 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 Azure Storage Preisseite.

Die Objektreplikation unterstützt Speicherkonten vom Typ Allgemeiner Zweck v2 und Premium-Blockblobkonten. Sowohl Quell- als auch Zielkonten müssen Blockblobkonten des Typs „Universell V2“ oder „Premium“ sein. Objektreplikation unterstützt nur Blockblobs; es unterstützt keine Append-Blobs und Page Blobs.

Objektreplikation unterstützt Konten, die entweder mit von Microsoft verwalteten Schlüsseln oder kundenverwalteten Schlüsseln verschlüsselt sind. Weitere Informationen zu vom Kunden verwalteten Schlüsseln finden Sie unter Customer-managed keys for Azure Storage encryption.

Objektreplikation unterstützt keine Blobs im Quellkonto, die mit einem vom Kunden bereitgestellten Schlüssel verschlüsselt sind. Weitere Informationen zu vom Kunden bereitgestellten Schlüsseln finden Sie unter Verschlüsselungsschlüssel für eine Anfrage an den Blob-Speicher bereitstellen.

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

Objektreplikation wird in Konten mit aktiviertem hierarchischen Namensraum nicht unterstützt.

Die Objektreplikation wird für Blobs, die mit 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 Dienst kopiert den Inhalt des Blobs, alle mit dem Blob verbundenen Versionen sowie die Metadaten und Eigenschaften des Blobs vom Quellcontainer in den Zielcontainer.

Wichtig

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

Objektreplikation (OR) unterstützt nun Prioritätsreplikation, die die Replikation aller Operationen in einer ODER-Richtlinie priorisiert. Wenn die OR-Prioritätsreplikation aktiviert ist, verbessert sich die Replikationsleistung aller Operationen. 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-Begriffen und im Artikel Object Replication Priority Replication .

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

Objekt-Replikation erfordert, dass du Blob-Versionierung sowohl im Quell- als auch im Zielkonto aktivierst. Wenn Sie einen replizierten Blob im Quellkonto modifizieren, erstellt der Dienst eine neue Version des Blobs im Quellkonto, die den vorherigen Zustand des Blobs vor der Änderung widerspiegelt. Die aktuelle Version im Quellkonto spiegelt die neuesten Updates wider. Der Dienst repliziert sowohl die aktuelle Version als auch alle vorherigen Versionen auf das Zielkonto. 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 Versionierung von Blobs 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. Der Dienst kopiert nicht die Versions-ID eines Blobs. Nachdem der Dienst einen Blob am Zielort platziert hat, weist er eine neue Versions-ID zu.

Löschen eines Blobs im Quellkonto

Wenn du einen Blob im Quellkonto löschst, wird die aktuelle Version des Blobs zu einer früheren Version, und es gibt keine aktuelle Version mehr. Der Dienst bewahrt alle bestehenden bisherigen Versionen des Blobs. Der Dienst repliziert diesen Zustand auf das Zielkonto. Weitere Informationen darüber, wie Löschoperationen Blob-Versionen beeinflussen, finden Sie unter Versionsführung von Löschoperationen.

Momentaufnahmen

Die Objektreplikation unterstützt keine Blobmomentaufnahmen. Der Dienst repliziert keine Snapshots eines Blobs im Quellkonto auf das Zielkonto.

Blobindextags

Die Objektreplikation unterstützt jetzt das Kopieren von Indextags aus Quell-Blobs in Ziel-Blobs. Sie können diese Funktion als Teil einer neuen oder vorhandenen Replikationsregel konfigurieren. Weitere Informationen finden Sie unter Konfigurieren der Objektreplikation.

Wichtig

Die Tag-Replikation befindet sich derzeit in der Vorschauphase. Lesen Sie die Supplemental-Nutzungsbedingungen für Microsoft Azure Previews für rechtliche Bedingungen, die für Azure Features gelten, die sich in der Betaversion, vorschau oder auf andere Weise noch nicht in der allgemeinen Verfügbarkeit befinden.

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. Das Rehydratieren eines archivierten Blobs löst keine Objektreplikation aus. Die Objektreplikation wird nur ausgelöst, wenn die BLOB-Daten nach der Rehydratation erneut aktualisiert werden. Weitere Informationen zu Blobebenen finden Sie unter Zugriffsebenen für Blobdaten.

Unveränderliche Blobs

Unveränderliche Richtlinien für Azure Blob Storage umfassen zeitbasierte Aufbewahrungsrichtlinien und rechtliche Aufbewahrungen. 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. Für weitere Informationen darüber, welche Operationen mit einer auf eine Version begrenzten Unveränderlichkeitsrichtlinie verboten sind, siehe Szenarien mit Versionsebene.

Objektreplikationsrichtlinien und -regeln

Wenn Sie die Objektreplikation konfigurieren, erstellen Sie eine Replikationsrichtlinie, die das Quellspeicherkonto und das Zielkonto angibt. 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 Objektreplikation konfigurieren, erstellen Sie eine Replikationsrichtlinie auf dem Zielkonto über den Azure Storage Resource Provider. Nachdem Sie die Replikationsrichtlinie erstellt haben, 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 auf den Quell- und Zielkonten muss gleich sein, damit die Replikation erfolgen 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. Sie können für jedes Quell- und Zielkontopaar nur eine Replikationsrichtlinie erstellen.

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. Du kannst die Regel deaktivieren, indem du sie entweder für diesen Container löschst oder die gesamte Replikationsrichtlinie entfernst.

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 Zugriffsebenen für Blob-Daten.

Hinweis

Wenn Sie die access Ebene eines Blobs im Quellkonto ändern, wird die access Ebene dieses Blobs im Zielkonto nicht geändert.

Richtliniendefinitionsdatei

Verwenden Sie eine JSON-Datei, um eine Objekt-Replikationsrichtlinie 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>",
    "metrics": {
		  "enabled": false
    },
    "priorityReplication": "false",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Benutzerdefinierte Filter

Du kannst Filter mit verschiedenen Optionen in einer JSON-Datei anpassen:

• Blobs per Präfix abgleichen – repliziere nur Blobs, deren Namen mit dem Buchstaben bbeginnen.

"filters": {
          "prefixMatch": [
            "b"
          ],
        }

• Gruppen Sie Blobs nach Erstellungszeit – replizieren Sie nur Blobs, die auf oder nach der angegebenen Zeit erstellt wurden.

"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}

• Replizieren Sie alle Blobs – setzen Sie die minimale Erstellungszeit auf den frühestmöglichen Wert.

"filters": {
  "minCreationTime": "1601-01-01T00: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 das sourceAccount und destinationAccounteinträge an, wie im Beispiel im vorherigen Abschnitt gezeigt. Informationen zum Suchen der Ressourcen-ID für ein Speicherkonto finden Sie unter Die Ressourcen-ID für ein Speicherkonto abrufen.

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 AllowCrossTenantReplication-Sicherheitseigenschaft in Version 2021-02-01 der Azure Storage-Ressourcenanbieter-REST-API müssen Sie nun die vollständige Ressourcen-ID für alle Objekt-Replikationsrichtlinien bereitstellen, die Sie erstellen, wenn die Cross-Tenant-Replikation für ein Speicherkonto, das an der Replikationsrichtlinie teilnimmt, nicht erlaubt ist. Azure Storage verwendet die vollständige Ressourcen-ID, um zu überprüfen, ob sich die Quell- und Zielkonten im selben Mandanten befinden. Weitere Informationen zum Verhindern von mandantenübergreifenden Replikationsrichtlinien finden Sie unter Verhindern der Replikation über Microsoft Entra Mandanten hinweg.

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 vorherigen Versionen der REST-API des Azure Storage Ressourcenanbieters unterstützen den vollständigen Ressourcen-ID-Pfad 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.

Speicherkontokennung 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, da Azure Storage nicht überprüfen kann, ob sich Quell- und Zielkonten im selben 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 Sie die Replikation zwischen Microsoft Entra-Mandanten.

Ein Microsoft Entra Mandant ist eine dedizierte Instanz von Microsoft Entra ID, die eine Organisation für die Identitäts- und Zugriffsverwaltung repräsentiert. Jedes Azure-Abonnement verfügt über eine Vertrauensstellung mit einem einzelnen Microsoft Entra Mandanten. Alle Ressourcen in einem Abonnement, einschließlich Speicherkonten, sind demselben Microsoft Entra Mandanten zugeordnet. Weitere Informationen finden Sie unter What is 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 Storage-Konten beschränken, die sich ausschließlich innerhalb desselben Mandanten befinden, können Sie die Replikation über Mandanten hinweg verbieten, indem Sie die Sicherheitseigenschaft AllowCrossTenantReplication-Eigenschaft (Vorschau) festlegen. Wenn Sie die mandantenübergreifende Objektreplikation für ein Speicherkonto deaktivieren, stellt Azure Storage eine zusätzliche Anforderung fest. 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 zur Verhinderung der mandantenübergreifenden Objektreplikation finden Sie unter Verhindern der Objektreplikation über Microsoft Entra-Mandanten hinweg.

Um die Mandanten-übergreifende Objektreplikation für ein Speicherkonto zu verbieten, legen Sie die Eigenschaft AllowCrossTenantReplication auf false fest. Wenn das storage Konto derzeit nicht an mandantenübergreifenden Objektreplikationsrichtlinien teilnimmt, wird durch Festlegen der AllowCrossTenantReplication-Eigenschaft auf false verhindert, dass zukünftige Konfiguration von mandantenübergreifenden Objektreplikationsrichtlinien mit diesem storage Konto als Quelle oder Ziel festgelegt wird.

Wenn das Speicherkonto derzeit an einer oder mehreren mandantenübergreifenden Objektreplikationsrichtlinien teilnimmt, ist das Festlegen der Eigenschaft AllowCrossTenantReplication auf false nicht zulässig. Sie müssen die vorhandenen mandantenübergreifenden Richtlinien löschen, bevor Sie die mandantenübergreifende Replikation unterbinden können.

Standardmäßig ist die Eigenschaft AllowCrossTenantReplication für ein Speicherkonto, das ab dem 15. Dezember 2023 erstellt wird, auf "false" festgelegt. Für Speicherkonten, die vor dem 15. Dezember 2023 erstellt wurden, ist der Wert der AllowCrossTenantReplication-Eigenschaft eines Speicherkontos null oder true, dann können autorisierte Benutzer mandantenübergreifend 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.

Sie können Azure Policy verwenden, um eine Reihe von Speicherkonten zu überwachen, um sicherzustellen, dass die eigenschaft AllowCrossTenantReplication festgelegt ist, um eine mandantenübergreifende Objektreplikation zu verhindern. Sie können auch Azure Policy verwenden, um Governance für eine Reihe von Speicherkonten zu erzwingen. 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 dass ein Benutzer ein vorhandenes Speicherkonto ändert, um den Eigenschaftswert in true zu ändern.

Replikationsmetriken

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

• Vorgänge mit ausstehender Replikation: Gesamtanzahl der Vorgänge mit ausstehender Replikation aus dem Quellkonto zum Zielspeicherkonto, die pro Zeitrahmen ausgegeben wurden
• Bytes mit ausstehender Replikation: Summe der Bytes mit ausstehender Replikation aus Quellkonten zu Zielspeicherkonten, die pro Zeitrahmen 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 im Gange ist, gibt es keine Möglichkeit, den Prozentsatz der replizierten Daten zu bestimmen.

Wenn der Replikationsstatus eines Blobs im Quellkonto auf einen Ausfall 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 Verschlüsselungsschlüssel für eine Anfrage an den Blob-Speicher bereitstellen.
• Ü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 Zugriffsebenen für Blob-Daten.
• Stellen Sie sicher, dass der Zielcontainer oder Blob nicht durch eine Unveränderbarkeitsrichtlinie geschützt ist. Ein Container oder Blob kann eine Unveränderlichkeitsrichtlinie von seinem Elternteil erben. Weitere Informationen zu Unveränderlichkeitsrichtlinien finden Sie unter Übersicht über unveränderlichen Speicher für Blob-Daten.

Featureunterstützung

Die Unterstützung für dieses Feature kann durch aktivieren von Data Lake Storage Gen2, 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 Blob Storage Funktionalitätsunterstützung in Azure Storage Konten, um die Unterstützung für dieses Feature zu bewerten.

Abrechnung

Es gibt keine Kosten für die Konfiguration der Objektreplikation, einschließlich des Aktivierens des Änderungsfeeds, der Versionierung und der Replikationsrichtlinien. Bei der Objektreplikation entstehen jedoch Kosten für Lese- und Schreibvorgänge für die Quell- und Zielkonten. Für die Replikation von Daten vom Quellkonto zum Zielkonto fallen ebenfalls Gebühren für ausgehenden Datenverkehr an, ebenso wie Lesegebühren bei der Verarbeitung des Änderungsfeeds.

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

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 des Blobs und jeder Blob-Version1	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 des Blobs und jeder Blob-Version1
	Kosten des Netzwerkausgangs3

¹ Im Quellkonto gilt: Wenn die Stufe eines Blobs oder einer Version unverändert bleibt, werden Sie für eindeutige Datenblöcke über diesen Blob und seine Versionen abgerechnet. Siehe Preise und Abrechnung für Blobversionsverwaltung. Im Zielkonto werden Ihnen bei einer Version alle Blöcke dieser Version in Rechnung gestellt, unabhängig davon, ob diese Blöcke einzigartig sind oder nicht.

² Diese Kosten beinhalten nur Blob-Versionen, die seit 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. Siehe Bandwidth-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
• Verhinderung der Objektreplikation über Microsoft Entra-Mandanten hinweg
• Blob-Versionsverwaltung
• Änderungsfeedunterstützung in Azure Blob Storage