Dela via

Objektreplikering för blockblobar

  • Artikel

Objektreplikering kopierar asynkront blockblobar mellan ett källlagringskonto och ett målkonto. Några scenarier som stöds av objektreplikering är:

  • Minimera svarstiden. Objektreplikering kan minska svarstiden för läsbegäranden genom att göra det möjligt för klienter att använda data från en region som ligger närmare fysisk närhet.
  • Öka effektiviteten för beräkningsarbetsbelastningar. Med objektreplikering kan beräkningsarbetsbelastningar bearbeta samma uppsättningar blockblobar i olika regioner.
  • Optimera datadistribution. Du kan bearbeta eller analysera data på en enda plats och sedan replikera bara resultaten till ytterligare regioner.
  • Optimera kostnader. När dina data har replikerats kan du minska kostnaderna genom att flytta dem till arkivnivån med hjälp av livscykelhanteringsprinciper.

Följande diagram visar hur objektreplikering replikerar blockblobar från ett källlagringskonto i en region till målkonton i två olika regioner.

Diagram som visar hur objektreplikering fungerar

Information om hur du konfigurerar objektreplikering finns i Konfigurera objektreplikering.

Krav och varningar för objektreplikering

Objektreplikering kräver att följande Azure Storage-funktioner också är aktiverade:

Aktivering av ändringsflöde och blobversionshantering kan medföra ytterligare kostnader. Mer information finns på sidan med priser för Azure Storage.

Objektreplikering stöds för allmänna v2-lagringskonton och Premium-blockblobkonton. Både käll- och målkontona måste vara antingen allmänna v2- eller Premium-blockblobkonton. Objektreplikering stöder endast blockblobar. tilläggsblobar och sidblobar stöds inte.

Objektreplikering stöds för konton som är krypterade med antingen Microsoft-hanterade nycklar eller kundhanterade nycklar. Mer information om kundhanterade nycklar finns i Kundhanterade nycklar för Azure Storage-kryptering.

Objektreplikering stöds inte för blobar i källkontot som är krypterade med en kundbaserad nyckel. Mer information om kundspecifika nycklar finns i Ange en krypteringsnyckel på en begäran till Blob Storage.

Kundhanterad redundans stöds inte för varken käll- eller målkontot i en objektreplikeringsprincip.

Objektreplikering stöds inte för blobar som laddas upp med hjälp av API:er för Data Lake Storage Gen2 .

Så här fungerar objektreplikering

Objektreplikering kopierar asynkront blockblobbar i en container enligt de regler som du konfigurerar. Innehållet i bloben, alla versioner som är associerade med blobben och blobens metadata och egenskaper kopieras alla från källcontainern till målcontainern.

Viktigt!

Eftersom blockblobdata replikeras asynkront synkroniseras inte källkontot och målkontot omedelbart. Det finns för närvarande inget serviceavtal om hur lång tid det tar att replikera data till målkontot. Du kan kontrollera replikeringsstatusen på källbloben för att avgöra om replikeringen är klar. Mer information finns i Kontrollera replikeringsstatus för en blob.

Blobversionshantering

Objektreplikering kräver att blobversionshantering är aktiverat på både käll- och målkontona. När en replikerad blob i källkontot ändras skapas en ny version av bloben i källkontot som återspeglar blobens tidigare tillstånd före ändringen. Den aktuella versionen i källkontot återspeglar de senaste uppdateringarna. Både den aktuella versionen och eventuella tidigare versioner replikeras till målkontot. Mer information om hur skrivåtgärder påverkar blobversioner finns i Versionshantering vid skrivåtgärder.

Om lagringskontot har gällande principer för objektreplikering kan du inte inaktivera blobversionshantering för det kontot. Du måste ta bort eventuella principer för objektreplikering på kontot innan du inaktiverar blobversionshantering.

Kommentar

Endast blobar kopieras till målet. En blobs versions-ID kopieras inte. Den blob som placeras på målplatsen tilldelas ett nytt versions-ID.

Ta bort en blob i källkontot

När en blob i källkontot tas bort blir den aktuella versionen av blobben en tidigare version och det finns inte längre någon aktuell version. Alla befintliga tidigare versioner av bloben bevaras. Det här tillståndet replikeras till målkontot. Mer information om hur du tar bort åtgärder påverkar blobversioner finns i Versionshantering vid borttagningsåtgärder.

Ögonblicksbilder

Objektreplikering stöder inte blobögonblicksbilder. Ögonblicksbilder på en blob i källkontot replikeras inte till målkontot.

Blobindextaggar

Objektreplikering kopierar inte källblobens indextaggar till målbloben.

Blob-nivåindelning

Objektreplikering stöds när käll- och målkontona är på den frekventa eller lågfrekventa nivån. Käll- och målkontona kan finnas på olika nivåer. Objektreplikeringen misslyckas dock om en blob i käll- eller målkontot har flyttats till arkivnivån. Mer information om blobnivåer finns i Åtkomstnivåer för blobdata.

Blobar som inte kan ändras

Oföränderlighetsprinciper för Azure Blob Storage omfattar tidsbaserade kvarhållningsprinciper och juridiska undantag. När en oföränderlighetsprincip tillämpas på målkontot kan objektreplikeringen påverkas. Mer information om oföränderlighetsprinciper finns i Lagra affärskritiska blobdata med oföränderlig lagring.

Om en princip för oföränderlighet på containernivå gäller för en container i målkontot och ett objekt i källcontainern uppdateras eller tas bort, kan åtgärden på källcontainern lyckas, men replikeringen av åtgärden till målcontainern misslyckas. Mer information om vilka åtgärder som är förbjudna med en oföränderlighetsprincip som är begränsad till en container finns i Scenarier med omfång på containernivå.

Om en princip för oföränderlighet på versionsnivå gäller för en blobversion i målkontot och en borttagnings- eller uppdateringsåtgärd utförs på blobversionen i källcontainern kan åtgärden på källobjektet lyckas, men replikeringen av åtgärden till målobjektet misslyckas. Mer information om vilka åtgärder som är förbjudna med en oföränderlighetsprincip som är begränsad till en container finns i Scenarier med omfång på versionsnivå.

Principer och regler för objektreplikering

När du konfigurerar objektreplikering skapar du en replikeringsprincip som anger källlagringskontot och målkontot. En replikeringsprincip innehåller en eller flera regler som anger en källcontainer och en målcontainer och anger vilka blockblobar i källcontainern som ska replikeras.

När du har konfigurerat objektreplikering kontrollerar Azure Storage ändringsflödet för källkontot regelbundet och replikerar asynkront eventuella skriv- eller borttagningsåtgärder till målkontot. Replikeringsfördröjningen beror på storleken på blockbloben som replikeras.

Replikeringsprinciper

När du konfigurerar objektreplikering skapar du en replikeringsprincip på målkontot via Azure Storage-resursprovidern. När replikeringsprincipen har skapats tilldelar Azure Storage det ett princip-ID. Du måste sedan associera replikeringsprincipen med källkontot med hjälp av princip-ID:t. Princip-ID:t för käll- och målkontona måste vara detsamma för att replikeringen ska kunna utföras.

Ett källkonto kan replikeras till högst två målkonton, med en princip för varje målkonto. På samma sätt kan ett konto fungera som målkonto för högst två replikeringsprinciper.

Käll- och målkontona kan finnas i samma region eller i olika regioner. De kan också finnas i samma prenumeration eller i olika prenumerationer. Alternativt kan käll- och målkontona finnas i olika Microsoft Entra-klienter. Endast en replikeringsprincip kan skapas för varje källkonto/målkonto-par.

Replikeringsregler

Replikeringsregler anger hur Azure Storage ska replikera blobar från en källcontainer till en målcontainer. Du kan ange upp till 1 000 replikeringsregler för varje replikeringsprincip. Varje replikeringsregel definierar en enda käll- och målcontainer, och varje käll- och målcontainer kan endast användas i en regel, vilket innebär att högst 1 000 källcontainrar och 1 000 målcontainrar kan delta i en enda replikeringsprincip.

När du skapar en replikeringsregel kopieras som standard endast nya blockblobar som sedan läggs till i källcontainern. Du kan ange att både nya och befintliga blockblobar kopieras, eller så kan du definiera ett anpassat kopieringsomfång som kopierar blockblobar som skapats från en angiven tidpunkt och framåt.

Du kan också ange ett eller flera filter som en del av en replikeringsregel för att filtrera blockblobar efter prefix. När du anger ett prefix kopieras endast blobar som matchar det prefixet i källcontainern till målcontainern.

Både käll- och målcontainrarna måste finnas innan du kan ange dem i en regel. När du har skapat replikeringsprincipen tillåts inte skrivåtgärder till målcontainern. Försök att skriva till målcontainern misslyckas med felkoden 409 (konflikt). Om du vill skriva till en målcontainer som en replikeringsregel har konfigurerats för måste du antingen ta bort regeln som är konfigurerad för containern eller ta bort replikeringsprincipen. Läs- och borttagningsåtgärder till målcontainern tillåts när replikeringsprincipen är aktiv.

Du kan anropa åtgärden Ange blobnivå på en blob i målcontainern för att flytta den till arkivnivån. Mer information om arkivnivån finns i Åtkomstnivåer för blobdata.

Kommentar

Om du ändrar åtkomstnivån för en blob i källkontot ändras inte åtkomstnivån för den bloben i målkontot.

Principdefinitionsfil

En princip för objektreplikering definieras av JSON-filen. Du kan hämta principdefinitionsfilen från en befintlig objektreplikeringsprincip. Du kan också skapa en princip för objektreplikering genom att ladda upp en principdefinitionsfil.

Exempel på principdefinitionsfil

I följande exempel definieras en replikeringsprincip för målkontot med en enda regel som matchar prefixet b och anger den minsta skapandetiden för blobar som ska replikeras. Kom ihåg att ersätta värden inom vinkelparenteser med dina egna värden:

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

Ange fullständiga resurs-ID:t för käll- och målkontona

När du skapar principdefinitionsfilen anger du fullständiga Azure Resource Manager-resurs-ID:t för källposternaAccount och destinationAccount, som du ser i exemplet i föregående avsnitt. Information om hur du hittar resurs-ID:t för ett lagringskonto finns i Hämta resurs-ID för ett lagringskonto.

Det fullständiga resurs-ID:t är i följande format:

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

Principdefinitionsfilen krävde tidigare endast kontonamnet i stället för det fullständiga resurs-ID:t för lagringskontot. Med introduktionen av säkerhetsegenskapen AllowCrossTenantReplication i version 2021-02-01 av Azure Storage-resursproviderns REST API måste du nu ange det fullständiga resurs-ID:t för alla principer för objektreplikering som skapas när replikering mellan klientorganisationer inte tillåts för ett lagringskonto som deltar i replikeringsprincipen. Azure Storage använder det fullständiga resurs-ID:t för att kontrollera om käll- och målkontona finns i samma klientorganisation. Mer information om hur du inte tillåter replikeringsprinciper mellan klientorganisationer finns i Förhindra replikering mellan Microsoft Entra-klienter.

Även om endast kontonamnet fortfarande stöds när replikering mellan klientorganisationer tillåts för ett lagringskonto rekommenderar Microsoft att du alltid tillhandahåller det fullständiga resurs-ID:t som bästa praxis. Alla tidigare versioner av Azure Storage-resursproviderns REST API-stöd med hjälp av den fullständiga resurs-ID-sökvägen i principer för objektreplikering.

I följande tabell beskrivs vad som händer när du skapar en replikeringsprincip med det fullständiga resurs-ID som angetts, jämfört med kontonamnet, i de scenarier där replikering mellan klientorganisationer tillåts eller inte tillåts för lagringskontot.

Lagringskontoidentifierare i principdefinition Replikering mellan klientorganisationer tillåts Replikering mellan klientorganisationer tillåts inte
Fullständigt resurs-ID Principer för samma klientorganisation kan skapas.

Principer för flera klientorganisationer kan skapas.		 Principer för samma klientorganisation kan skapas.

Det går inte att skapa principer för flera klientorganisationer.
Endast kontonamn Principer för samma klientorganisation kan skapas.

Principer för flera klientorganisationer kan skapas.		 Det går inte att skapa principer för samma klientorganisation eller flera klientorganisationer. Ett fel uppstår eftersom Azure Storage inte kan verifiera att käll- och målkonton finns i samma klientorganisation. Felet anger att du måste ange det fullständiga resurs-ID:t för källkontot och destinationAccount-posterna i principdefinitionsfilen.

Ange princip- och regel-ID:t

I följande tabell sammanfattas vilka värden som ska användas för policyId - och ruleId-posterna i principdefinitionsfilen i varje scenario.

När du skapar principdefinitionsfilen för det här kontot... Ange princip-ID till det här värdet Ange regel-ID:t till det här värdet
Målkonto Standardvärdet för strängen. Azure Storage skapar princip-ID-värdet åt dig. En tom sträng. Azure Storage skapar regel-ID-värden åt dig.
Källkonto Värdet för det princip-ID som returnerades när du laddade ned principdefinitionsfilen för målkontot. Värdena för regel-ID:t som returneras när du laddar ned principdefinitionsfilen för målkontot.

Förhindra replikering mellan Microsoft Entra-klienter

En Microsoft Entra-klientorganisation är en dedikerad instans av Microsoft Entra-ID som representerar en organisation för identitets- och åtkomsthantering. Varje Azure-prenumeration har en förtroenderelation med en enda Microsoft Entra-klientorganisation. Alla resurser i en prenumeration, inklusive lagringskonton, är associerade med samma Microsoft Entra-klientorganisation. Mer information finns i Vad är Microsoft Entra-ID?

Som standard inaktiveras replikering mellan klientorganisationer för nya konton som skapats från och med 15 dec 2023. Om dina säkerhetsprinciper kräver att du begränsar objektreplikering till lagringskonton som endast finns i samma klientorganisation kan du inte tillåta replikering mellan klienter genom att ange en säkerhetsegenskap, egenskapen AllowCrossTenantReplication (förhandsversion). När du inte tillåter replikering av objekt mellan klientorganisationer för ett lagringskonto, och sedan för alla objektreplikeringsprinciper som har konfigurerats med det lagringskontot som käll- eller målkonto, kräver Azure Storage att både käll- och målkontona finns i samma Microsoft Entra-klientorganisation. Mer information om hur du inte tillåter replikering av objekt mellan klientorganisationer finns i Förhindra objektreplikering mellan Microsoft Entra-klienter.

Om du inte vill tillåta replikering av objekt mellan klientorganisationer för ett lagringskonto anger du egenskapen AllowCrossTenantReplication till false. Om lagringskontot för närvarande inte deltar i några replikeringsprinciper för objektreplikering mellan klientorganisationer förhindrar inställningen av egenskapen AllowCrossTenantReplication falskt framtida konfiguration av replikeringsprinciper för objekt mellan klientorganisationer med det här lagringskontot som källa eller mål.

Om lagringskontot för närvarande deltar i en eller flera replikeringsprinciper för objekt mellan klientorganisationer är det inte tillåtet att ange egenskapen AllowCrossTenantReplication till false . Du måste ta bort befintliga principer för flera klientorganisationer innan du kan neka replikering mellan klientorganisationer.

Som standard är egenskapen AllowCrossTenantReplication inställd på false för ett lagringskonto som skapats från och med 15 dec 2023. För lagringskonton som skapats före den 15 december 2023, när värdet för egenskapen AllowCrossTenantReplication för ett lagringskonto är null eller sant, kan behöriga användare konfigurera replikeringsprinciper för objekt mellan klientorganisationer med det här kontot som källa eller mål. Mer information om hur du konfigurerar principer för flera klientorganisationer finns i Konfigurera objektreplikering för blockblobar.

Du kan använda Azure Policy för att granska en uppsättning lagringskonton för att säkerställa att egenskapen AllowCrossTenantReplication har angetts för att förhindra replikering av objekt mellan klientorganisationer. Du kan också använda Azure Policy för att framtvinga styrning för en uppsättning lagringskonton. Du kan till exempel skapa en princip med neka-effekten för att förhindra att en användare skapar ett lagringskonto där egenskapen AllowCrossTenantReplication är inställd på true eller från att ändra ett befintligt lagringskonto för att ändra egenskapsvärdet till true.

Replikeringsstatus

Du kan kontrollera replikeringsstatusen för en blob i källkontot. Mer information finns i Kontrollera replikeringsstatus för en blob.

Kommentar

Medan replikeringen pågår finns det inget sätt att fastställa procentandelen data som har replikerats.

Om replikeringsstatusen för en blob i källkontot indikerar ett fel undersöker du följande möjliga orsaker:

  • Kontrollera att objektreplikeringsprincipen har konfigurerats för målkontot.
  • Kontrollera att målkontot fortfarande finns.
  • Kontrollera att målcontainern fortfarande finns.
  • Kontrollera att målcontainern inte håller på att tas bort eller att den inte bara har tagits bort. Det kan ta upp till 30 sekunder att ta bort en container.
  • Kontrollera att målcontainern fortfarande deltar i objektreplikeringsprincipen.
  • Om källbloben har krypterats med en kundbaserad nyckel som en del av en skrivåtgärd misslyckas objektreplikeringen. Mer information om kundspecifika nycklar finns i Ange en krypteringsnyckel på en begäran till Blob Storage.
  • Kontrollera om käll- eller målbloben har flyttats till arkivnivån. Arkiverade blobar kan inte replikeras via objektreplikering. Mer information om arkivnivån finns i Åtkomstnivåer för blobdata.
  • Kontrollera att målcontainern eller bloben inte skyddas av en oföränderlig princip. Tänk på att en container eller blob kan ärva en oföränderlighetsprincip från dess överordnade. Mer information om oföränderlighetsprinciper finns i Översikt över oföränderlig lagring för blobdata.

Funktionsstöd

Stöd för den här funktionen kan påverkas genom att aktivera Data Lake Storage Gen2, NFS 3.0-protokoll (Network File System) eller SSH File Transfer Protocol (SFTP). Om du har aktiverat någon av dessa funktioner kan du läsa Stöd för Blob Storage-funktioner i Azure Storage-konton för att utvärdera stödet för den här funktionen.

Fakturering

Det kostar ingenting att konfigurera objektreplikering. Detta omfattar uppgiften att aktivera ändringsflöde, aktivera versionshantering och lägga till replikeringsprinciper. Objektreplikering medför dock kostnader för läs- och skrivtransaktioner mot käll- och målkontona, samt utgående avgifter för replikering av data från källkontot till målkontot och läsavgifter för att bearbeta ändringsflöde.

Här är en uppdelning av kostnaderna. Information om hur du hittar priset för varje kostnadskomponent finns i Prissättning för Azure Blob Storage.

Kostnad för att uppdatera en blob i källkontot Kostnad för att replikera data i målkontot
Transaktionskostnad för en skrivåtgärd Transaktionskostnad för att läsa en ändringsflödespost
Lagringskostnad för bloben och varje blobversion1 Transaktionskostnad för att läsa blob- och blobversionerna2
Kostnad för att lägga till en ändringsflödespost Transaktionskostnad för att skriva blob- och blobversionerna2
Lagringskostnad för bloben och varje blobversion1
Kostnad för utgåendenätverk 3

1 Om du inte har ändrat en blob eller versionsnivå på källkontot debiteras du för unika datablock i blobben, dess versioner. Se Prissättning för blobversioner och fakturering. För en version på målkontot debiteras du för alla block i en version oavsett om dessa block är unika eller inte.

2 Detta omfattar endast blobversioner som skapats sedan den senaste replikeringen slutfördes.

3 Objektreplikering kopierar hela versionen till målet (inte bara de unika blocken i versionen). Den här överföringen medför kostnaden för nätverkets utgående trafik. Se Priser för bandbredd.

Dricks

För att minska risken för en oväntad faktura aktiverar du objektreplikering i ett konto som bara innehåller ett litet antal objekt. Mät sedan effekten på kostnaden innan du aktiverar funktionen i en produktionsinställning.

Nästa steg