Dela via

Principer för livscykelhantering som flyttar blobbar mellan nivåer

Du kan använda livscykelhanteringsprinciper för att överföra blobar till kostnadseffektiva åtkomstnivåer baserat på deras användningsmönster. Den här artikeln innehåller exempel på principdefinitioner som hanterar övergångar av blobbar mellan olika nivåer.

Allmän information om livscykelhanteringsprinciper för Azure Storage finns i Översikt över livscykelhantering i Azure Blob Storage.

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. Policyn flyttar blobar som inte har ändrats på mer än 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 }
          }
        }
      }
    }
  ]
}

Anmärkning

BaseBlob-elementet i en livscykelhanteringsprincip refererar till den aktuella versionen av en blob.

Flytta data baserat på den senast använda tiden

I följande exempel flyttas blobar till kall lagring om de inte har använts inom 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.

Tips/Råd

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 enableAutoTierToHotFromCool egenskapen måste du analysera åtkomstmönstren för dina data så att du kan minska oväntade avgifter. Automatisk nivåindelning från kallt till varmt vid åtkomst av blobbar är begränsad till en gång var 30:e dag. Det här skyddet är på plats för att hjälpa dig att undvika flera straff för tidig borttagning från den lågfrekventa nivån. Om objektet återgår till lågfrekventa nivåer på grund av principen debiteras alla transaktioner på blobben till lågfrekventa nivåpriser. Det är kostnadseffektivt att hålla bloben på varm nivå om den behöver flyttas upp automatiskt i nivå mer än en gång under en 30-dagarsperiod.

Aktivering av en regel med enableAutoTierToHotFromCool gäller endast för objekt som är nivåindelade med den här regeln. Egenskapen enableAutoTierToHotFromCool kan inte aktiveras för blobar som redan finns på lågfrekvent nivå. Därför kommer åtkomstnivån för dessa blobar inte automatiskt att ändras till het när de används.

{
  "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 hantera blobar 0 dagar efter senast ändrat datum.

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.

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

Anmärkning

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.

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 nivåindelning av 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å.

{
  "rules": [
    {
      "enabled": true,
      "name": "versionrule",
      "type": "Lifecycle",
      "definition": {
        "actions": {
          "version": {
            "tierToCool": {
              "daysAfterCreationGreaterThan": 90
            },
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "activedata/"
          ]
        }
      }
    }
  ]
}

Anmärkning

Versionselementet i en livscykelhanteringsprincip refererar till en tidigare version.

Se även