Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Objectreplicatie kopieert asynchroon blok-blobs tussen een bronopslagaccount en een doelaccount. Enkele scenario's die worden ondersteund door objectreplicatie zijn:
- Minimale latentie. Objectreplicatie kan de latentie voor leesaanvragen verminderen door clients in staat te stellen gegevens te gebruiken uit een regio die zich dichter bij de fysieke nabijheid bevindt.
- Verhoog de efficiëntie voor rekenworkloads. Met objectreplicatie kunnen rekenworkloads dezelfde sets blok-blobs in verschillende regio's verwerken.
- Gegevensdistributie optimaliseren. U kunt gegevens op één locatie verwerken of analyseren en vervolgens alleen de resultaten repliceren naar extra regio's.
- Kosten optimaliseren. Nadat uw gegevens zijn gerepliceerd, kunt u de kosten verlagen door deze naar de archieflaag te verplaatsen met behulp van levenscyclusbeheerbeleid.
In het volgende diagram ziet u hoe objectreplicatie blok-blobs repliceert van een bronopslagaccount in één regio naar doelaccounts in twee verschillende regio's.
Zie Objectreplicatie configureren voor meer informatie over het configureren van objectreplicatie.
Vereisten en beperkingen voor objectreplicatie
Voor objectreplicatie moeten ook de volgende Azure Storage-functies zijn ingeschakeld:
- Wijzigingenfeed: moet zijn ingeschakeld voor het bronaccount. Zie De wijzigingenfeed inschakelen en uitschakelen voor meer informatie over het inschakelen van de wijzigingenfeed.
- Blob-versiebeheer: moet zijn ingeschakeld voor zowel de bron- als doelaccounts. Zie Blob-versiebeheer inschakelen en beheren voor meer informatie over het inschakelen van versiebeheer.
Het inschakelen van wijzigingenfeed- en blobversiebeheer kan extra kosten in rekening brengen. Zie de pagina met prijzen voor Azure Storage voor meer informatie.
Objectreplicatie wordt ondersteund voor v2-opslagaccounts voor algemeen gebruik en premium blok-blobaccounts. De bron- en doelaccounts moeten zowel algemeen v2- als premium blok-blobaccounts zijn. Objectreplicatie ondersteunt alleen blok-blobs; toevoeg-blobs en pagina-blobs worden niet ondersteund.
Objectreplicatie wordt ondersteund voor accounts die zijn versleuteld met door Microsoft beheerde sleutels of door de klant beheerde sleutels. Zie Door de klant beheerde sleutels voor Azure Storage-versleuteling voor meer informatie over door de klant beheerde sleutels.
Objectreplicatie wordt niet ondersteund voor blobs in het bronaccount die zijn versleuteld met een door de klant geleverde sleutel. Zie Een versleutelingssleutel opgeven voor een aanvraag bij 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 nog niet ondersteund in accounts waarvoor een hiërarchische naamruimte is 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 inhoud van de blob, alle versies die zijn gekoppeld aan de blob en de metagegevens en eigenschappen van de blob worden allemaal gekopieerd van de broncontainer naar de doelcontainer.
Belangrijk
Omdat blok-blobgegevens asynchroon worden gerepliceerd, worden het bronaccount en het doelaccount niet onmiddellijk gesynchroniseerd.
OR ondersteunt nu prioriteitsreplicatie, waarbij prioriteit wordt gegeven aan de replicatie van alle bewerkingen binnen een OR Policy. Wanneer OR-prioriteitsreplicatie is ingeschakeld, worden de replicatieprestaties van alle bewerkingen verbeterd. 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). Ga voor meer informatie naar de SLA-termen en het artikel Over replicatieprioriteit van objectreplicatie .
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
Voor objectreplicatie is vereist dat blobversiebeheer is ingeschakeld voor zowel de bron- als doelaccounts. Wanneer een gerepliceerde blob in het bronaccount wordt gewijzigd, wordt er een nieuwe versie van de blob gemaakt in het bronaccount dat de vorige status van de blob weergeeft voordat deze wordt gewijzigd. De huidige versie in het bronaccount weerspiegelt de meest recente updates. Zowel de huidige versie als eerdere versies worden gerepliceerd naar het doelaccount. Zie Versiebeheer bij schrijfbewerkingen voor meer informatie over hoe schrijfbewerkingen van invloed zijn op blobversies.
Als uw opslagaccount 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 versie-id van een blob wordt niet gekopieerd. Nadat een blob op de doellocatie is geplaatst, wordt er een nieuwe versie-id toegewezen.
Een blob verwijderen in het bronaccount
Wanneer een blob in het bronaccount wordt verwijderd, wordt de huidige versie van de blob een eerdere versie en is er geen huidige versie meer. Alle bestaande eerdere versies van de blob blijven behouden. Deze status wordt gerepliceerd naar het doelaccount. Zie Versiebeheer bij verwijderingsbewerkingen voor meer informatie over het verwijderen van bewerkingen die van invloed zijn op blobversies.
Momentopnamen
Objectreplicatie biedt geen ondersteuning voor blob-momentopnamen. Momentopnamen van een blob in het bronaccount worden niet gerepliceerd naar het doelaccount.
Blob-index-tags
Objectreplicatie kopieert de indextags van de bron-blob niet naar de doel-blob.
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. Voor meer informatie over bloblagen, zie Toegangslagen voor blobgegevens.
Onveranderbare blobs
Onveranderbaarheidsbeleid voor Azure Blob Storage omvat bewaarbeleid op basis van tijd en juridische bewaring. Wanneer een beleid voor onveranderbaarheid van kracht is op het doelaccount, kan dit gevolgen hebben voor objectreplicatie. Zie Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag voor meer informatie over onveranderbaarheidsbeleid.
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. Zie Scenario's met een bereik op versieniveau voor meer informatie over welke bewerkingen zijn verboden met een beleid voor onveranderbaarheid dat is gericht op een container.
Beleid en regels voor objectreplicatie
Wanneer u objectreplicatie configureert, maakt u een replicatiebeleid dat het bronopslagaccount 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 u objectreplicatie configureert, maakt u een replicatiebeleid voor het doelaccount via de Azure Storage-resourceprovider. Nadat het replicatiebeleid is gemaakt, wijst Azure Storage dit toe aan een beleids-id. Vervolgens moet u dat replicatiebeleid koppelen aan het bronaccount met behulp van de beleids-id. De beleids-id voor de bron- en doelaccounts moet hetzelfde zijn om de replicatie te kunnen uitvoeren.
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. Desgewenst bevinden de bron- en doelaccounts zich in verschillende Microsoft Entra-tenants. Er kan slechts één replicatiebeleid worden gemaakt voor elk bronaccount/doelaccountpaar.
Replicatieregels
Replicatieregels geven aan hoe blobs van een broncontainer naar een doelcontainer worden gerepliceerd in Azure Storage. 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. U kunt de regel uitschakelen door deze te verwijderen voor die container 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 Toegangslagen voor blobgegevens voor meer informatie over de archieflaag.
Notitie
Als u de toegangslaag van een blob in het bronaccount wijzigt, wordt de toegangslaag van die blob in het doelaccount niet gewijzigd.
Beleidsdefinitiebestand
Een JSON-bestand wordt gebruikt 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>",
"rules": [
{
"ruleId": "",
"sourceContainer": "<source-container>",
"destinationContainer": "<destination-container>",
"filters": {
"prefixMatch": [
"b"
],
"minCreationTime": "2021-08-028T00: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 De resource-id voor een opslagaccount ophalen om te leren hoe u de resource-id voor een opslagaccount kunt vinden.
De volledige resource-id heeft de volgende indeling:
/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>
Het beleidsdefinitiebestand vereist eerder alleen de accountnaam, in plaats van de volledige resource-id voor het opslagaccount. Met de introductie van de beveiligingseigenschap AllowCrossTenantReplication in versie 2021-02-01 van de REST API van de Azure Storage-resourceprovider moet u nu de volledige resource-id opgeven voor alle objectreplicatiebeleidsregels die worden gemaakt wanneer replicatie tussen tenants niet is toegestaan voor een opslagaccount dat deelneemt aan het replicatiebeleid. Azure Storage gebruikt de volledige resource-id om te controleren of de bron- en doelaccounts zich in dezelfde tenant bevinden. Zie Replicatie tussen Microsoft Entra-tenants voorkomen voor meer informatie over het tegenhouden van replicatiebeleid tussen meerdere tenants.
Hoewel het gebruik van alleen de accountnaam nog steeds wordt ondersteund voor replicatie tussen tenants, raadt Microsoft aan om de volledige resource-id te gebruiken als best practice. Alle vorige versies van de REST API van de Azure Storage-resourceprovider 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 opslagaccount.
| Opslagaccount-identificatie 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 beleids-id-waarde voor u aan. | Een lege tekenreeks. Azure Storage maakt de regel-id-waarden voor u. |
| 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. |
Replicatie voorkomen over Microsoft Entra-tenants
Een Microsoft Entra-tenant is een toegewezen instantie van Microsoft Entra-id die 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 opslagaccounts die zich alleen binnen dezelfde tenant bevinden, kunt u replicatie tussen tenants weigeren door een beveiligingseigenschap, de eigenschap AllowCrossTenantReplication (preview) in te stellen. Wanneer u replicatie van meerdere tenantobjecten 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. Voor meer informatie over het voorkomen van crosstenantobjectreplicatie, zie Objectreplicatie voorkomen in Microsoft Entra-tenants.
Als u replicatie van meerdere tenantobjecten voor een opslagaccount wilt weigeren, stelt u de eigenschap AllowCrossTenantReplication in op false. Als het opslagaccount momenteel niet aan een replicatiebeleid voor meerdere tenantobjecten deelneemt, voorkomt u het instellen van de eigenschap AllowCrossTenantReplication op false voor toekomstige configuratie van replicatiebeleid voor meerdere tenantobjecten met dit opslagaccount als de bron of het doel.
Als het opslagaccount momenteel deelneemt aan een of meer beleidsregels voor objectreplicatie tussen tenants, is het instellen van de eigenschap AllowCrossTenantReplication op false niet toegestaan. 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 opslagaccount dat is gemaakt vanaf 15 december 2023. Voor opslagaccounts die zijn gemaakt vóór 15 december 2023, wanneer de waarde van de eigenschap AllowCrossTenantReplication voor een opslagaccount null of true is, kunnen geautoriseerde gebruikers replicatiebeleid voor meerdere tenantobjecten met dit account configureren 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 Azure Policy ook gebruiken om governance af te dwingen voor een set opslagaccounts. U kunt bijvoorbeeld een beleid maken met het deny effect om te voorkomen dat een gebruiker een opslagaccount maakt waarbij de eigenschap AllowCrossTenantReplication is ingesteld op true of een bestaand opslagaccount wijzigt om de eigenschapswaarde in waar te wijzigen.
Metrische replicatiegegevens
Objectreplicatie ondersteunt twee metrische gegevens om u inzicht te geven in de replicatievoortgang:
- Bewerkingen die in behandeling zijn voor replicatie: het totale aantal bewerkingen die in afwachting zijn van replicatie van de bronopslagrekening naar de doelopslagrekening dat per tijdsinterval wordt verzonden
- Bytes die in afwachting zijn voor replicatie: Som van bytes die voor replicatie in afwachting zijn van bron- naar doelopslagaccounts, uitgesplitst per tijdsegment.
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:
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
Hoewel de replicatie wordt uitgevoerd, is er geen manier om het percentage of de gerepliceerde gegevens te bepalen.
Als de replicatiestatus voor een blob in het bronaccount een fout aangeeft, onderzoekt u de volgende mogelijke oorzaken:
- Zorg ervoor dat het objectreplicatiebeleid is geconfigureerd voor het doelaccount.
- 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 Een versleutelingssleutel opgeven voor een aanvraag bij 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 Toegangslagen voor blobgegevens voor meer informatie over de archieflaag.
- Controleer of de doelcontainer of blob niet is beveiligd door een onveranderbaarheidsbeleid. Houd er rekening mee dat een container of blob een onveranderbaarheidsbeleid kan overnemen van zijn ouder. Zie Overzicht van onveranderbare opslag 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-protocol (Network File System) 3.0 of het SSH File Transfer Protocol (SFTP). Als u een van deze mogelijkheden hebt ingeschakeld, raadpleegt u de ondersteuning voor Blob Storage-functies in Azure Storage-accounts om ondersteuning voor deze functie te beoordelen.
Facturatie
Er zijn geen kosten verbonden aan het configureren van objectreplicatie, waaronder de taak om wijzigingenfeed in te schakelen, versiebeheer in te schakelen en replicatiebeleid toe te voegen. Voor objectreplicatie worden echter kosten in rekening gebracht voor lees- en schrijftransacties voor de bron- en doelaccounts. Uitgaande kosten voor de replicatie van gegevens van het bronaccount naar het doelaccount brengen ook kosten met zich mee, net als leeskosten tijdens het verwerken van de wijzigingenfeed.
Hier volgt een uitsplitsing van de kosten. Zie Prijzen voor Azure Blob Storage 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 |
| 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 | Opslagkosten van de blob en elke blob versie1 |
| Kosten van uitgaandnetwerk 3 |
1 Als in het bronaccount de laag van een blob of versie ongewijzigd is, wordt u gefactureerd voor unieke gegevensblokken in die blob, de versies ervan. Zie prijzen voor Blob-versiebeheer en facturering. Bij het doelaccount, voor een versie, wordt u gefactureerd voor alle blokken van een versie, ongeacht of deze blokken uniek zijn.
2 Dit omvat alleen blobversies die zijn gemaakt sinds de laatste replicatie is voltooid.
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 prijzen voor bandbreedte.
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.