Optimera kostnaderna genom att automatiskt hantera datalivscykeln
Livscykelhantering i Azure Blob Storage erbjuder en regelbaserad princip som du kan använda för att överföra blobdata till lämpliga åtkomstnivåer eller för att förfalla data i slutet av datalivscykeln.
Med policyn för livscykelhantering kan du:
- Övergå blobar från lågfrekvent till frekvent direkt när de används för att optimera prestanda.
- Överföra aktuella versioner av en blob, tidigare versioner av en blob eller blobögonblicksbilder till en lågfrekvent lagringsnivå om dessa objekt inte har använts eller ändrats under en viss tidsperiod för att optimera för kostnader.
- Ta bort aktuella versioner av en blob, tidigare versioner av en blob eller blobögonblicksbilder i slutet av livscykeln.
- Tillämpa regler på ett helt lagringskonto, för att välja containrar eller på en delmängd blobar med namnprefix eller blobindextaggar som filter.
Dricks
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?.
Livscykelhanteringsprinciper kan användas med blockblobar och tilläggsblobar i v2-konton för generell användning, premiumblockblobar och Blob Storage-konton. Livscykelhantering påverkar inte systemcontainrar som $logs containrar eller $web containrar.
Viktigt!
Om en datauppsättning måste vara läsbar ska du inte ange någon princip för att flytta blobar till arkivnivån. Blobar på arkivnivån kan inte läsas om de inte först extraheras, en process som kan vara tidskrävande och dyr. Mer information finns i Översikt över blobrehydrering från arkivnivån. Om en datauppsättning behöver läsas ofta ska du inte ange en princip för att flytta blobar till lågfrekventa eller kalla nivåer eftersom detta kan leda till högre transaktionskostnader.
Optimera kostnader genom att hantera datalivscykeln
Datauppsättningar har unika livscykeler. Tidigt i livscykeln får användarna ofta åtkomst till vissa data. Men behovet av åtkomst minskar ofta drastiskt när data åldras. Vissa data förblir inaktiva i molnet och används sällan när de har lagrats. Vissa datauppsättningar upphör att gälla dagar eller månader efter skapandet, medan andra datauppsättningar aktivt läss och ändras under hela livslängden.
Tänk dig ett scenario där data används ofta under de tidiga faserna av livscykeln, men bara ibland efter två veckor. Utöver den första månaden används sällan datauppsättningen. I det här scenariot är frekvent lagring bäst under de tidiga stadierna. Lågfrekvent lagring är lämpligast för tillfällig åtkomst. Arkivlagring är det bästa nivåalternativet efter att data har åldrats över en månad. Genom att flytta data till lämplig lagringsnivå baserat på dess ålder med policyregler för livscykelhantering kan du utforma den billigaste lösningen för dina behov.
Principdefinition för livscykelhantering
En livscykelhanteringsprincip är en samling regler i ett JSON-dokument. Följande JSON-exempel visar en fullständig regeldefinition:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
En princip är en samling regler enligt beskrivningen i följande tabell:
| Parameternamn | Parametertyp | Kommentar |
|---|---|---|
rules |
En matris med regelobjekt | Minst en regel krävs i en princip. Du kan definiera upp till 100 regler i en princip. |
Varje regel i principen har flera parametrar som beskrivs i följande tabell:
| Parameternamn | Parametertyp | Kommentar | Obligatoriskt |
|---|---|---|---|
name |
String | Ett regelnamn kan innehålla upp till 256 alfanumeriska tecken. Regelnamnet är skiftlägeskänsligt. Den måste vara unik i en princip. | Sant |
enabled |
Booleskt | Ett valfritt booleskt värde som tillåter att en regel inaktiveras tillfälligt. Standardvärdet är sant om det inte har angetts. | Falsk |
type |
Ett uppräkningsvärde | Den aktuella giltiga typen är Lifecycle. |
Sant |
definition |
Ett objekt som definierar livscykelregeln | Varje definition består av en filteruppsättning och en åtgärdsuppsättning. | Sant |
Definition av livscykelhanteringsregel
Varje regeldefinition i en princip innehåller en filteruppsättning och en åtgärdsuppsättning. Filtret anger begränsningar för regelåtgärder till en viss uppsättning objekt i en container eller objektnamn. Åtgärdsuppsättningen tillämpar nivå- eller borttagningsåtgärder på den filtrerade uppsättningen objekt.
Exempelregel
Följande exempelregel filtrerar kontot för att köra åtgärderna på objekt som finns inuti sample-container och börja med blob1.
- Nivåblob till lågfrekvent nivå 30 dagar efter senaste ändring
- Nivåblob till arkivnivå 90 dagar efter senaste ändring
- Ta bort blob 2 555 dagar (sju år) efter senaste ändringen
- Ta bort tidigare versioner 90 dagar efter skapandet
{
"rules": [
{
"enabled": true,
"name": "sample-rule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"delete": {
"daysAfterCreationGreaterThan": 90
}
},
"baseBlob": {
"tierToCool": {
"daysAfterModificationGreaterThan": 30
},
"tierToArchive": {
"daysAfterModificationGreaterThan": 90,
"daysAfterLastTierChangeGreaterThan": 7
},
"delete": {
"daysAfterModificationGreaterThan": 2555
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"sample-container/blob1"
]
}
}
}
]
}
Kommentar
BaseBlob-elementet i en livscykelhanteringsprincip refererar till den aktuella versionen av en blob. Versionselementet refererar till en tidigare version.
Regelfilter
Filter begränsar regelåtgärder till en delmängd blobar i lagringskontot. Om fler än ett filter har definierats körs ett logiskt AND på alla filter. Du kan använda ett filter för att ange vilka blobar som ska inkluderas. Ett filter ger inget sätt att ange vilka blobar som ska undantas.
Bland filtren finns:
| Filternamn | Filtertyp | Kommentar | Krävs |
|---|---|---|---|
| blobTypes | En matris med fördefinierade uppräkningsvärden. | Den aktuella versionen stöder blockBlob och appendBlob. Endast åtgärden Ta bort stöds för appendBlob; Ange nivå stöds inte. |
Ja |
| prefixMatch | En matris med strängar för prefix som ska matchas. Varje regel kan definiera upp till 10 skiftlägeskänsliga prefix. En prefixsträng måste börja med ett containernamn. Om du till exempel vill matcha alla blobar under https://myaccount.blob.core.windows.net/sample-container/blob1/...anger du prefixMatch som sample-container/blob1. Det här filtret matchar alla blobar i exempelcontainern vars namn börjar med blob1.. |
Om du inte definierar prefixMatch gäller regeln för alla blobar i lagringskontot. Prefixsträngar stöder inte jokerteckenmatchning. Tecken som * och ? behandlas som strängliteraler. |
Nej |
| blobIndexMatch | En matris med ordlistevärden som består av blobindextaggens nyckel- och värdevillkor som ska matchas. Varje regel kan definiera upp till tio villkor för blobindexeringstaggar. Om du till exempel vill matcha alla blobar med Project = Contoso under https://myaccount.blob.core.windows.net/ för en regel är {"name": "Project","op": "==","value": "Contoso"}blobIndexMatch . |
Om du inte definierar blobIndexMatch gäller regeln för alla blobar i lagringskontot. | Nej |
Mer information om blobindexfunktionen tillsammans med kända problem och begränsningar finns i Hantera och hitta data i Azure Blob Storage med blobindex.
Regelåtgärder
Åtgärder tillämpas på filtrerade blobs när körvillkoret är uppfyllt.
Livscykelhantering stöder nivåindelning och borttagning av aktuella versioner, tidigare versioner och blobögonblicksbilder. Definiera minst en åtgärd för varje regel.
Kommentar
Nivåindelning stöds ännu inte i ett Premium-blockbloblagringskonto. För alla andra konton tillåts nivåindelning endast på blockblobar och inte för tilläggs- och sidblobar.
| Åtgärd | Aktuell version | Ögonblicksbild | Tidigare versioner |
|---|---|---|---|
| tierToCool | Stöds för blockBlob |
Stöds | Stöds |
| tierToCold | Stöds för blockBlob |
Stöds | Stöds |
| enableAutoTierToHotFromCool1 | Stöds för blockBlob |
Stöds inte | Stöds inte |
| tierToArchive4 | Stöds för blockBlob |
Stöds | Stöds |
| ta bort2,3 | Stöds för blockBlob och appendBlob |
Stöds | Stöds |
1 Åtgärden enableAutoTierToHotFromCool är endast tillgänglig när den används med körningsvillkoret daysAfterLastAccessTimeGreaterThan . Det villkoret beskrivs i nästa tabell.
2 När en borttagningsåtgärd tillämpas på ett konto med ett hierarkiskt namnområde aktiverat tas tomma kataloger bort. Om katalogen inte är tom tar borttagningsåtgärden bort objekt som uppfyller principvillkoren inom den första livscykelprincipkörningscykeln. Om åtgärden resulterar i en tom katalog som också uppfyller principvillkoren tas katalogen bort inom nästa körningscykel och så vidare.
3 En livscykelhanteringsprincip tar inte bort den aktuella versionen av en blob förrän tidigare versioner eller ögonblicksbilder som är associerade med den blobben har tagits bort. Om blobar i ditt lagringskonto har tidigare versioner eller ögonblicksbilder måste du inkludera tidigare versioner och ögonblicksbilder när du anger en borttagningsåtgärd som en del av principen.
4 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. Den här åtgärden visas baserat på den redundans som konfigurerats för kontot.
Kommentar
Om du definierar mer än en åtgärd på samma blob tillämpar livscykelhantering den billigaste åtgärden på blobben. Till exempel är åtgärder delete billigare än åtgärd tierToArchive. Åtgärd tierToArchive är billigare än åtgärd tierToCool.
Körningsvillkoren baseras på ålder. Aktuella versioner använder den senaste ändrade tiden eller senaste åtkomsttiden, tidigare versioner använder tiden för versionsskapande och blobögonblicksbilder använder tiden för att skapa ögonblicksbilder för att spåra ålder.
| Villkor för åtgärdskörning | Villkorsvärde | beskrivning |
|---|---|---|
| daysAfterModificationGreaterThan | Heltalsvärde som anger ålder i dagar | Villkoret för åtgärder i en aktuell version av en blob |
| daysAfterCreationGreaterThan | Heltalsvärde som anger ålder i dagar | Villkoret för åtgärder på den aktuella versionen eller tidigare version av en blob eller en ögonblicksbild av blob |
| daysAfterLastAccessTimeGreaterThan1 | Heltalsvärde som anger ålder i dagar | Villkoret för en aktuell version av en blob när åtkomstspårning är aktiverat |
| daysAfterLastTierChangeGreaterThan | Heltalsvärde som anger ålder i dagar efter senaste ändringstid för blobnivå | Den minsta varaktigheten i dagar som en uttorkad blob hålls på frekventa, lågfrekventa eller kalla nivåer innan den returneras till arkivnivån. Det här villkoret gäller endast åtgärder tierToArchive . |
1 Om spårning av senaste åtkomsttid inte är aktiverat använder daysAfterLastAccessTimeGreaterThan det datum då livscykelprincipen aktiverades i stället för LastAccessTime blobens egenskap. Det här datumet används också när egenskapen LastAccessTime är ett null-värde. Mer information om hur du använder spårning av senaste åtkomsttid finns i Flytta data baserat på senast använda tid.
Livscykelpolicykörningar
När du konfigurerar eller redigerar en livscykelprincip kan det ta upp till 24 timmar innan ändringarna börjar gälla och för att den första körningen ska börja. Den tid det tar för principåtgärder att slutföra beror på antalet blobar som utvärderas och används.
Om du inaktiverar en princip schemaläggs inga nya principkörningar, men om en körning redan pågår fortsätter den körningen tills den har slutförts och du debiteras för alla åtgärder som krävs för att slutföra körningen. Se Regional tillgänglighet och prissättning.
Händelse för slutförd livscykelprincip
Händelsen LifecyclePolicyCompleted genereras när åtgärderna som definieras av en livscykelhanteringsprincip utförs. Ett sammanfattningsavsnitt visas för varje åtgärd som ingår i principdefinitionen. Följande json visar en exempelhändelse LifecyclePolicyCompleted för en princip. Eftersom principdefinitionen deleteinnehåller åtgärderna , tierToCool, tierToColdoch visas ett sammanfattningsavsnitt för var och tierToArchive en.
{
"topic": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/contosoresourcegroup/providers/Microsoft.Storage/storageAccounts/contosostorageaccount",
"subject": "BlobDataManagement/LifeCycleManagement/SummaryReport",
"eventType": "Microsoft.Storage.LifecyclePolicyCompleted",
"eventTime": "2022-05-26T00:00:40.1880331",
"id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"data": {
"scheduleTime": "2022/05/24 22:57:29.3260160",
"deleteSummary": {
"totalObjectsCount": 16,
"successCount": 14,
"errorList": ""
},
"tierToCoolSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToColdSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
I följande tabell beskrivs schemat för LifecyclePolicyCompleted händelsen.
| Fält | Type | Beskrivning |
|---|---|---|
| scheduleTime | sträng | Den tid då livscykelpolicyn schemalagts |
| deleteSummary | vektorbyte<> | Resultatsammanfattningen av blobar som är schemalagda för borttagning |
| tierToCoolSummary | vektorbyte<> | Resultatsammanfattningen av blobar som schemalagts för nivå-till-lågfrekvent åtgärd |
| tierToColdSummary | vektorbyte<> | Resultatsammanfattningen av blobar som schemalagts för nivå-till-kall-åtgärd |
| tierToArchiveSummary | vektorbyte<> | Resultatsammanfattningen av blobar som schemalagts för åtgärden nivå-till-arkiv |
Exempel på livscykelprinciper
Följande exempel visar hur du hanterar vanliga scenarier med livscykelprincipregler.
Flytta åldrande data till en lågfrekvent nivå
Det här exemplet visar hur du övergår blockblobbar som är prefix med sample-container/blob1 eller container2/blob2. Principen övergår blobar som inte har ändrats på över 30 dagar till lågfrekvent lagring och blobar som inte har ändrats på 90 dagar till arkivnivån:
{
"rules": [
{
"name": "agingRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "sample-container/blob1", "container2/blob2" ]
},
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 90 }
}
}
}
}
]
}
Flytta data baserat på senaste åtkomsttid
Du kan aktivera spårning av senaste åtkomsttid för att behålla en post för när blobben senast lästes eller skrevs och som ett filter för att hantera nivåindelning och kvarhållning av dina blobdata. Information om hur du aktiverar spårning av senaste åtkomsttid finns i Aktivera åtkomsttidsspårning om du vill.
När spårning av senaste åtkomsttid är aktiverat uppdateras blobegenskapen som anropas LastAccessTime när en blob läs- eller skrivs. En Get Blob-åtgärd betraktas som en åtkomståtgärd. Hämta blobegenskaper, Hämta blobmetadata och Hämta blobtaggar är inte åtkomståtgärder och uppdaterar därför inte den senaste åtkomsttiden.
Om spårning av senaste åtkomsttid är aktiverat används LastAccessTime livscykelhantering för att avgöra om körningsvillkoret daysAfterLastAccessTimeGreaterThan uppfylls. Livscykelhantering använder det datum då livscykelpolicyn aktiverades i stället för LastAccessTime i följande fall:
Värdet för blobens
LastAccessTimeegenskap är ett null-värde.Kommentar
Egenskapen
lastAccessedOnför bloben är null om en blob inte har använts sedan spårning av senaste åtkomsttid aktiverades.Spårning av senaste åtkomsttid är inte aktiverat.
För att minimera effekten på svarstiden för läsåtkomst uppdaterar endast den första läsningen under de senaste 24 timmarna den senaste åtkomsttiden. Efterföljande läsningar under samma 24-timmarsperiod uppdaterar inte den senaste åtkomsttiden. Om en blob ändras mellan läsningar är den senaste åtkomsttiden den senaste av de två värdena.
I följande exempel flyttas blobar till lågfrekvent lagring om de inte har använts på 30 dagar. Egenskapen enableAutoTierToHotFromCool är ett booleskt värde som anger om en blob automatiskt ska nivåindelas från lågfrekvent tillbaka till frekvent om den nås igen efter att ha nivåindelats till lågfrekvent.
Dricks
Om en blob flyttas till lågfrekvent nivå och sedan flyttas tillbaka automatiskt innan 30 dagar har förflutit debiteras en avgift för tidig borttagning. Innan du anger enablAutoTierToHotFromCool egenskapen måste du analysera åtkomstmönstren för dina data så att du kan minska oväntade avgifter.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Arkivera data efter inmatning
Vissa data förblir inaktiva i molnet och används sällan, om någonsin. Följande livscykelprincip är konfigurerad för att arkivera data kort efter att den har matats in. I det här exemplet övergår blockblobar i en container med namnet archivecontainer till en arkivnivå. Övergången utförs genom att agera på blobar 0 dagar efter den senaste ändrade tiden.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Kommentar
Microsoft rekommenderar att du laddar upp dina blobar direkt till arkivnivån för bättre effektivitet. Du kan ange arkivnivån i rubriken x-ms-access-tier i åtgärden Put Blob or Put Block List (Placera blobb eller Placera blockeringslista ). Rubriken x-ms-access-tier stöds med REST version 2018-11-09 och senare eller de senaste blob storage-klientbiblioteken.
Förfalla data baserat på ålder
Vissa data förväntas upphöra att gälla dagar eller månader efter skapandet. Du kan konfigurera en livscykelhanteringsprincip för att förfalla data genom borttagning baserat på dataålder. I följande exempel visas en princip som tar bort alla blockblobar som inte har ändrats under de senaste 365 dagarna.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Ta bort data med blobindextaggar
Vissa data bör bara upphöra att gälla om de uttryckligen har markerats för borttagning. Du kan konfigurera en livscykelhanteringsprincip för att förfalla data som är taggade med nyckel-/värdeattribut för blobindex. I följande exempel visas en princip som tar bort alla blockblobar som är taggade med Project = Contoso. Mer information om blobindex finns i Hantera och hitta data på Azure Blob Storage med blobindex.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Hantera tidigare versioner
För data som ändras och används regelbundet under hela dess livslängd kan du aktivera bloblagringsversioner för att automatiskt underhålla tidigare versioner av ett objekt. Du kan skapa en princip för att nivåindela eller ta bort tidigare versioner. Versionsåldern bestäms genom att utvärdera tidpunkten för versionsskapandet. Den här principregeln flyttar tidigare versioner i en container activedata som är 90 dagar eller äldre efter att versionen har skapats till lågfrekvent nivå och tar bort tidigare versioner som är 365 dagar eller äldre.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Regional tillgänglighet och prissättning
Livscykelhanteringsfunktionen är tillgänglig i alla Azure-regioner.
Principer för livscykelhantering är kostnadsfria. Kunder debiteras för standardåtgärdskostnader för API-anrop på set-blobnivå . Borttagningsåtgärder är kostnadsfria. Andra Azure-tjänster och -verktyg som Microsoft Defender for Storage kan dock debiteras för åtgärder som hanteras via en livscykelprincip.
Varje uppdatering av en blob senaste åtkomsttid faktureras under den andra driftkategorin . Varje uppdatering av senaste åtkomsttid debiteras som en "annan transaktion" högst en gång var 24:e timme per objekt, även om den nås 1000-talet gånger på en dag. Detta är skilt från lästransaktioner.
Mer information om priser finns på Prissättning för blockblobbar.
Kända problem och begränsningar
Nivåindelning stöds ännu inte i ett Premium-blockbloblagringskonto. För alla andra konton tillåts nivåindelning endast på blockblobar och inte för tilläggs- och sidblobar.
En livscykelhanteringsprincip måste läsas eller skrivas i sin helhet. Partiella uppdateringar stöds inte.
Varje regel kan ha upp till 10 skiftlägeskänsliga prefix och upp till 10 villkor för blobindextaggen.
En livscykelhanteringsprincip kan inte ändra nivån för en blob som använder ett krypteringsomfång.
Borttagningsåtgärden för en livscykelhanteringsprincip fungerar inte med någon blob i en oföränderlig container. Med en oföränderlig princip kan objekt skapas och läsas, men inte ändras eller tas bort. Mer information finns i Lagra affärskritiska blobdata med oföränderlig lagring.
Vanliga frågor och svar
Se Vanliga frågor och svar om livscykelhantering.