Objectreplicatie voor blok-blobs

Objectreplicatie kopieert asynchroon blok-blobs tussen een bron-storage-account en een doelaccount. Enkele scenario's die worden ondersteund door objectreplicatie zijn:

  • Minimaliseer latentie. Objectreplicatie vermindert de latentie voor leesverzoeken door clients in staat te stellen data te consumeren uit een gebied dichter bij de fysieke omgeving.
  • Verhoog de efficiëntie voor rekenworkloads. Met objectreplicatie kunnen rekenworkloads dezelfde sets blok-blobs in verschillende regio's verwerken.
  • Optimaliseer de datadistributie. U kunt gegevens op één locatie verwerken of analyseren en vervolgens alleen de resultaten repliceren naar extra regio's.
  • Kosten optimaliseren. Nadat je data is gerepliceerd, kun je kosten besparen door deze naar het archiefniveau te verplaatsen met behulp van levenscyclusbeheerbeleid.

In het volgende diagram ziet u hoe objectreplicatie blok-blobs repliceert van een bron-storage-account in één regio naar doelaccounts in twee verschillende regio's.

Diagram waarin wordt getoond hoe objectreplicatie werkt.

Zie Objectreplicatie configureren voor meer informatie over het configureren van objectreplicatie.

Vereisten en beperkingen voor objectreplicatie

Objectreplicatie vereist dat de volgende Azure Storage functies ook zijn ingeschakeld:

Het inschakelen van wijzigingenfeed- en blobversiebeheer kan extra kosten in rekening brengen. Zie de pagina Azure Storage prijzen voor meer informatie.

Objectreplicatie ondersteunt zowel opslagaccounts voor algemene doeleinden van het type v2 als premium block blob-accounts. De bron- en doelaccounts moeten zowel algemeen v2- als premium blok-blobaccounts zijn. Objectreplicatie ondersteunt alleen block blobs; het ondersteunt geen append blobs en page blobs.

Objectreplicatie ondersteunt accounts die zijn versleuteld met ofwel door Microsoft beheerde sleutels of door klanten beheerde sleutels. Zie Customer-beheerde sleutels voor Azure Storage versleuteling voor meer informatie over door de klant beheerde sleutels.

Objectreplicatie ondersteunt geen blobs in het bronaccount die versleuteld zijn met een door de klant verstrekte sleutel. Zie Versleutelingssleutel op aanvraag voor Blob storage voor meer informatie over door de klant verstrekte sleutels.

Door de klant beheerde failover wordt niet ondersteund voor het bron- of doelaccount in een objectreplicatiebeleid.

Objectreplicatie wordt niet ondersteund in accounts met een hiërarchische naamruimte ingeschakeld.

Objectreplicatie wordt niet ondersteund voor blobs die worden geüpload met behulp van Data Lake Storage API's.

Hoe objectreplicatie werkt

Objectreplicatie kopieert asynchroon blok-blobs in een container volgens de regels die u configureert. De service kopieert de inhoud van de blob, eventuele versies die met de blob zijn geassocieerd, en de metadata en eigenschappen van de blob van de broncontainer naar de bestemmingscontainer.

Belangrijk

Omdat blok-blobgegevens asynchroon worden gerepliceerd, worden het bronaccount en het doelaccount niet onmiddellijk gesynchroniseerd.

Objectreplicatie (OR) ondersteunt nu prioriteitsreplicatie, waarbij de replicatie van alle bewerkingen in een OR-beleid wordt geprioriteerd. Wanneer OR-prioriteitsreplicatie is ingeschakeld, verbetert de replicatieprestaties van alle bewerkingen. Wanneer het bron- en doelaccount van een replicatiebeleid zich binnen hetzelfde continent bevinden, repliceert OR-prioriteitsreplicatie ook 99,0% objecten binnen 15 minuten voor ondersteunde workloads. De prestaties van functies worden gegarandeerd met een SLA (Service Level Agreement). Voor meer informatie, zie de SLA-termen en het artikel Object Replication Priority Replication .

U kunt ook de replicatiestatus van de bron-blob controleren om te bepalen of de replicatie is voltooid. Zie De replicatiestatus van een blob controleren voor meer informatie.

Blob-versiebeheer

Objectreplicatie vereist dat je blobversieering inschakelt op zowel het bron- als het bestemmingsaccount. Wanneer je een gerepliceerde blob in het bronaccount aanpast, maakt de service een nieuwe versie van de blob aan in het bronaccount die de vorige staat van de blob weergeeft, vóór de wijziging. De huidige versie in het bronaccount weerspiegelt de meest recente updates. De dienst repliceert zowel de huidige versie als eerdere versies naar het bestemmingsaccount. Zie Versiebeheer bij schrijfbewerkingen voor meer informatie over hoe schrijfbewerkingen van invloed zijn op blobversies.

Als uw storage-account objectreplicatiebeleid heeft, kunt u blobversiebeheer voor dat account niet uitschakelen. U moet alle objectreplicatiebeleidsregels voor het account verwijderen voordat u blobversiebeheer uitschakelt.

Notitie

Alleen blobs worden naar het doel gekopieerd. De service kopieert niet de versie-ID van een blob. Nadat de service een blob op de bestemmingslocatie heeft geplaatst, wijst het een nieuwe versie-ID toe.

Een blob verwijderen in het bronaccount

Wanneer je een blob verwijdert in het bronaccount, wordt de huidige versie van de blob een eerdere versie, en is er geen huidige versie meer. De dienst behoudt alle bestaande eerdere versies van de blob. De service repliceert deze toestand naar het bestemmingsaccount. Voor meer informatie over hoe verwijderoperaties blobversies beïnvloeden, zie Versiebeheer bij verwijderingsoperaties.

Momentopnamen

Objectreplicatie biedt geen ondersteuning voor blob-momentopnamen. De service repliceert geen snapshots van een blob in het bronaccount naar het bestemmingsaccount.

Blob-index-tags

Objectreplicatie ondersteunt nu het kopiëren van indextags van bron-blobs naar doel-blobs. U kunt deze mogelijkheid configureren als onderdeel van een nieuwe of bestaande replicatieregel. Zie Objectreplicatie configureren voor meer informatie.

Belangrijk

Replicatie van tags is momenteel als preview beschikbaar. Zie de Aanvullende gebruiksvoorwaarden voor Microsoft Azure previews voor juridische voorwaarden die van toepassing zijn op Azure functies die beschikbaar zijn in bèta, preview of anderszins nog niet beschikbaar zijn voor algemene beschikbaarheid.

Blob-lagen

Objectreplicatie wordt ondersteund wanneer de bron- en doelaccounts zich in een onlinelaag bevinden (dynamisch, statisch of koud). De bron- en doelaccounts bevinden zich mogelijk in verschillende lagen. Objectreplicatie mislukt echter als een blob in het bron- of doelaccount wordt verplaatst naar de archieflaag. Het rehydrateren van een gearchiveerde blob activeert geen objectreplicatie. Objectreplicatie wordt alleen geactiveerd wanneer de blobgegevens na rehydratatie opnieuw worden bijgewerkt. Raadpleeg Toegangsniveaus voor blobgegevens voor meer informatie over blobniveaus.

Onveranderbare blobs

Onveranderbaarheidsbeleid voor Azure Blob Storage bevat tijdgebaseerde bewaarbeleid en juridische blokkeringen. Wanneer een beleid voor onveranderbaarheid van kracht is op het doelaccount, kan dit gevolgen hebben voor objectreplicatie. Voor meer informatie over onveranderbaarheidsbeleid, zie Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag.

Als de doelcontainer een beleid voor onveranderbaarheid op containerniveau heeft, kunnen wijzigingen in objecten in de broncontainer, zoals updates of verwijderingen, nog steeds slagen. Deze wijzigingen kunnen echter niet worden gerepliceerd naar de doelcontainer vanwege de onveranderbaarheidsbeperking. Zie Scenario's met bereik op containerniveau voor meer informatie over welke bewerkingen zijn verboden met een beleid voor onveranderbaarheid dat is gericht op een container.

Als de blobversie van een doelaccount een beleid voor onveranderbaarheid op actief versieniveau heeft, kan een verwijder- of updatebewerking die wordt uitgevoerd op de bijbehorende blobversie van de broncontainer slagen. Replicatie van deze bewerking naar het doelobject mislukt echter. Voor meer informatie over welke bewerkingen verboden zijn met een onveranderlijkheidsbeleid dat is beperkt tot een versie, zie Scenario's met versieniveau-scope.

Beleid en regels voor objectreplicatie

Wanneer u objectreplicatie configureert, maakt u een replicatiebeleid dat de bron-storage-account en het doelaccount aangeeft. Een replicatiebeleid bevat een of meer regels die een bron- en doelcontainer opgeven en aangeven welke bron-blobs worden gerepliceerd.

Nadat u objectreplicatie hebt geconfigureerd, controleert Azure Storage regelmatig de wijzigingenfeed voor het bronaccount en repliceert asynchroon alle schrijf- of verwijderbewerkingen naar het doelaccount. De replicatielatentie is afhankelijk van de grootte van de blok-blob die wordt gerepliceerd.

Replicatiebeleid

Wanneer je objectreplicatie configureert, maak je een replicatiebeleid aan op het bestemmingsaccount via de Azure Storage resource provider. Nadat je het replicatiebeleid hebt aangemaakt, wijst Azure Storage het een beleids-ID toe. Vervolgens moet u dat replicatiebeleid koppelen aan het bronaccount met behulp van de beleids-id. De beleids-ID op de bron- en bestemmingsaccounts moet hetzelfde zijn om replicatie mogelijk te maken.

Een bronaccount kan worden gerepliceerd naar maximaal twee doelaccounts, met één beleid voor elk doelaccount. Op dezelfde manier kan een account fungeren als het doelaccount voor maximaal twee replicatiebeleidsregels.

De bron- en doelaccounts bevinden zich mogelijk in dezelfde regio of in verschillende regio's. Ze kunnen zich ook in hetzelfde abonnement of in verschillende abonnementen bevinden. Optioneel kunnen de bron- en doelaccounts zich in verschillende Microsoft Entra tenants bevinden. Je kunt slechts één replicatiebeleid aanmaken voor elk bron- en bestemmingsaccountpaar.

Replicatieregels

Replicatieregels geven aan hoe Azure Storage blobs van een broncontainer repliceert naar een doelcontainer. U kunt maximaal 1000 replicatieregels opgeven voor elk replicatiebeleid. Elke replicatieregel definieert één bron- en doelcontainer en elke bron- en doelcontainer kan slechts in één regel worden gebruikt. Als gevolg hiervan kunnen maximaal 1000 broncontainers en 1000 doelcontainers deelnemen aan één replicatiebeleid.

Nadat u een replicatieregel hebt gemaakt, worden bestaande blobs genegeerd; alleen nieuwe blok-blobs die worden toegevoegd nadat de regel is gemaakt, worden standaard gekopieerd. U kunt echter opgeven dat zowel nieuwe als bestaande blok-blobs worden gekopieerd. U kunt ook een aangepast kopieerbereik definiëren waarmee blok-blobs worden gekopieerd die na een opgegeven tijd zijn gemaakt.

U kunt ook een of meer filters opgeven als onderdeel van een replicatieregel om blok-blobs te filteren op voorvoegsel. Wanneer u een voorvoegsel opgeeft, worden alleen blobs die overeenkomen met dat voorvoegsel in de broncontainer gekopieerd naar de doelcontainer.

De bron- en doelcontainers moeten beide bestaan voordat u ze in een regel kunt opgeven. Nadat u het replicatiebeleid hebt gemaakt, zijn schrijfbewerkingen naar de doelcontainer niet toegestaan. Pogingen om naar de doelcontainer te schrijven, mislukken met foutcode 409 (Conflict).

Als u wilt schrijven naar een doelcontainer met een replicatieregel, moet u eerst replicatie uitschakelen. Je kunt de regel uitschakelen door deze voor die container te verwijderen of door het hele replicatiebeleid te verwijderen.

Lees- en verwijderbewerkingen naar de doelcontainer zijn toegestaan wanneer het replicatiebeleid actief is.

U kunt de bewerking Set Blob Tier aanroepen voor een blob in de doelcontainer om het naar de archieflaag te verplaatsen. Zie Toegangsindelingen voor blobgegevens voor meer informatie over de archieflaag.

Notitie

Als u de access laag van een blob in het bronaccount wijzigt, verandert de access laag van die blob niet in het doelaccount.

Beleidsdefinitiebestand

Gebruik een JSON-bestand om een objectreplicatiebeleid te definiëren. U kunt het beleidsdefinitiebestand ophalen uit een bestaand objectreplicatiebeleid of u kunt een objectreplicatiebeleid maken door een beleidsdefinitiebestand te uploaden.

Voorbeeld van een beleidsdefinitiebestand

In het volgende voorbeeld wordt een replicatiebeleid ingesteld voor het doelaccount met één regel. De regel is gericht op blobs met het voorvoegsel b en geeft een minimale aanmaaktijd voor replicatie op. Vergeet niet om waarden tussen punthaken te vervangen door uw eigen waarden:

{
  "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"
        }
      }
    ]
  }
}

Aangepaste filters

Je kunt filters aanpassen met verschillende opties in een JSON-bestand:

  • Koppel blobs op prefix — repliceer alleen blobs waarvan de naam begint met de letter b.
"filters": {
          "prefixMatch": [
            "b"
          ],
        }
  • Koppel blobs op creatietijd — repliceer alleen blobs die op of na de opgegeven tijd zijn gemaakt.
"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}
  • Repliceer alle blobs — stel de minimale creatietijd in op de vroegst mogelijke waarde.
"filters": {
  "minCreationTime": "1601-01-01T00:00:00Z"
}

Volledige resource-id's opgeven voor bron- en doelaccounts

Wanneer u het beleidsdefinitiebestand maakt, geeft u de volledige Azure Resource Manager resource-id's op voor de vermeldingen sourceAccount en destinationAccount, zoals wordt weergegeven in het voorbeeld in de vorige sectie. Zie Get the resource ID for a storage account voor meer informatie over het vinden van de resource-id voor een storage-account.

De volledige resource-id heeft de volgende indeling:

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

Het bestand met beleidsdefinities vereist eerder alleen de accountnaam, in plaats van de volledige resource-id voor het storage-account. Met de introductie van de AllowCrossTenantReplication beveiligingseigenschap in versie 2021-02-01 van de Azure Storage resource provider REST API, moet je nu de volledige resource ID geven voor elk objectreplicatiebeleid dat je aanmaakt wanneer cross-tenant replicatie niet is toegestaan voor een opslagaccount dat deelneemt aan het replicatiebeleid. Azure Storage de volledige resource-id gebruikt om te controleren of de bron- en doelaccounts zich in dezelfde tenant bevinden. Zie Prevent-replicatie voor Microsoft Entra tenants voor meer informatie over het ongedaan maken van replicatiebeleid voor meerdere tenants.

Hoewel het gebruik van alleen de accountnaam nog steeds wordt ondersteund voor replicatie tussen tenants, wordt Microsoft aanbevolen om de volledige resource-id te gebruiken als best practice. Alle vorige versies van de Azure Storage resourceprovider-REST-API ondersteunen het gebruik van het volledige resource-id-pad in objectreplicatiebeleid.

In de volgende tabel ziet u hoe het gedrag van replicatiebeleid verschilt wanneer u een volledige resource-id versus een accountnaam gebruikt. De vergelijking is afhankelijk van of replicatie tussen tenants is toegestaan voor het storage-account.

opslagaccount-ID in beleidsdefinitie Replicatie tussen tenants is toegestaan Replicatie tussen tenants is niet toegestaan
Volledig bron-ID Er kunnen beleidsregels voor dezelfde tenant worden gemaakt.

Beleidsregels voor meerdere tenants kunnen worden gemaakt.		 Er kunnen beleidsregels voor dezelfde tenant worden gemaakt.

Beleidsregels voor meerdere tenants kunnen niet worden gemaakt.
Enkel accountnaam Er kunnen beleidsregels voor dezelfde tenant worden gemaakt.

Beleidsregels voor meerdere tenants kunnen worden gemaakt.		 Er kunnen geen beleid voor dezelfde tenant of meerdere tenants worden gemaakt. Er treedt een fout op, omdat Azure Storage niet kan controleren of de bron- en doelaccounts zich in dezelfde tenant bevinden. De fout geeft aan dat u de volledige resource-id moet opgeven voor de vermeldingen sourceAccount en destinationAccount in het beleidsdefinitiebestand.

Specificeer de beleids- en regel-ID's

De volgende tabel bevat een overzicht van de waarden die moeten worden gebruikt voor de vermeldingen policyId en ruleId in het bestand met beleidsdefinities in elk scenario.

Wanneer u het beleidsdefinitiebestand voor dit account maakt... Stel de beleids-id in op deze waarde Regel-ID's instellen op deze waarde
Doelrekening De tekenreekswaarde default. Azure Storage maakt de waarde voor de beleids-ID voor u. Een lege tekenreeks. Azure Storage maakt de regel-ID-waarden voor u aan.
Bronaccount De waarde van de beleids-ID die wordt geretourneerd wanneer u het beleidsdefinitiebestand voor het bestemmingsaccount downloadt. De waarden van de regel-id's die worden geretourneerd wanneer u het beleidsdefinitiebestand voor het doelaccount downloadt.

Voorkom replicatie tussen Microsoft Entra-tenantparen

Een Microsoft Entra-tenant is een toegewezen exemplaar van Microsoft Entra ID dat een organisatie vertegenwoordigt voor identiteits- en toegangsbeheer. Elk Azure-abonnement heeft een vertrouwensrelatie met één Microsoft Entra tenant. Alle resources in een abonnement, inclusief opslagaccounts, zijn gekoppeld aan dezelfde Microsoft Entra tenant. Zie Wat is Microsoft Entra ID? voor meer informatie

Replicatie tussen tenants is standaard uitgeschakeld voor nieuwe accounts die zijn gemaakt vanaf 15 december 2023. Als uw beveiligingsbeleid vereist dat u objectreplicatie beperkt tot storage accounts die zich alleen binnen dezelfde tenant bevinden, kunt u replicatie tussen tenants weigeren door een beveiligingseigenschap in te stellen, de eigenschap AllowCrossTenantReplication (preview). Wanneer u cross-tenant objectreplicatie voor een opslagaccount uitschakelt, legt Azure Storage een extra vereiste op. Voor elk objectreplicatiebeleid dat gebruikmaakt van dit opslagaccount als de bron of het doel, moeten beide accounts deel uitmaken van dezelfde Microsoft Entra tenant. Zie Prevent objectreplicatie over Microsoft Entra tenants voor meer informatie over het niet-toestaan van objectreplicatie over verschillende tenants.

Als u replicatie van meerdere tenantobjecten voor een storage-account wilt weigeren, stelt u de eigenschap AllowCrossTenantReplication in op false. Als het storage-account momenteel niet deelneemt aan een cross-tenant objectreplicatiebeleid, voorkomt het instellen van de eigenschap AllowCrossTenantReplication op false dat dit in de toekomst geconfigureerd kan worden met dit storage-account als bron of bestemming.

Als het storage-account momenteel deelneemt aan een of meer beleidsregels voor objectreplicatie tussen tenants, is het niet toegestaan om de eigenschap AllowCrossTenantReplication op false in te stellen. U moet het bestaande beleid voor meerdere tenants verwijderen voordat u replicatie tussen tenants kunt weigeren.

De eigenschap AllowCrossTenantReplication is standaard ingesteld op false voor een storage account dat is gemaakt vanaf 15 december 2023. Voor storage accounts die vóór 15 december 2023 zijn gemaakt, wordt de waarde van de eigenschap AllowCrossTenantReplication voor een storage-account null of true, vervolgens kunnen geautoriseerde gebruikers replicatiebeleid voor meerdere tenantobjecten configureren met dit account als de bron of bestemming. Voor meer informatie over het configureren van tenantoverschrijdende beleidsregels, zie Objectreplicatie configureren voor blok-blobs.

U kunt Azure Policy gebruiken om een set opslagaccounts te controleren om ervoor te zorgen dat de eigenschap AllowCrossTenantReplication is ingesteld om replicatie van meerdere tenantobjecten te voorkomen. U kunt ook Azure Policy gebruiken om governance af te dwingen voor een set opslagaccounts. U kunt bijvoorbeeld een beleid maken met het effect deny om te voorkomen dat een gebruiker een storage-account maakt waarbij de eigenschap AllowCrossTenantReplication is ingesteld op true, of van het wijzigen van een bestaand storage-account om de eigenschapswaarde te wijzigen in true.

Metrische replicatiegegevens

Objectreplicatie ondersteunt twee metrische gegevens om u inzicht te geven in de replicatievoortgang:

  • Bewerkingen in behandeling voor replicatie: Totaal aantal bewerkingen die wachten op replicatie van bron naar doel, die per tijdbucket worden uitgezonden.
  • Bytes in behandeling voor replicatie: Som van bytes die nog in behandeling zijn voor replicatie van bron naar doelopslagaccounts en die per tijdsbucket worden uitgestoten.

Elk van de eerder vermelde metriek kan worden weergegeven met de dimensie van tijdsgroepen. Met deze uitsplitsing kunt u als volgt inzicht krijgen in hoeveel bytes of bewerkingen er in afwachting zijn voor replicatie per tijdvak:

  • 0-5 minuten
  • 5-10 minuten
  • 10-15 minuten
  • 15-30 minuten
  • 30 minuten-2 uur
  • 2-8 uur
  • 8-24 uur
  • >24 uur

In de volgende voorbeeld afbeelding ziet u de lopende bewerking en bytesmetriek voor de afgelopen zeven dagen:

Metrische gegevens over objectreplicatie met in behandeling zijnde bewerkingen en wachtende bytes gedurende een periode van zeven dagen

U kunt replicatiemetrieken inschakelen op het bronaccount om pending bytes en bewerkingen te bewaken. Zie Replicatiegegevens configureren voor meer informatie.

Replicatiestatus

U kunt de replicatiestatus voor een blob in het bronaccount controleren. Zie De replicatiestatus van een blob controleren voor meer informatie.

Notitie

Terwijl replicatie gaande is, is er geen manier om het percentage gerepliceerde data te bepalen.

Als de replicatiestatus voor een blob in het bronaccount wijst op falen, onderzoek dan de volgende mogelijke oorzaken:

  • Zorg ervoor dat het objectreplicatiebeleid is geconfigureerd op het bestemmingsaccount.
  • Controleer of het doelaccount nog bestaat.
  • Controleer of de doelcontainer nog bestaat.
  • Controleer of de doelcontainer niet is verwijderd en niet in het proces van verwijdering is. Het verwijderen van een container kan tot 30 seconden duren.
  • Controleer of de doelcontainer nog steeds deelneemt aan het objectreplicatiebeleid.
  • Als de bron-blob is versleuteld met een door de klant geleverde sleutel als onderdeel van een schrijfbewerking, mislukt de objectreplicatie. Zie Versleutelingssleutel op aanvraag voor Blob storage voor meer informatie over door de klant verstrekte sleutels.
  • Controleer of de bron- of doel-blob wordt verplaatst naar de archieflaag. Gearchiveerde blobs kunnen niet worden gerepliceerd via objectreplicatie. Zie Toegangsindelingen voor blobgegevens voor meer informatie over de archieflaag.
  • Controleer of de doelcontainer of blob niet is beveiligd door een onveranderbaarheidsbeleid. Een container of blob kan een onveranderlijkheidsbeleid van zijn ouder erven. Zie Overview van onveranderbare storage voor blobgegevens voor meer informatie over onveranderbaarheidsbeleid.

Functieondersteuning

Ondersteuning voor deze functie kan worden beïnvloed door het inschakelen van Data Lake Storage Gen2, het NFS 3.0-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u Blob Storage functieondersteuning in Azure Storage accounts om ondersteuning voor deze functie te beoordelen.

Facturatie

Het configureren van objectreplicatie is gratis, inclusief het inschakelen van wijzigingsfeed, versiebeheer en replicatiebeleid. Voor objectreplicatie worden echter kosten in rekening gebracht voor lees- en schrijftransacties voor de bron- en doelaccounts. Egresskosten voor de replicatie van gegevens van het bronaccount naar het bestemmingsaccount brengen eveneens kosten met zich mee, evenals leeskosten bij het verwerken van de change feed.

Hier volgt een uitsplitsing van de kosten. Zie Azure Blob Storage Pricing om de prijs van elk kostenonderdeel te vinden.

Kosten voor het bijwerken van een blob in het bronaccount Kosten voor het repliceren van gegevens in het doelaccount
Transactiekosten van een schrijfbewerking Transactiekosten voor het lezen van een wijzigingsfeedrecord
De opslagkosten van de blob en elke blob versie1 Transactiekosten voor het lezen van de blobs en blobversies2
Kosten voor het toevoegen van een wijzigingenfeedrecord Transactiekosten voor het schrijven van de blob- en blobversie2
Kosten voor het ophalen van gegevens op koele en koude niveaus De opslagkosten van de blob en elke blob versie1
Kosten van uitgaandnetwerk 3

1 Op het bronaccount, als de tier van een blob of versie ongewijzigd blijft, word je gefactureerd voor unieke datablokken over die blob en zijn versies. Zie prijzen voor Blob-versiebeheer en facturering. In het doelaccount worden voor een versie alle blokken van die versie in rekening gebracht, ongeacht of die blokken uniek zijn of niet.

2 Deze kosten omvatten alleen blobversies die sinds de laatste voltooide replicatie zijn gemaakt.

3 Objectreplicatie kopieert de hele versie naar bestemming (niet alleen de unieke blokken van de versie). Bij deze overdracht worden de kosten van uitgaand netwerkverkeer in rekening gebracht. Zie Bandwidth-prijzen.

Aanbeveling

Als u het risico van een onverwachte factuur wilt verminderen, schakelt u objectreplicatie in een account in dat slechts enkele objecten bevat. Meet vervolgens de impact op de kosten voordat u de functie inschakelt in een productie-instelling.

Volgende stappen

  • Last updated on