Objectreplicatie voor blok-blobs
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 niet ondersteund voor blobs die worden geüpload met behulp van Data Lake Storage Gen2-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. Er is momenteel geen SLA over hoe lang het duurt om gegevens te repliceren naar het doelaccount. U kunt 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 voor schrijfbewerkingen voor 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 objectreplicatiebeleid 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. Aan de blob die op de doellocatie wordt geplaatst, wordt 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 in een blob in het bronaccount worden niet gerepliceerd naar het doelaccount.
Blob-indextags
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 de dynamische of statische laag bevinden. De bron- en doelaccounts bevinden zich mogelijk in verschillende lagen. Objectreplicatie mislukt echter als een blob in het bron- of doelaccount is verplaatst naar de archieflaag. Zie Access-lagen voor blobgegevens voor meer informatie over bloblagen.
Onveranderbare blobs
Onveranderbaarheidsbeleid voor Azure Blob Storage omvat bewaarbeleid op basis van tijd en juridische bewaring. Wanneer een onveranderbaarheidsbeleid van kracht is op het doelaccount, kan de objectreplicatie worden beïnvloed. Zie Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag voor meer informatie over onveranderbaarheidsbeleid.
Als een beleid voor onveranderbaarheid op containerniveau van kracht is voor een container in het doelaccount en een object in de broncontainer wordt bijgewerkt of verwijderd, kan de bewerking op de broncontainer slagen, maar de replicatie van die bewerking naar de doelcontainer mislukt. 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 een beleid voor onveranderbaarheid op versieniveau van kracht is voor een blobversie in het doelaccount en er een verwijder- of updatebewerking wordt uitgevoerd op de blobversie in de broncontainer, kan de bewerking op het bronobject slagen, maar de replicatie van die bewerking naar het doelobject mislukt. 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 broncontainer en een doelcontainer opgeven en aangeven welke blok-blobs in de broncontainer 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. Optioneel kunnen de bron- en doelaccounts zich in verschillende Microsoft Entra-tenants bevinden. Er kan slechts één replicatiebeleidsregel 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 worden gebruikt in slechts één regel, wat betekent dat maximaal 1000 broncontainers en 1000 doelcontainers kunnen deelnemen aan één replicatiebeleid.
Wanneer u een replicatieregel maakt, worden standaard alleen nieuwe blok-blobs gekopieerd die vervolgens aan de broncontainer worden toegevoegd. U kunt opgeven dat zowel nieuwe als bestaande blok-blobs worden gekopieerd, of u kunt een aangepast kopieerbereik definiëren waarmee blok-blobs worden gekopieerd die vanaf 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, naar de doelcontainer gekopieerd.
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 waarvoor een replicatieregel is geconfigureerd, moet u de regel verwijderen die is geconfigureerd voor die container of het replicatiebeleid verwijderen. Lees- en verwijderbewerkingen naar de doelcontainer zijn toegestaan wanneer het replicatiebeleid actief is.
U kunt de bewerking Blob-laag instellen op een blob in de doelcontainer aanroepen om deze 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 objectreplicatiebeleid wordt gedefinieerd door het JSON-bestand. U kunt het bestand met beleidsdefinities ophalen uit een bestaand objectreplicatiebeleid. U kunt ook een objectreplicatiebeleid maken door een beleidsdefinitiebestand te uploaden.
Voorbeeld van een beleidsdefinitiebestand
In het volgende voorbeeld wordt een replicatiebeleid voor het doelaccount gedefinieerd met één regel die overeenkomt met het voorvoegsel b en de minimale aanmaaktijd voor blobs die moeten worden gerepliceerd. 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 de 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 voor een opslagaccount voor meer informatie over het vinden van de resource-id voor een opslagaccount.
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 voorkomen in Microsoft Entra-tenants voor meer informatie over het ongedaan maken van replicatiebeleid voor meerdere tenants.
Hoewel het opgeven van alleen de accountnaam nog steeds wordt ondersteund wanneer replicatie tussen tenants is toegestaan voor een opslagaccount, raadt Microsoft aan altijd de volledige resource-id op te geven als best practice. Alle vorige versies van de REST API-ondersteuning van de Azure Storage-resourceprovider met behulp van het volledige resource-id-pad in objectreplicatiebeleid.
In de volgende tabel wordt beschreven wat er gebeurt wanneer u een replicatiebeleid maakt met de volledige resource-id die is opgegeven, versus de accountnaam, in de scenario's waarin replicatie tussen tenants is toegestaan of niet is toegestaan voor het opslagaccount.
| Opslagaccount-id in beleidsdefinitie | Replicatie tussen tenants is toegestaan | Replicatie tussen tenants is niet toegestaan |
|---|---|---|
| Volledige resource-id | Hetzelfde tenantbeleid kan worden gemaakt. Beleidsregels voor meerdere tenants kunnen worden gemaakt. |
Hetzelfde tenantbeleid kan worden gemaakt. Beleidsregels voor meerdere tenants kunnen niet worden gemaakt. |
| Alleen accountnaam | Hetzelfde tenantbeleid kan 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. |
De beleids- en regel-id's opgeven
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 |
|---|---|---|
| Doelaccount | De standaardwaarde van de tekenreekswaarde. Azure Storage maakt de waarde voor de beleids-id voor u. | 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 doelaccount downloadt. | De waarden van de regel-id's die worden geretourneerd wanneer u het beleidsdefinitiebestand voor het doelaccount downloadt. |
Replicatie voorkomen in 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 niet wilt weigeren, moet Azure Storage voor elk objectreplicatiebeleid dat is geconfigureerd met dat opslagaccount als het bron- of doelaccount, zowel de bron- als doelaccounts zich in dezelfde Microsoft Entra-tenant bevinden. Zie Objectreplicatie voorkomen in Microsoft Entra-tenants voor meer informatie over het ongedaan maken van de toewijzing van crosstenantobjectreplicatie.
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 configureren met dit account als de bron of bestemming. Zie Objectreplicatie configureren voor blok-blobs voor meer informatie over het configureren van beleidsregels voor meerdere tenants.
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 effect Weigeren 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.
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 gegevens te bepalen dat is gerepliceerd.
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 bezig is met het verwijderen of niet alleen is verwijderd. 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 is 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 het bovenliggende item. 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.
Billing
Er zijn geen kosten verbonden aan het configureren van objectreplicatie. Dit omvat 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, evenals uitgaande kosten voor de replicatie van gegevens van het bronaccount naar het doelaccount en leeskosten voor het verwerken van wijzigingenfeeds.
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 blob- en blobversie2 |
| Kosten voor het toevoegen van een wijzigingenfeedrecord | Transactiekosten voor het schrijven van de blob- en blobversie2 |
| Opslagkosten van de blob en elke blob versie1 | |
| Kosten van uitgaandnetwerk 3 |
1 Als u in het bronaccount de laag van een blob of versie niet hebt gewijzigd, 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.
Tip
Als u het risico van een onverwachte factuur wilt verminderen, schakelt u objectreplicatie in een account in dat slechts een klein aantal objecten bevat. Meet vervolgens de impact op de kosten voordat u de functie inschakelt in een productie-instelling.