Veelgestelde vragen over levenscyclusbeheer

Dit artikel beantwoordt veelgestelde vragen over levenscyclusbeheerbeleid in Azure Blob Storage.

Ik heb een nieuw beleid opgesteld. Waarom worden de acties niet meteen uitgevoerd?

Zodra je een beleid hebt ingesteld, kan het tot 24 uur duren voordat het van kracht wordt. Zodra het beleid van kracht is, kan de tijd die het kost om acties uit te voeren variëren afhankelijk van de grootte van het opslagaccount en de uitgevoerde bewerkingen.

Als ik een bestaand beleid bijwerk, hoe lang duurt het dan voordat de acties worden uitgevoerd?

Het bijgewerkte beleid kan tot 24 uur duren voordat het van kracht wordt. Zodra het beleid van kracht is, varieert de tijd die het kost om de acties uit te voeren afhankelijk van de grootte van het opslagaccount en de uitgevoerde bewerkingen. Als de update is om een regel uit te schakelen of te verwijderen en enableAutoTierToHotFromCool is gebruikt, vindt automatische tiering naar de hot-tier nog steeds plaats. Stel bijvoorbeeld een regel met enableAutoTierToHotFromCool in op basis van de laatste toegang. Als de regel is uitgeschakeld of verwijderd en een blob zich momenteel in de koele of koude laag bevindt en vervolgens wordt benaderd, wordt deze teruggezet naar de hot-laag, omdat dit bij toegang buiten lifecycle management om wordt toegepast. De blob verschuift niet van warm naar koud of koud als de lifecycle management-regel is uitgeschakeld of verwijderd. De enige manier om dit te voorkomen autoTierToHotFromCool is door de tijdregistratie van de laatste toegang uit te schakelen.

De run wordt voltooid, maar verplaatst of verwijdert geen enkele blobs

Afhankelijk van de grootte en het aantal objecten in een opslagaccount heb je misschien meer dan één run nodig om alle objecten te verwerken. Je kunt ook de opslagresourcelogs controleren om te zien of het lifecycle management beleid de bewerkingen uitvoert.

Ik zie geen veranderingen in de capaciteit, ook al wordt het beleid uitgevoerd en worden de blobs verwijderd.

Controleer of gegevensbeschermingsfuncties zoals soft delete of versiebeheer op het opslagaccount zijn ingeschakeld. Zelfs als het beleid de blobs verwijdert, kunnen die blobs nog steeds bestaan in een zacht verwijderde staat of als oudere versie, afhankelijk van hoe deze functies zijn geconfigureerd.

Ik heb een gearchiveerde blob gerehydrateerd. Hoe voorkom ik dat het tijdelijk terug naar de Archief-laag wordt verplaatst?

Als er een levenscyclusbeheerbeleid van kracht is voor het opslagaccount, kan het rehydrateren van een blob door de tier te veranderen resulteren in een scenario waarin het levenscyclusbeleid de blob terug naar de archieflaag verplaatst. Deze voorwaarde treedt voor als de laatste wijzigingstijd, aanmaaktijd of laatste toegangstijd de drempelwaarde van het beleid overschrijdt. Er zijn drie manieren om deze aandoening te voorkomen:

  • Voeg de daysAfterLastTierChangeGreaterThan voorwaarde toe aan de tierToArchive actie van de polis. Zie Gebruik levenscyclusbeheerbeleid om blobs te archiveren.

  • Schakel de regel uit die deze blob tijdelijk beïnvloedt om te voorkomen dat deze opnieuw wordt gearchiveerd. Schakel de regel opnieuw in wanneer de blob veilig terug naar het archiefniveau kan worden verplaatst.

  • Als de blob permanent in de warme, koele of koude tier moet blijven, kopieer dan de blob naar een andere locatie waar het lifecycle management-beleid niet van kracht is.

De blob-prefix-matchstring paste het beleid niet toe op de verwachte blobs

Het blob-prefix-matchveld van een beleid is een volledig of gedeeltelijk blobpad, dat je gebruikt om de blobs te matchen waarop je wilt dat de beleidacties van toepassing zijn. Het pad moet beginnen met de naam van de container. Als je geen prefixmatch specificeert, geldt het beleid voor alle blobs in het opslagaccount. Het formaat van de prefix-overeenkomstreeks is [container name]/[blob name]. Houd de volgende punten in gedachten over de prefix-matchstring:

  • Een prefix-matchstring zoals container1/ geldt voor alle blobs in de container met de naam container1. Een prefix-overeenkomststring van container1, zonder het voorlopende slash-teken (/), geldt voor alle blobs in alle containers waarbij de containernaam begint met de string container1. Het voorvoegsel komt overeen met containers genaamd container11, container1234, container1ab, enzovoort.
  • Een prefix-overeenkomstreeks van container1/sub1/ geldt voor alle blobs in de container die met de naam container1 beginnen met de string sub1/. Bijvoorbeeld komt het voorvoegsel overeen met blobs met de naam container1/sub1/sub2/test.txt of container1/sub1/test.txt.
  • Het asteriskteken * is een geldig teken in een blobnaam. Als je het asterisk-teken in een prefix gebruikt, komt het prefix overeen met blobs met een asterisk in hun naam. Het sterretje werkt niet als een jokerkarakter.
  • Het vraagtekenteken ? is een geldig teken in een blobnaam. Als je het vraagtekenteken in een voorvoegsel gebruikt, komt het voorvoegsel overeen met blobs met een vraagteken in hun naam. Het vraagteken functioneert niet als een jokerkarakter.
  • De prefixmatch houdt alleen rekening met positieve (=) logische vergelijkingen. Het negeert negatieve (!=) logische vergelijkingen.
  • De voorvoegselmatching werkt op een hoofdlettergevoelige manier.

Is er een manier om het tijdstip te bepalen waarop het beleid wordt uitgevoerd?

Helaas is er geen manier om het tijdstip van uitvoering van het beleid bij te houden, omdat het een achtergrondplanningsproces is. Levenscyclusbeleid begint met de uitvoering binnen 24 uur nadat een regel is aangemaakt of bijgewerkt. Beleidsregels verwerken objecten continu op de achtergrond, wanneer nodig. Het systeem geeft prioriteit aan verzoeken van workloads. Er is dus geen manier om het tijdstip bij te houden waarop een polis mogelijk wordt uitgevoerd. De tijd die nodig is om objecten te verwerken kan afhangen van de aanvraagsnelheid voor het opslagaccount. Deze tijd kan langer zijn als de aanvraagsnelheid voor het opslagaccount de limiet van het opslagaccount nadert.

Volgende stappen 

  • Last updated on