Optimera kostnader genom att automatiskt hantera datalivscykeln

Datauppsättningar har unika livscykler. Tidigt i livscykeln kommer användare ofta åt vissa data. Men behovet av åtkomst minskar ofta drastiskt när data blir äldre. Vissa data förblir inaktiva i molnet och används sällan när de lagras. Vissa datauppsättningar upphör att gälla dagar eller månader efter skapandet, medan andra datauppsättningar aktivt läses och ändras under hela livslängden. Azure Storage livscykelhantering erbjuder en regelbaserad princip som du kan använda för att föra över blobdata till lämpliga åtkomstnivåer eller för att förfalla data i slutet av datalivscykeln.

Med livscykelhanteringsprincipen kan du:

• Föra över blobar från cool till hot direkt när de används för att optimera prestandan.
• Föra över blobar, blobversioner och blobögonblicksbilder till en kallare lagringsnivå om dessa objekt inte har använts eller ändrats under en viss tidsperiod, för att optimera för kostnader. I det här scenariot kan livscykelhanteringsprincipen flytta objekt från hot till cool, från hot till archive eller från cool till arkiv.
• Ta bort blobar, blobversioner och blobögonblicksbilder i slutet av livscykeln.
• Definiera regler som ska köras en gång per dag på lagringskontonivå.
• Tillämpa regler på containrar eller på en delmängd av blobar med hjälp av namnprefix eller blobindextaggar som filter.

Tänk dig ett scenario där data ofta används under de tidiga faserna av livscykeln, men bara ibland efter två veckor. Efter den första månaden används datauppsättningen sällan. I det här scenariot är den heta lagringen bäst i ett tidigt skede. Den coola lagringen passar bäst för tillfällig åtkomst. Arkivlagring är det bästa nivåalternativet när data har åldrarna över en månad. Genom att flytta data till lämplig lagringsnivå baserat på dess ålder med principregler för livscykelhantering kan du utforma den billigaste lösningen för dina behov.

Principer för livscykelhantering stöds för blockblobar och tilläggsblobbar i konton för generell användning v2, Premium-blockblob och Blob Storage. Livscykelhanteringen påverkar inte systemcontainrar, till exempel $logs eller $web containrar.

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:

Varje regel i principen har flera parametrar som beskrivs i följande tabell:

Regeldefinition för livscykelhantering

Varje regeldefinition i en princip innehåller en filteruppsättning och en åtgärdsuppsättning. Filtret begränsar 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 i sample-container och börjar med blob1 .

• Nivåblob till den coola nivån 30 dagar efter den senaste ändringen
• Nivåblob för arkivlagringsnivå 90 dagar efter den senaste ändringen
• Ta bort blob 2 555 dagar (sju år) efter den senaste ändringen
• Ta bort tidigare blobversioner 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
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

Regelfilter

Filter begränsar regelåtgärder till en delmängd av blobar i lagringskontot. Om fler än ett filter har definierats körs ett AND logiskt värde på alla filter.

Filtren är:

Mer information om funktionen för blobindex 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å de filtrerade blobarna när körningsvillkoret uppfylls.

Livscykelhantering stöder nivåindelad lagring och borttagning av blobar, tidigare blobversioner och blobögonblicksbilder. Definiera minst en åtgärd för varje regel på basblobar, tidigare blobversioner eller blobögonblicksbilder.

Körningsvillkoren baseras på ålder. Basblobar använder tiden för senaste ändring, blobversioner använder versionstidsgenereringen och blobögonblicksbilder använder tiden för att skapa ögonblicksbilder för att spåra ålder.

Exempel på livscykelprinciper

Följande exempel visar hur du kan hantera vanliga scenarier med livscykelprincipregler.

Flytta lagringsdata till en mer kylarnivå

Det här exemplet visar hur du övergår till blockblobar med sample-container/blob1 prefixet eller container2/blob2 . Principen övergår från blobar som inte har ändrats på över 30 dagar till cool lagring och blobar ändras inte 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å senast använda tid

Du kan aktivera spårning av senaste åtkomsttid för att registrera när bloben senast läses eller skrivs och som ett filter för att hantera nivåindelad och kvarhållning av dina blobdata. Information om hur du aktiverar spårning av senaste åtkomsttid finns i Aktivera spårning av åtkomsttid (valfritt).

När spårning av senaste åtkomsttid är aktiverat uppdateras blobegenskapen LastAccessTime som anropas när en blob läses eller skrivs. En Get Blob-åtgärd betraktas som en åtkomståtgärd. Hämta blobegenskaper, Hämta blobmetadataoch Hämta blobtaggar är inte åtkomståtgärder och uppdaterar därför inte den senaste åtkomsttiden.

För att minimera påverkan på svarstiden för läsåtkomst uppdaterar endast den första läsningen av 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 den coola lagringen om de inte har använts på 30 dagar. Egenskapen är ett booleskt värde som anger om en blob automatiskt ska nivåindelats från den kalla tillbaka till den heta om den används igen efter att ha nivåindelats enableAutoTierToHotFromCool till nedspolning.

{
  "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 konfigureras för att arkivera data strax efter att de har matats in. I det här exemplet övergår blockblobar i en container med archivecontainer namnet till en arkivnivå. Övergången åstadkoms genom att agera på blobar 0 dagar efter den senaste ändringstiden:

{
  "rules": [
    {
      "name": "archiveRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ],
          "prefixMatch": [ "archivecontainer" ]
        },
        "actions": {
          "baseBlob": {
              "tierToArchive": { "daysAfterModificationGreaterThan": 0 }
          }
        }
      }
    }
  ]
}

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 så att data upphör att gälla genom borttagning baserat på dataålder. I följande exempel visas en princip som tar bort alla blockblobar som är äldre än 365 dagar.

{
  "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 blobindexnyckel-/värdeattribut. I följande exempel visas en princip som tar bort alla blockblobar som taggats med Project = Contoso . Mer information om blobindex finns i Hantera och hitta data i Azure Blob Storage med blobindex (förhandsversion).

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Hantera versioner

För data som ändras och används regelbundet under hela livslängden kan du aktivera versionshantering av bloblagring för att automatiskt underhålla tidigare versioner av ett objekt. Du kan skapa en princip för att nivåindelad eller ta bort tidigare versioner. Versionsåldern bestäms genom utvärdering av skapandetiden för versionen. Den här principregeln nivåindelar tidigare versioner i containern som är 90 dagar eller äldre efter att versionen har skapats på den lägre nivån och tar bort tidigare versioner som är activedata 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"
          ]
        }
      }
    }
  ]
}

Funktionsstöd

Den här tabellen visar hur den här funktionen stöds i ditt konto och hur det påverkar supporten när du aktiverar vissa funktioner.

Typ av lagringskonto	Blob Storage (standardstöd)	Data Lake Storage Gen2 1	NFS 3.0 1	SFTP 1
Standard generell användning v2
Premium blockblobar

¹ Data Lake Storage Gen2, NFS 3.0-protokollet (Network File System) och SFTP (Secure File Transfer Protocol) stöder alla ett lagringskonto med ett hierarkiskt namnområde aktiverat.

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-anropen på Set Blob Tier. Borttagningsåtgärder är kostnadsfria.

Varje uppdatering av en blobs senaste åtkomsttid debiteras under den andra driftkategorin.

Mer information om priser finns i Prissättning för blockblobar.

Vanliga frågor

Jag har skapat en ny princip. Varför körs inte åtgärderna omedelbart?

Plattformen kör livscykelprincipen en gång om dagen. När du har konfigurerat en princip kan det ta upp till 24 timmar innan vissa åtgärder körs för första gången.

Hur lång tid tar det innan åtgärderna körs om jag uppdaterar en befintlig princip?

Den uppdaterade principen tar upp till 24 timmar att gälla. När principen har verkställs kan det ta upp till 24 timmar innan åtgärderna körs. Principåtgärderna kan därför ta upp till 48 timmar att slutföra. Om uppdateringen är att inaktivera eller ta bort en regel, och enableAutoTierToHotFromCool användes, sker automatisk nivåindelad till hot-nivå fortfarande. Ange till exempel en regel, inklusive enableAutoTierToHotFromCool baserat på senaste åtkomst. Om regeln är inaktiverad/borttagna och en blob för närvarande är i cool och sedan används, flyttas den tillbaka till Hot eftersom den tillämpas på åtkomst utanför livscykelhanteringen. Bloben flyttas sedan inte från Het till Kall eftersom livscykelhanteringsregeln är inaktiverad/borttagna. Det enda sättet att förhindra autoTierToHotFromCool är att inaktivera spårning av senaste åtkomsttid.

Jag har rehydrerat en arkiverad blob manuellt. Hur förhindrar jag att den tillfälligt flyttas tillbaka till arkivnivån?

När en blob flyttas från en åtkomstnivå till en annan ändras inte dess senaste ändringstid. Om du manuellt rehydrerade en arkiverad blob till den heta nivån skulle den flyttas tillbaka till arkivnivån av livscykelhanteringsmotorn. Inaktivera regeln som tillfälligt påverkar bloben för att förhindra att den arkiveras igen. Återaktivera regeln när bloben på ett säkert sätt kan flyttas tillbaka till arkivnivån. Du kan också kopiera bloben till en annan plats om den måste vara permanent på den heta eller coola nivån.

Nästa steg

• Konfigurera en princip för livscykelhantering
• Åtkomstnivåer för hot, cool och archive för blobdata
• Hantera och hitta data i Azure Blob Storage med blobindex