Objektreplikering för blockblobar

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

  • Minimera svarstiden. Objektreplikering minskar latens för läsförfrågningar genom att möjliggöra för klienter att konsumera data från en region 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 datadistributionen. Du kan bearbeta eller analysera data på en enda plats och sedan bara replikera resultaten till extra regioner.
  • Optimera kostnader. Efter att din data har replikerats kan du minska kostnaderna genom att flytta den till arkivnivån med hjälp av livscykelhanteringspolicys.

Följande diagram visar hur objektreplikering replikerar blockblobar från en källa storage konto 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å prissidan Azure Storage.

Objektreplikering stödjer allmänna v2-lagringskonton och premiumblockblob-konton. Både käll- och målkontona måste vara antingen allmänna v2- eller Premium-blockblobkonton. Objektreplikering stöder endast blockblobar; den stöder inte append-blobs och sidblobar.

Objektreplikering stödjer 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öder inte blobs i källkontot som är krypterade med en nyckel som tillhandahålls av kunden. Mer information om kundtillhandahållna nycklar finns i Tillhandahåll en krypteringsnyckel vid en begäran till Blob-lagring.

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

Objektreplikering stöds inte i konton som har ett hierarkiskt namnrymd aktiverat.

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

Så här fungerar objektreplikering

Objektreplikering kopierar asynkront blockblobbar i en container enligt de regler som du konfigurerar. Tjänsten kopierar innehållet i blobben, eventuella versioner kopplade till blobben, samt blobbens metadata och egenskaper från källcontainern till destinationscontainern.

Viktigt!

Eftersom blockblobdata replikeras asynkront synkroniseras inte källkontot och målkontot omedelbart.

Objektreplikering (OR) stöder nu prioriterad replikering, vilket prioriterar replikering av alla operationer i en ELLER-policy. När OR-prioriterad replikering aktiveras förbättras replikationsprestandan för alla operationer. När käll- och målkontot för en replikeringsprincip finns på samma kontinent, replikerar även OR-prioritetsreplikering 99,0 % av objekten inom 15 minuter för arbetsbelastningar som stöds. Funktionsprestanda garanteras med ett serviceavtal (SLA). För mer information, se SLA-villkoren och artikeln Objektreplikering med prioritetsreplikering.

Du kan också kontrollera replikeringsstatusen för 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 du aktiverar blobversionering på både käll- och destinationskontot. När du modifierar en replikerad blob i källkontot skapar tjänsten en ny version av blobben i källkontot som speglar blobens tidigare tillstånd innan modifieringen. Den aktuella versionen i källkontot återspeglar de senaste uppdateringarna. Tjänsten replikerar både den aktuella versionen och tidigare versioner till destinationskontot. Mer information om hur skrivåtgärder påverkar blobversioner finns i Versionshantering vid skrivåtgärder.

Om ditt storage-konto 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.

Anteckning

Endast blobar kopieras till målet. Tjänsten kopierar inte en blobs versions-ID. Efter att tjänsten placerat en blob på destinationsplatsen tilldelar den ett nytt versions-ID.

Ta bort en blob i källkontot

När du tar bort en blob i källkontot blir den aktuella versionen av blobben en tidigare version, och det finns inte längre någon aktuell version. Tjänsten bevarar alla befintliga tidigare versioner av blobben. Tjänsten replikerar detta tillstånd till destinationskontot. För mer information om hur borttagningsoperationer påverkar blobversioner, se Versionshantering av borttagningsoperationer.

Snabbfotografier

Objektreplikering stöder inte blobögonblicksbilder. Tjänsten replikerar inga snapshots från en blob i källkontot till destinationskontot.

Taggar för blobindex

Objektreplikering stöder nu kopiering av indextaggar från källblobar till målblobar. Du kan konfigurera den här funktionen som en del av en ny eller befintlig replikeringsregel. Mer information finns i Konfigurera objektreplikering.

Viktigt!

Replikering av taggar är för närvarande i förhandsversion. Se Tilläggsvillkor för användning av Microsoft Azure Preview-funktioner för juridiska villkor som gäller för Azure-funktioner som är i beta, förhandsgranskning eller andra som ännu inte släppts för allmän tillgänglighet.

Blob-nivåindelning

Objektreplikering stöds när käll- och målkontona finns på någon onlinenivå (frekvent, lågfrekvent eller kall). Käll- och målkontona kan finnas på olika nivåer. Objektreplikeringen misslyckas dock om en blob i käll- eller målkontot flyttas till arkivnivån. Att återfukta en arkiverad blob utlöser inte objektreplikering. Objektreplikering utlöses endast när blobdata uppdateras igen efter uttorkning. För ytterligare information om bloblager, se Åtkomstlager för blobdata.

Blobar som inte kan ändras

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

Om målcontainern har en princip för oföränderlighet på containernivå kan ändringar av objekt i källcontainern, till exempel uppdateringar eller borttagningar, fortfarande lyckas. Dessa ändringar kan dock misslyckas med att replikera till målcontainern på grund av den oföränderliga begränsningen. 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 ett målkontos blobversion har en aktiv princip för oföränderlighet på versionsnivå kan en borttagnings- eller uppdateringsåtgärd som utförs på motsvarande källcontainer blobversion lyckas. Replikeringen av åtgärden till målobjektet misslyckas dock. För mer information om vilka operationer som är förbjudna med en oföränderlighetspolicy som är begränsad till en version, se Scenarier med versionsnivå-omfattning.

Principer och regler för objektreplikering

När du konfigurerar objektreplikering skapar du en replikeringsprincip som anger lagringskontot för källan och målkontot. En replikeringsprincip innehåller en eller flera regler som anger en käll- och målcontainer och anger vilka källblobar som 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 replikeringspolicy på destinationskontot via Azure Storage-resursleverantören. Efter att du skapat replikeringspolicyn tilldelar Azure Storage den ett policy-ID. Du måste sedan associera replikeringsprincipen med källkontot med hjälp av princip-ID:t. Policy-ID:t på käll- och destinationskontot måste vara detsamma för att replikering ska kunna genomfö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 klientorganisationer. Du kan bara skapa en replikeringspolicy för varje käll- och destinationskontopar.

Replikeringsregler

Replikeringsregler anger hur Azure Storage replikerar 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. Därför kan högst 1 000 källcontainrar och 1 000 målcontainrar delta i en enda replikeringsprincip.

När du har skapat en replikeringsregel ignoreras befintliga blobar. endast nya blockblobar som har lagts till efter att regeln har skapats kopieras som standard. Du kan dock ange att både nya och befintliga blockblobar kopieras. Du kan också definiera ett anpassat kopieringsomfång som kopierar alla blockblobar som skapats efter en angiven tid.

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 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 med en replikeringsregel måste du först inaktivera replikeringen. Du kan inaktivera regeln genom att antingen ta bort den för den containern eller genom att ta bort hela replikeringspolicyn.

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.

Anteckning

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

Principdefinitionsfil

Använd en JSON-fil för att definiera en objektreplikeringspolicy. Du kan hämta principdefinitionsfilen från en befintlig objektreplikeringsprincip eller skapa en objektreplikeringsprincip genom att ladda upp en principdefinitionsfil.

Exempel på principdefinitionsfil

I följande exempel anges en replikeringsprincip för målkontot med en regel. Regeln riktar in sig på blobar med prefixet b och anger en minsta skapandetid för replikering. 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>",
    "metrics": {
		  "enabled": false
    },
    "priorityReplication": "false",
    "rules": [
      {
        "ruleId": "",
        "sourceContainer": "<source-container>",
        "destinationContainer": "<destination-container>",
        "filters": {
          "prefixMatch": [
            "b"
          ],
          "minCreationTime": "2021-08-28T00:00:00Z"
        }
      }
    ]
  }
}

Anpassade filter

Du kan anpassa filter med olika alternativ i en JSON-fil:

  • Matcha blobs med prefix — replikera endast blobbar vars namn börjar med bokstaven b.
"filters": {
          "prefixMatch": [
            "b"
          ],
        }
  • Matcha blobs efter skapandetid — replikera endast blobs som skapats på eller efter den angivna tiden.
"filters": {
  "minCreationTime": "2021-08-28T00:00:00Z"
}
  • Replikera alla blobbar — ange den minsta tiden för skapande till det tidigaste möjliga värdet.
"filters": {
  "minCreationTime": "1601-01-01T00:00:00Z"
}

Ange fullständiga resurs-ID:n för källkonto och mål-konto

När du skapar principfilen anger du de fullständiga Azure Resource Manager resurs-ID:n för sourceAccount och destinationAccount inlägg, som du ser i exemplet i föregående avsnitt. Information om hur du hittar resurs-ID:t för ett storage-konto finns i Hämta resurs-ID:t för ett storage-konto.

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 storage-kontot. Med introduktionen av säkerhetsegenskapen AllowCrossTenantReplication i version 2021-02-01 av Azure Storage-resursleverantörens REST API, måste du nu ange hela resurs-ID för alla objektreplikeringspolicyer du skapar när cross-tenant replikering inte tillåts för ett lagringskonto som deltar i replikeringspolicyn. 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 förhindrar replikeringsprinciper mellan klientorganisationer finns i Förhindra replikering mellan Microsoft Entra klienter.

Även om endast kontonamnet fortfarande stöds för replikering mellan klientorganisationer rekommenderar Microsoft att du använder det fullständiga resurs-ID:t som bästa praxis. Alla tidigare versioner av REST API för resursleverantören Azure Storage stödjer användningen av hela resurs-ID-sökvägen i objektreplikationsprinciper.

Följande tabell visar hur replikeringsprincipens beteende skiljer sig när du använder ett fullständigt resurs-ID jämfört med ett kontonamn. Jämförelsen beror på om replikering mellan klientorganisationer tillåts för storage-kontot.

Lagringskontots identifierare i policydefinition Replikering mellan klientorganisationer tillåts Replikering mellan klientorganisationer tillåts inte
Fullständigt resurs-ID Policyer för samma hyresgäst kan skapas.

Principer för övergripande klientorganisationer kan skapas.		 Policyer för samma hyresgäst kan skapas.

Det går inte att skapa tvärgående principer för klientorganisationer.
Endast kontonamn Policyer för samma hyresgäst kan skapas.

Principer för övergripande klientorganisationer kan skapas.		 Det går inte att skapa principer för samma klientorganisation eller flera klientorganisationer. Ett fel inträffar 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 Strängvärdet default. Azure Storage skapar princip-ID-värdet åt dig. En tom sträng. Azure Storage skapar regel-ID-värdena åt dig.
Källkonto Värdet för det policy-ID som returnerades när du hämtade policydokumentationsfilen för målkontot. Värdena för regel-ID:erna som returneras när du laddar ner policyns definitionsfil för målkontot.

Förhindra replikering mellan Microsoft Entra klientorganisationer

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 den 15 december 2023. Om dina säkerhetsprinciper kräver att du begränsar objektreplikering till lagringskonton som endast finns i samma klientorganisation, kan du förhindra replikering mellan klientorganisationer genom att ställa in en säkerhetsegenskap, egenskapen AllowCrossTenantReplication (förhandsversion). När du inaktiverar replikering av objekt mellan klientorganisationer för ett lagringskonto, inför Azure Storage ytterligare ett krav. För alla objektreplikeringsprinciper som använder det här lagringskontot som källa eller mål måste båda kontona tillhöra samma Microsoft Entra klientorganisation. Mer information om hur du inte tillåter replikering av objekt mellan klientorganisationer finns i Prevent object replication across Microsoft Entra tenants.

Om du inte vill tillåta replikering av objekt mellan klientorganisationer för ett storage konto anger du egenskapen AllowCrossTenantReplication till false. Om lagringskontot för närvarande inte deltar i några replikeringsprinciper för objekt mellan klientorganisationer, kan du ange egenskapen AllowCrossTenantReplication till false, vilket förhindrar 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 ställa in 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 storage konto som skapats från och med den 15 december 2023. För lagringskonton som skapades före den 15 december 2023, när värdet för egenskapen AllowCrossTenantReplication för ett lagringskonto är null eller true, kan sedan behöriga användare konfigurera replikeringsprinciper för objekt mellan tenanter 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 är inställd 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 effekten deny för att förhindra att en användare skapar ett storage konto där egenskapen AllowCrossTenantReplication anges till true, eller från att ändra ett befintligt storage konto för att ändra egenskapsvärdet till true.

Replikeringsmått

Objektreplikering stöder två mått för att ge dig insikter om replikeringsförloppet:

  • Operationer väntar på replikering: Totalt antal operationer som väntar på replikering från källa till mållagringskonto som genereras i enlighet med tidsintervaller.
  • Antal byte väntar på replikering: Summan av byte som väntar på replikering från källa till mål lagringskonton som genereras per tidsintervall

Var och en av de mått som listades tidigare kan visas med tidsintervall som dimension. Den här uppdelningen ger insikter om hur många byte eller åtgärder som väntar på replikering i varje tidsintervall som följer:

  • 0–5 minuter
  • 5–10 minuter
  • 10–15 minuter
  • 15–30 minuter
  • 30 min-2 timmar
  • 2-8 timmar
  • 8-24 timmar
  • >24 timmar

Följande exempelbild visar måttet pågående åtgärd och bytesmått för de föregående sju dagarna.

Objektreplikeringsmetrik som visar väntande åtgärder och väntande byteantal under en sju-dagarsperiod

Du kan aktivera replikeringsmått på källkontot för övervakning av väntande byte och väntande åtgärder. Mer information finns i Konfigurera replikeringsmått.

Replikeringsstatus

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

Anteckning

Medan replikationen pågår finns det inget sätt att avgöra procentandelen replikerade data.

Om replikationsstatusen för en blob i källkontot indikerar misslyckande, undersök följande möjliga orsaker:

  • Se till att objektreplikeringspolicyn är konfigurerad på destinationskontot.
  • Kontrollera att målkontot fortfarande finns.
  • Kontrollera att målcontainern fortfarande finns.
  • Kontrollera att målcontainern inte tas bort och inte håller på att tas bort. Det kan ta upp till 30 sekunder att ta bort en container.
  • Kontrollera att målcontainern fortfarande deltar i objektreplikeringsprincipen.
  • Om källbloben krypteras med en kundbaserad nyckel som en del av en skrivåtgärd misslyckas objektreplikeringen. Mer information om kundtillhandahållna nycklar finns i Tillhandahåll en krypteringsnyckel vid en begäran till Blob-lagring.
  • Kontrollera om käll- eller målbloben flyttas 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ålcontainer eller blob inte skyddas av en oföränderlighetspolicy. En container eller blob kan ärva en oföränderlighetspolicy från sin förälder. Mer information om principer för oföränderlighet finns i Översikt över oföränderlig lagring för blobdata.

Funktionalitetssupport

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

Fakturering

Det kostar inget att konfigurera objektreplikering, inklusive att aktivera ändringsflöde, versionshantering och replikeringspolicyer. Objektreplikering medför dock kostnader för läs- och skrivtransaktioner mot käll- och målkontona. Utgångsavgifter för replikering av data från källkontot till destinationskontot medför också kostnader, liksom läsavgifter vid bearbetning av ändringsflöde.

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

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
Kostnad för lagring av 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
Kostnader för datahämtning på lågfrekventa och kalla nivåer Kostnad för lagring av bloben och varje blobversion1
Kostnad för nätverksutgång3

1 På källkontot, om en blob eller versions nivå är oförändrad, faktureras du för unika datablock över den blobben och dess versioner. Se Prissättning och fakturering för blobversionering. På destinationskontot, för en version, faktureras du för alla block i en version, oavsett om dessa block är unika eller inte.

2 Denna kostnad inkluderar endast blob-versioner 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. See bandbreddspriser.

Tips

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

Nästa steg

  • Last updated on