Vanliga frågor om livscykelhanteringspolicy

Den här artikeln besvarar vanliga frågor om livscykelhanteringspolicys i Azure Blob Storage.

Jag skapade en ny policy. Varför körs inte åtgärderna direkt?

När du har konfigurerat en policy kan det ta upp till 24 timmar innan den träder i kraft. När policyn väl är i kraft kan tiden det tar för åtgärder att köras variera beroende på lagringskontots storlek och de utförda operationerna.

Om jag uppdaterar en befintlig policy, hur lång tid tar det innan åtgärderna körs?

Den uppdaterade policyn kan ta upp till 24 timmar innan den träder i kraft. När policyn väl är i kraft varierar tiden det tar för åtgärderna att köras beroende på storleken på lagringskontot och de operationer som utförs. Om uppdateringen innebär att en regel ska inaktiveras eller tas bort, och enableAutoTierToHotFromCool användes, fortsätter automatisk nivåindelning till den varma nivån ändå. Till exempel, sätt en regel som inkluderar enableAutoTierToHotFromCool baserat på senaste åtkomst. Om regeln är inaktiverad eller borttagen och ett blobobjekt för närvarande finns på den svala eller kalla åtkomstnivån och sedan används, flyttas det tillbaka till den heta åtkomstnivån, eftersom detta sker vid åtkomst utanför livscykelhantering. Blobben flyttas inte från varm till kall eller kall om livscykelhanteringsregeln är inaktiverad eller borttagen. Det enda sättet att förhindra autoTierToHotFromCool är att stänga av spårning av senaste åtkomsttid.

Körningen slutförs men flyttar inte eller tar bort vissa blobbar

Beroende på storleken och antalet objekt i ett lagringskonto kan du behöva mer än en körning för att bearbeta alla objekt. Du kan också kontrollera lagringsresursloggarna för att se om livscykelhanteringspolicyn utför operationerna.

Jag ser inga kapacitetsändringar trots att policyn körs och raderar blobsen

Kontrollera om dataskyddsfunktioner som mjuk borttagning eller versionshantering är aktiverade på lagringskontot. Även om policyn är att ta bort blobsen kan dessa blobs fortfarande existera i ett mjukt raderat tillstånd eller som en äldre version beroende på hur dessa funktioner är konfigurerade.

Jag återfuktade en arkiverad klump. Hur förhindrar jag att den tillfälligt flyttas tillbaka till Arkivet-nivån?

Om det finns en livscykelhanteringspolicy i kraft för lagringskontot, kan en rehydrering av en blob genom att ändra dess nivå resultera i ett scenario där livscykelpolicyn flyttar blobben tillbaka till arkivnivån. Detta villkor uppstår om den senaste modifierade tiden, skapandetiden eller sista åtkomsttiden överskrider den tröskel som är satt för policyn. Det finns tre sätt att förebygga detta tillstånd:

  • Lägg till villkoret daysAfterLastTierChangeGreaterThan i policyns tierToArchive handling. Se Använd principer för livscykelhantering för att arkivera blobbar.

  • Inaktivera regeln som tillfälligt påverkar denna blob för att förhindra att den arkiveras igen. Aktivera regeln igen när blobben säkert kan flyttas tillbaka till arkivnivån.

  • Om blobben behöver vara kvar permanent på hot-, cool- eller cold-nivån kopierar du blobben till en annan plats där principen för livscykelhantering inte gäller.

Blobprefixets matchningssträng tillämpade inte policyn på de förväntade blobsen

Fältet för att matcha blobprefixet i en policy är en fullständig eller delvis blob-väg, som du använder för att matcha de blobs du vill att policyåtgärderna ska gälla för. Sökvägen måste börja med containernamnet. Om du inte specificerar en prefixmatchning gäller policyn för alla blobs i lagringskontot. Formatet för prefixmatchningssträngen är [container name]/[blob name]. Tänk på följande punkter om strängen för prefixmatchning:

  • En prefixmatchningssträng som container1/ gäller för alla blobs i containern som heter container1. En sträng för prefixmatchning av container1, utan det efterföljande snedstreckstecknet (/), tillämpas på alla blobbar i alla containrar där containernamnet börjar med strängen container1. Prefixet matchar behållare som heter container11, container1234, container1ab, och så vidare.
  • En prefixmatchningssträng av container1/sub1/ gäller för alla blobs i behållaren som är namngivna container1 och som börjar med strängen sub1/. Till exempel matchar prefixet blobbar som heter container1/sub1/test.txt eller container1/sub1/sub2/test.txt.
  • Asterisktecknet * är ett giltigt tecken i ett blobnamn. Om du använder asterisktecknet i ett prefix matchar prefixet blobbar med en asterisk i deras namn. Asterisken fungerar inte som en jokerkaraktär.
  • Frågetecknet ? är ett giltigt tecken i ett blob-namn. Om du använder frågetecken i ett prefix, matchar prefixet blobbar med ett frågetecken i deras namn. Frågetecknet fungerar inte som en jokerkaraktär.
  • Prefixmatchningen beaktar endast positiva (=) logiska jämförelser. Den ignorerar negativa (!=) logiska jämförelser.
  • Prefixmatchningen fungerar på ett kasuskänsligt sätt.

Finns det något sätt att identifiera när policyn kommer att träda i kraft?

Tyvärr finns det inget sätt att spåra när policyn kommer att träda i kraft, eftersom det är en bakgrundsschemaläggningsprocess. Livscykelpolicyer börjar köras inom 24 timmar efter att en regel skapats eller uppdaterats. Policyer bearbetar objekt kontinuerligt i bakgrunden vid behov. Systemet ger prioritet åt förfrågningar från arbetslaster. Så det finns inget sätt att spåra när en policy kan vara i drift. Tiden som krävs för att bearbeta objekt kan bero på begärandets hastighet för lagringskontot. Den här tiden kan bli längre om begäransatsen för lagringskontot närmar sig lagringskontots gräns.

Nästa steg

  • Last updated on