Dela via

Åtkomstnivåer för blobdata

  • Artikel

Data som lagras i molnet växer i exponentiell takt. Om du vill hantera kostnader för dina växande lagringsbehov kan det vara bra att organisera dina data baserat på hur ofta de används och hur länge de ska behållas. Azure Storage erbjuder olika åtkomstnivåer så att du kan lagra dina blobdata på det mest kostnadseffektiva sättet baserat på hur de används. Azure Storage-åtkomstnivåer omfattar:

  • Frekvent nivå – en onlinenivå som är optimerad för att lagra data som används eller ändras ofta. Den varma nivån har de högsta lagringskostnaderna, men de lägsta åtkomstkostnaderna.
  • Lågfrekvent nivå – en onlinenivå som är optimerad för lagring av data som sällan används eller ändras. Data på lågfrekvent nivå ska lagras i minst 30 dagar. Den kalla nivån har lägre lagringskostnader och högre åtkomstkostnader jämfört med den varma nivån.
  • Kall nivå – En onlinenivå som är optimerad för att lagra data som sällan används eller ändras, men som fortfarande kräver snabb hämtning. Data på den kalla nivån ska lagras i minst 90 dagar. Den kalla lagringsnivån har lägre lagringskostnader och högre åtkomstkostnader jämfört med den svala lagringsnivån.
  • Arkivnivå – en offlinenivå som är optimerad för lagring av data som sällan används och som har flexibla svarstidskrav i timmar. Data på arkivnivån ska lagras i minst 180 dagar.

Kapacitetsbegränsningar för Azure Storage anges på kontonivå i stället för enligt åtkomstnivå. Du kan välja att maximera din kapacitetsanvändning på en nivå eller att distribuera kapacitet över två eller flera nivåer.

Kommentar

Att ange åtkomstnivån tillåts endast för blockblobar. De stöds inte för tilläggs- och sidblobar.

Onlineåtkomstnivåer

När dina data lagras på en onlineåtkomstnivå (antingen frekvent, lågfrekvent eller kall) kan användarna komma åt dem omedelbart. Den frekventa nivån är det bästa valet för data som används aktivt. Lågfrekvent eller kall nivå är idealisk för data som används mindre ofta, men som fortfarande måste vara tillgängliga för läsning och skrivning.

Exempel på användningsscenarier för den varma nivån är:

  • Data som används aktivt eller data som du förväntar dig kräver frekventa läsningar och skrivningar.
  • Data som mellanlagras för bearbetning och eventuell migrering till lågfrekvent åtkomstnivå.

Användningsscenarier för lågfrekvent och kall åtkomstnivå omfattar:

  • Kortsiktig datorsäkerhetskopiering och katastrofåterställning.
  • Äldre datamängder som inte används ofta, men som förväntas vara tillgängliga för omedelbar åtkomst.
  • Stora datamängder som måste lagras på ett kostnadseffektivt sätt medan andra data samlas in för bearbetning.

Information om hur du flyttar en blob till frekvent, lågfrekvent eller kall nivå finns i Ange en blobs åtkomstnivå.

Data på lågfrekvent och kall nivå har något lägre tillgänglighet, men har samma höga hållbarhet, svarstid och dataflödesegenskaper som den frekventa nivån. För data på lågfrekvent eller kall nivå kan något lägre tillgänglighet och högre åtkomstkostnader vara godtagbara kompromisser för lägre totala lagringskostnader jämfört med den frekventa nivån. Mer information finns i SLA för Storage.

Blobar omfattas av en straffavgift för tidig borttagning om de tas bort, skrivs över eller flyttas till en annan nivå innan det minimiantal dagar som krävs av nivån har passerat. Till exempel kan en blob på kall nivå i ett generellt v2-konto drabbas av en tidig borttagningsavgift om den tas bort eller flyttas till en annan nivå innan 30 dagar har förflutit. För en blob på den kalla nivån gäller borttagningsstraffet om den tas bort eller flyttas till en annan nivå innan 90 dagar har gått. Den här kostnaden beräknas proportionellt. Om en blob till exempel flyttas till lågfrekvent nivå och sedan tas bort efter 21 dagar debiteras du en avgift för tidig borttagning som motsvarar 9 (30 minus 21) dagar för lagring av blobben på lågfrekvent nivå. Avgifter för tidig borttagning sker också om hela objektet skrivs om via någon åtgärd (t.ex. placera blob, placera blockeringslista eller kopiera blob) inom det angivna tidsfönstret. Den här avgiften beräknas proportionellt baserat på datalagringspriset för motsvarande nivå, dvs. om du tar bort en arkiverad blob efter 120 dagar debiteras objektet i 180 dagar.

Kommentar

I ett konto som har mjuk borttagning aktiverat betraktas en blob som borttagen när den har tagits bort och kvarhållningsperioden upphör att gälla. Tills den perioden upphör att gälla är bloben endast mjukraderad och omfattas inte av avgiften för tidig borttagning.

Nivåerna frekvent, lågfrekvent och kall stöder alla redundanskonfigurationer. Mer information om alternativ för dataredundans i Azure Storage finns i Redundans för Azure Storage.

Arkivtillgångsnivå

Arkivnivån är en offlinenivå för lagring av data som sällan används. Arkivåtkomstnivån har den lägsta lagringskostnaden. Den här nivån har dock högre kostnader för datahämtning med högre svarstid jämfört med nivåerna frekvent, lågfrekvent och kall. Exempel på användningsscenarier för arkivåtkomstnivån är:

  • Långsiktig säkerhetskopiering, sekundär säkerhetskopiering och datauppsättningar för arkivering
  • Ursprungliga (rådata) som måste bevaras, även efter att de har bearbetats till slutlig användbar form
  • Efterlevnads- och arkiveringsdata som behöver lagras under lång tid och som nästan aldrig nås

Information om hur du flyttar en blob till arkivnivån finns i Arkivera en blob.

Data måste ligga kvar på arkivlagringsnivån i minst 180 dagar, annars debiteras du en avgift för tidig borttagning. Om en blob till exempel flyttas till arkivnivån och sedan tas bort eller flyttas till den frekventa nivån efter 45 dagar debiteras du en avgift för tidig borttagning som motsvarar 135 (180 minus 45) dagar efter lagring av blobben på arkivnivån.

Kommentar

I ett konto som har mjuk borttagning aktiverat betraktas en blob som borttagen när den har tagits bort och kvarhållningsperioden upphör att gälla. Tills den perioden upphör att gälla är bloben endast mjukraderad och omfattas inte av avgiften för tidig borttagning.

När en blob finns på arkivnivån kan den inte läsas eller ändras. Om du vill läsa eller ladda ned en blob på arkivnivån måste du först återställa den till en onlinenivå, antingen varm, sval eller kall. Data i arkivlagret kan ta upp till 15 timmar att återställa, beroende på vilken prioritet du anger för återställningsprocessen. Mer information om blobrehydrering finns i Översikt över blobrehydrering från arkivnivån.

Metadata för en arkiverad blob förblir tillgängliga för läsåtkomst, så att du kan lista bloben och dess egenskaper, metadata och indextaggar. Metadata för en blob på arkivnivån är skrivskyddad, medan blobindextaggar kan läsas eller skrivas. Lagringskostnader för metadata för arkiverade blobar debiteras enligt kall nivå-priser. Ögonblicksbilder stöds inte för arkiverade blobar.

Följande åtgärder stöds för blobar på arkivnivån:

Endast lagringskonton som har konfigurerats för LRS, GRS eller RA-GRS stöder flytt av blobar till arkivnivån. Arkivnivån stöds inte för ZRS-, GZRS- eller RA-GZRS-konton. Mer information om redundanskonfigurationer för Azure Storage finns i Redundans för Azure Storage.

Om du vill ändra redundanskonfigurationen för ett lagringskonto som innehåller blobar på arkivnivån måste du först återställa alla arkiverade blobar till den varma, svala eller kalla nivån. Eftersom återfuktningsåtgärder kan vara kostsamma och tidskrävande rekommenderar Microsoft att du undviker att ändra redundanskonfigurationen för ett lagringskonto som innehåller arkiverade blobar.

Migrering av ett lagringskonto från LRS till GRS stöds så länge inga blobar har flyttats till arkivnivån medan kontot har konfigurerats för LRS. Ett konto kan flyttas tillbaka till GRS om uppdateringen utförs mindre än 14 dagar från det att kontot blev LRS och inga blobar flyttades till arkivnivån medan kontot var inställt på LRS.

Standardinställning för kontoåtkomstnivå

Lagringskonton har en standardinställning för åtkomstnivå som anger den onlinenivå där en ny blob skapas. Standardinställningen för åtkomstnivå kan vara antingen varm, sval eller kall. Användare kan åsidosätta standardinställningen för en enskild blob när de laddar upp bloben eller ändrar dess nivå.

Standardåtkomstnivån för ett nytt generellt v2-lagringskonto är som standard inställd på den frekventa nivån. Du kan ändra standardinställningen för åtkomstnivå när du skapar ett lagringskonto eller när det har skapats. Om du inte ändrar den här inställningen på lagringskontot eller uttryckligen anger nivån när du laddar upp en blob, laddas en ny blob upp till den frekventa nivån som standard.

En blob som inte har en uttryckligen tilldelad nivå härleder nivån från standardinställningen för kontoåtkomstnivå. Om en blobs åtkomstnivå härleds från standardinställningen för kontoåtkomstnivå visar Azure Portal åtkomstnivån som Frekvent (härledd), Lågfrekvent (härledd) eller Kall (härledd).

Att ändra standardinställningen för åtkomstnivå för ett lagringskonto gäller för alla blobar i kontot som en åtkomstnivå inte uttryckligen har angetts för. Om du ändrar standardinställningen för åtkomstnivå till en lågfrekvent nivå i ett generellt v2-konto debiteras du för skrivåtgärder (per 10 000) för alla blobbar som åtkomstnivån härleds till. Du debiteras för både läsåtgärder (per 10 000) och datahämtning (per GB) om du växlar till en varmare nivå i ett generellt v2-konto.

När du skapar ett klassiskt Blob Storage-konto måste du ange standardinställningen för åtkomstnivå som varm eller kall vid skapandet. Det kostar inget att ändra standardinställningen för kontoåtkomstnivå till en lågfrekvent nivå i ett äldre Blob Storage-konto. Du debiteras för både läsåtgärder (per 10 000) och datahämtning (per GB) om du växlar till en varmare nivå i ett Blob Storage-konto. Microsoft rekommenderar att du använder allmänna v2-lagringskonton i stället för Blob Storage-konton när det är möjligt.

Kommentar

Arkivnivån stöds inte som standardåtkomstnivå för ett lagringskonto.

Ange eller ändra blobbens nivå

Om du uttryckligen vill ange en blobnivå när du skapar den anger du nivån när du laddar upp bloben.

När en blob har skapats kan du ändra dess nivå på något av följande sätt:

  • Genom att anropa åtgärden Ange blobnivå, antingen direkt eller via en princip för livscykelhantering. Att anropa Ange blobnivå är vanligtvis det bästa alternativet när du ändrar en blobnivå från en varmare nivå till en svalare nivå.

    Kommentar

    Du kan inte återställa en arkiverad blob till en onlinenivå med hjälp av livscykelhanteringsprinciper.

  • Genom att anropa åtgärden Kopiera blob för att kopiera en blob från en nivå till en annan. Att anropa Copy Blob rekommenderas för de flesta scenarier där du rehydrerar en blob från arkivnivån till en onlinenivå eller flyttar en blob från cool eller kall till het. Genom att kopiera en blob kan du undvika den tidiga borttagningsstraffet om det nödvändiga lagringsintervallet för källbloben ännu inte har förflutit. Att kopiera en blob resulterar dock i kapacitetsavgifter för två blobar, källbloben och målbloben.

Att ändra en blobs nivå från en varmare nivå till en kyligare är omedelbart, liksom att byta från kall eller kyla till varm. Det kan ta upp till 15 timmar att överföra en blob från arkivnivån till en onlinenivå, till exempel den varma, svala eller kalla nivån.

Tänk på följande när du ändrar en blob-nivå:

  • Du kan inte använda Ange blobnivå för att arkivera en blob som använder ett krypteringsomfång. Du kan bara använda Ange blobnivå för att flytta mellan onlineåtkomstnivåer. Mer information om krypteringsomfång finns i Krypteringsomfång för Blob Storage.

  • Om en blob uttryckligen flyttas till lågfrekvent eller kall nivå och sedan flyttas till arkivnivån gäller den tidiga borttagningsavgiften.

Livscykelhantering för blob

Livscykelhantering för Blob Storage erbjuder en regelbaserad princip som du kan använda för att överföra dina data till önskad åtkomstnivå när dina angivna villkor uppfylls. Du kan också använda livscykelhantering för att avsluta livslängden för data när dess livslängd löper ut. Mer information finns i Optimera kostnader genom att automatisera Åtkomstnivåer för Azure Blob Storage.

Du kan inte återställa en arkiverad blob till en onlinenivå med hjälp av livscykelhanteringsprinciper. Data som lagras i ett premium blockbloblagringskonto kan inte nivåindelas till varm, sval, kall eller arkiv genom att använda Ange blobnivå eller livscykelhantering för Azure Blob Storage. Om du vill flytta data måste du synkront kopiera blobar från blockbloblagringskontot till nivån "hot" i ett annat konto med API:et Put Block From URL eller en version av AzCopy som stöder detta API. API:et Put Block From URL kopierar synkront data på servern, vilket innebär att anropet bara slutförs när alla data har flyttats från den ursprungliga serverplatsen till målplatsen.

Lagringsåtgärder

Livscykelhantering hjälper dig att flytta data mellan nivåer i ett enda konto, men du kan använda en lagringsuppgift för att utföra den här uppgiften i stor skala över flera konton. En lagringsuppgift är en resurs som är tillgänglig i Azure Storage Actions. Ett serverlöst ramverk som du kan använda för att utföra vanliga dataåtgärder på miljontals objekt i flera lagringskonton. Mer information finns i Vad är Azure Storage Actions?.

Sammanfattning av alternativ för åtkomstnivå

I följande tabell sammanfattas funktionerna för nivåerna het, sval, kall och arkivåtkomst.

Frekvent nivå Lågfrekvent nivå Kall nivå Arkivnivå
Tillgänglighet 99,9 % 99 % 99 % 99 %
Tillgänglighet
(RA-GRS läser)		 99,99 % 99,9 % 99,9 % 99,9 %
Förbrukningsavgifter Högre lagringskostnader, men lägre åtkomst- och transaktionskostnader Lägre lagringskostnader, men högre åtkomst- och transaktionskostnader Lägre lagringskostnader, men högre åtkomst- och transaktionskostnader Lägsta lagringskostnader, men högsta åtkomst- och transaktionskostnader
Minsta rekommenderade datakvarhållningsperiod Ej tillämpligt 30 dagar1 90 dagar1 180 dagar
Svarstider
(Tid till första byte)		 Millisekunder Millisekunder Millisekunder Timmar2
Redundanskonfigurationer som stöds Alla Alla Alla Endast LRS, GRS och RA-GRS3

1 Objekt på kallnivå på allmänna v2-konton har en minsta kvarhållningstid på 30 dagar. Objekt på den kalla nivån på konton för generell användning v2 har en minsta kvarhållningstid på 90 dagar. För Blob Storage-konton finns det ingen minsta kvarhållningstid för lågfrekvent eller kall nivå.

2 När du rehydrerar en blob från arkivnivån kan du välja antingen en standard- eller hög rehydreringsprioritet. Var och en erbjuder olika svarstider och kostnader för hämtning. Mer information finns i Översikt över blobrehydrering från arkivnivån.

3 Mer information om redundanskonfigurationer i Azure Storage finns i Azure Storage-redundans.

Prissättning och fakturering

Alla lagringskonton använder en prismodell för blockbloblagring som baseras på en blobnivå. Tänk på de faktureringsöverväganden som beskrivs i följande avsnitt.

Mer information om priser för blockblobar finns i Blockblobpriser.

Kostnader för lagringskapacitet

Förutom mängden data som lagras varierar kostnaden för att lagra data beroende på åtkomstnivå. Kapacitetskostnaden per gigabyte minskar när nivån blir svalare.

Kostnader för dataåtkomst

Avgifterna för dataåtkomst ökar när prisklassen blir mindre viktig. För data på lågfrekvent, kall och arkiverad åtkomstnivå debiteras du en dataåtkomstavgift per gigabyte för läsningar.

Transaktionskostnader

En avgift per transaktion gäller för alla nivåer och ökar när nivån blir svalare.

Kostnader för dataöverföring med geo-replikering

Den här avgiften gäller endast konton med konfigurerad geo-replikering, inklusive GRS, RA-GRS och GZRS. Dataöverföring för geo-replikering debiteras per gigabyte.

Kostnader för utgående dataöverföring

Utgående dataöverföringar (data som överförs från en Azure-region) debiteras för bandbreddsanvändning per gigabyte. Mer information om avgifter för utgående dataöverföring finns på sidan Prisinformation för bandbredd.

Ändra standardkontoåtkomstnivån

Om kontoåtkomstnivån ändras tillkommer nivåändringsavgifter för alla blobar som inte redan har en uttrycklig nivå angiven. Mer information finns i följande avsnitt, Ändra åtkomstnivån för en blob.

Ändra åtkomstnivån för en blob

Tänk på följande påverkan på fakturering när du ändrar en blobs nivå:

  • När en blob laddas upp eller flyttas mellan nivåer debiteras den med motsvarande hastighet omedelbart vid uppladdning eller nivåändring.
  • När en blob flyttas till en kallare nivå debiteras åtgärden som en skrivåtgärd till målnivån, där avgifterna för skrivåtgärder (per 10 000 åtgärder) och dataskrivning (per GB) för målnivån tillämpas.
  • När en blob flyttas till en varmare nivå debiteras åtgärden som en läsning från källnivån, där läsåtgärden (per 10 000) och avgifter för datahämtning (per GB) för källnivån tillämpas. Avgifter för tidig borttagning för alla blobar som flyttas från den svala, kalla eller arkivnivån kan också gälla.
  • När en blob återställs från arkivlagret faktureras blobens data som arkiverade data tills datan återställs och blobens nivå ändras till varm, sval eller kall.

I följande tabell sammanfattas hur nivåändringar faktureras.

Skrivavgifter (åtgärd + åtkomst) Avgifter för läsning (drift + åtkomst)
Från varm till sval
Varmt till kallt
Hett att arkivera
Sval till kall
Häftigt att arkivera
Förflyttning till arkivering		 Arkivera till kallförvaring
Arkivera för nedkylning
Arkivera till frekvent
Kallt till svalt
Kall till varm
Sval till varm

Om du ändrar åtkomstnivån för en blob när versionshantering är aktiverat, eller om blobben har ögonblicksbilder, kan det leda till fler avgifter. Information om blobar med versionshantering aktiverat finns i Prissättning och fakturering i dokumentationen för blobversioner. Information om blobar med ögonblicksbilder finns i dokumentationen för blobögonblicksbilder under Prissättning och fakturering.

Kall kategori

Den kalla nivån kräver följande minimiversioner av REST, SDK:er och verktyg

Miljö Minimiversion
REST-API 2021-21-02
.NET 12.15.0
Java 12.21.0
Python 12.15.0
JavaScript 12.13.0
PowerShell (Az.Storage) 5.8.0
Azure CLI 2.50.0
AzCopy 10.18.1
Azure Storage Explorer 1.29.0

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.

Nästa steg