Kosten optimaliseren door de levenscyclus van gegevens automatisch te beheren
Het levenscyclusbeheer van Azure Blob Storage biedt een beleid op basis van regels dat u kunt gebruiken om blobgegevens over te zetten naar de juiste toegangslagen of om gegevens te laten verlopen aan het einde van de levenscyclus van de gegevens.
Met het levenscyclusbeheerbeleid kunt u het volgende doen:
- Overgangsblobs van statisch naar dynamisch onmiddellijk wanneer ze worden geopend, om de prestaties te optimaliseren.
- De huidige versies van een blob, eerdere versies van een blob of blob-momentopnamen overdragen naar een koeler opslaglaag als deze objecten gedurende een bepaalde periode niet zijn geopend of gewijzigd om kosten te optimaliseren.
- Verwijder huidige versies van een blob, eerdere versies van een blob of blob-momentopnamen aan het einde van hun levenscyclus.
- Regels toepassen op een volledig opslagaccount, containers selecteren of op een subset van blobs met naamvoorvoegsels of blobindextags als filters.
Tip
Hoewel levenscyclusbeheer u helpt bij het verplaatsen van gegevens tussen lagen in één account, kunt u een opslagtaak gebruiken om deze taak op schaal uit te voeren voor meerdere accounts. Een opslagtaak is een resource die beschikbaar is in Azure Storage Actions; een serverloos framework dat u kunt gebruiken om algemene gegevensbewerkingen uit te voeren op miljoenen objecten in meerdere opslagaccounts. Zie Wat is Azure Storage Actions?voor meer informatie.
Beleidsregels voor levenscyclusbeheer worden ondersteund voor blok-blobs en toevoeg-blobs in v2-accounts voor algemeen gebruik, premium blok-blob en Blob Storage-accounts. Levenscyclusbeheer heeft geen invloed op systeemcontainers zoals de $logs of $web containers.
Belangrijk
Als een gegevensset leesbaar moet zijn, moet u geen beleid instellen om blobs naar de archieflaag te verplaatsen. Blobs in de archieflaag kunnen niet worden gelezen tenzij ze eerst worden gerehydrateerd, een proces dat tijdrovend en duur kan zijn. Zie Overzicht van rehydratatie van blobs vanuit de archieflaag voor meer informatie. Als een gegevensset vaak moet worden gelezen, moet u geen beleid instellen om blobs naar de statische of koude lagen te verplaatsen, omdat dit kan leiden tot hogere transactiekosten.
Kosten optimaliseren door de levenscyclus van gegevens te beheren
Gegevenssets hebben unieke levenscycluss. Vroeg in de levenscyclus hebben mensen vaak toegang tot bepaalde gegevens. Maar de behoefte aan toegang neemt vaak drastisch af naarmate de gegevens ouder worden. Sommige gegevens blijven inactief in de cloud en worden zelden gebruikt zodra ze zijn opgeslagen. Sommige gegevenssets verlopen dagen of maanden na het maken, terwijl andere gegevenssets gedurende hun levensduur actief worden gelezen en gewijzigd.
Overweeg een scenario waarin gegevens vaak worden geopend tijdens de vroege fasen van de levenscyclus, maar slechts af en toe na twee weken. Na de eerste maand wordt de gegevensset zelden geopend. In dit scenario is dynamische opslag het beste tijdens de vroege fasen. Statische opslag is het meest geschikt voor incidentele toegang. Archiefopslag is de beste laagoptie nadat de gegevens ouder zijn dan een maand. Door gegevens naar de juiste opslaglaag te verplaatsen op basis van de leeftijd met beleidsregels voor levenscyclusbeheer, kunt u de minst dure oplossing voor uw behoeften ontwerpen.
Definitie van levenscyclusbeheerbeleid
Een levenscyclusbeheerbeleid is een verzameling regels in een JSON-document. In de volgende voorbeeld-JSON ziet u een volledige regeldefinitie:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Een beleid is een verzameling regels, zoals beschreven in de volgende tabel:
| Parameternaam | Parametertype | Opmerkingen |
|---|---|---|
rules |
Een matrix met regelobjecten | Er is ten minste één regel vereist in een beleid. U kunt maximaal 100 regels definiëren in een beleid. |
Elke regel in het beleid heeft verschillende parameters, zoals beschreven in de volgende tabel:
| Parameternaam | Parametertype | Opmerkingen | Vereist |
|---|---|---|---|
name |
String | Een regelnaam kan maximaal 256 alfanumerieke tekens bevatten. Regelnaam is hoofdlettergevoelig. Deze moet uniek zijn binnen een beleid. | Waar |
enabled |
Booleaanse waarde | Een optionele Booleaanse waarde om toe te staan dat een regel tijdelijk wordt uitgeschakeld. De standaardwaarde is waar als deze niet is ingesteld. | Onwaar |
type |
Een opsommingswaarde | Het huidige geldige type is Lifecycle. |
Waar |
definition |
Een object dat de levenscyclusregel definieert | Elke definitie bestaat uit een filterset en een actieset. | Waar |
Definitie van levenscyclusbeheerregel
Elke regeldefinitie binnen een beleid bevat een filterset en een actieset. Met de filterset worden regelacties beperkt tot een bepaalde set objecten binnen een container- of objectnamen. De actieset past de laag- of verwijderacties toe op de gefilterde set objecten.
Voorbeeldregel
Met de volgende voorbeeldregel wordt het account gefilterd om de acties uit te voeren op objecten die zich binnen sample-container bevinden en beginnen met blob1.
- Blob tieren naar statische laag 30 dagen na de laatste wijziging
- Laag-blob voor archieflaag 90 dagen na laatste wijziging
- Blob 2555 dagen (zeven jaar) verwijderen na laatste wijziging
- Vorige versies 90 dagen na het maken verwijderen
{
"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"
]
}
}
}
]
}
Notitie
Het baseBlob-element in een levenscyclusbeheerbeleid verwijst naar de huidige versie van een blob. Het versie-element verwijst naar een eerdere versie.
Regelfilters
Filters beperken regelacties tot een subset van blobs binnen het opslagaccount. Als er meer dan één filter is gedefinieerd, wordt een logische uitvoering AND uitgevoerd op alle filters. U kunt een filter gebruiken om op te geven welke blobs moeten worden opgenomen. Een filter biedt geen middelen om op te geven welke blobs moeten worden uitgesloten.
Filters zijn onder andere:
| Filternaam | Filtertype | Opmerkingen | Is vereist |
|---|---|---|---|
| blobTypes | Een matrix met vooraf gedefinieerde enumwaarden. | De huidige release ondersteunt blockBlob en appendBlob. Alleen de actie Verwijderen wordt ondersteund voor appendBlob; Setlaag wordt niet ondersteund. |
Ja |
| prefixMatch | Een matrix met tekenreeksen voor voorvoegsels die moeten worden vergeleken. Elke regel kan maximaal 10 hoofdlettergevoelige voorvoegsels definiëren. Een voorvoegseltekenreeks moet beginnen met een containernaam. Als u bijvoorbeeld alle blobs wilt https://myaccount.blob.core.windows.net/sample-container/blob1/...vergelijken, geeft u het voorvoegselmatch op als sample-container/blob1. Dit filter komt overeen met alle blobs in de voorbeeldcontainer waarvan de namen beginnen met blob1.. |
Als u prefixMatch niet definieert, is de regel van toepassing op alle blobs in het opslagaccount. Voorvoegseltekenreeksen bieden geen ondersteuning voor jokertekenkoppeling. Tekens zoals * en ? worden behandeld als letterlijke tekenreeksen. |
Nee |
| blobIndexMatch | Een matrix met woordenlijstwaarden die bestaan uit sleutel- en waardevoorwaarden voor de blob-index die moeten worden vergeleken. Elke regel kan een voorwaarde van maximaal 10 blob-indextags definiëren. Als u bijvoorbeeld alle blobs wilt vergelijken met Project = Contoso onder https://myaccount.blob.core.windows.net/ voor een regel, is {"name": "Project","op": "==","value": "Contoso"}de blobIndexMatch. |
Als u blobIndexMatch niet definieert, is de regel van toepassing op alle blobs in het opslagaccount. | Nee |
Zie Gegevens beheren en zoeken in Azure Blob Storage met blob-index voor meer informatie over de functie blobindex, samen met bekende problemen en beperkingen.
Regelacties
Acties worden toegepast op de gefilterde blobs wanneer aan de uitvoeringsvoorwaarde wordt voldaan.
Levenscyclusbeheer biedt ondersteuning voor lagen en verwijdering van huidige versies, eerdere versies en blob-momentopnamen. Definieer ten minste één actie voor elke regel.
Notitie
Lagen worden nog niet ondersteund in een premium blok-blob-opslagaccount. Voor alle andere accounts is lagen alleen toegestaan voor blok-blobs en niet voor toevoeg- en pagina-blobs.
| Actie | Huidige versie | Momentopname | Vorige versies |
|---|---|---|---|
| tierToCool | Ondersteund voor blockBlob |
Ondersteund | Ondersteund |
| tierToCold | Ondersteund voor blockBlob |
Ondersteund | Ondersteund |
| enableAutoTierToHotFromCool1 | Ondersteund voor blockBlob |
Niet ondersteund | Niet ondersteund |
| tierToArchive4 | Ondersteund voor blockBlob |
Ondersteund | Ondersteund |
| verwijderen2,3 | Ondersteund voor blockBlob en appendBlob |
Ondersteund | Ondersteund |
1 De enableAutoTierToHotFromCool actie is alleen beschikbaar wanneer deze wordt gebruikt met de daysAfterLastAccessTimeGreaterThan uitvoeringsvoorwaarde. Deze voorwaarde wordt beschreven in de volgende tabel.
2 Wanneer deze wordt toegepast op een account waarvoor een hiërarchische naamruimte is ingeschakeld, verwijdert een verwijderactie lege mappen. Als de map niet leeg is, worden met de verwijderactie objecten verwijderd die voldoen aan de beleidsvoorwaarden binnen de eerste uitvoeringscyclus van het levenscyclusbeleid. Als deze actie resulteert in een lege map die ook voldoet aan de beleidsvoorwaarden, wordt die map verwijderd binnen de volgende uitvoeringscyclus, enzovoort.
3 Een levenscyclusbeheerbeleid verwijdert de huidige versie van een blob pas nadat eerdere versies of momentopnamen die aan die blob zijn gekoppeld, zijn verwijderd. Als blobs in uw opslagaccount eerdere versies of momentopnamen hebben, moet u eerdere versies en momentopnamen opnemen wanneer u een verwijderactie opgeeft als onderdeel van het beleid.
4 Alleen opslagaccounts die zijn geconfigureerd voor LRS, GRS of RA-GRS ondersteunen het verplaatsen van blobs naar de archieflaag. De archieflaag wordt niet ondersteund voor ZRS-, GZRS- of RA-GZRS-accounts. Deze actie wordt weergegeven op basis van de redundantie die is geconfigureerd voor het account.
Notitie
Als u meer dan één actie op dezelfde blob definieert, past levenscyclusbeheer de goedkoopste actie toe op de blob. Zo is actie delete goedkoper dan actie tierToArchive. Actie tierToArchive is goedkoper dan actie tierToCool.
De uitvoeringsvoorwaarden zijn gebaseerd op leeftijd. Huidige versies gebruiken de laatst gewijzigde tijd of laatste toegangstijd, vorige versies gebruiken de tijd voor het maken van de versie en blob-momentopnamen maken gebruik van de tijd voor het maken van momentopnamen om de leeftijd bij te houden.
| Voorwaarde voor actieuitvoering | Voorwaardewaarde | Beschrijving |
|---|---|---|
| daysAfterModificationGreaterThan | Integerwaarde die de leeftijd in dagen aangeeft | De voorwaarde voor acties op een huidige versie van een blob |
| daysAfterCreationGreaterThan | Integerwaarde die de leeftijd in dagen aangeeft | De voorwaarde voor acties op de huidige versie of vorige versie van een blob of een momentopname van een blob |
| daysAfterLastAccessTimeGreaterThan1 | Integerwaarde die de leeftijd in dagen aangeeft | De voorwaarde voor een huidige versie van een blob wanneer het bijhouden van toegang is ingeschakeld |
| daysAfterLastTierChangeGreaterThan | Integerwaarde die de leeftijd aangeeft in dagen na wijzigingstijd van de laatste bloblaag | De minimale duur in dagen dat een gerehydrateerde blob wordt bewaard in dynamische, statische of koude lagen voordat deze worden geretourneerd naar de archieflaag. Deze voorwaarde is alleen van toepassing op tierToArchive acties. |
1 Als het bijhouden van de laatste toegangstijd niet is ingeschakeld, gebruikt daysAfterLastAccessTimeGreaterThan de datum waarop het levenscyclusbeleid is ingeschakeld in plaats van de LastAccessTime eigenschap van de blob. Deze datum wordt ook gebruikt wanneer de LastAccessTime eigenschap een null-waarde is. Zie Gegevens verplaatsen op basis van de laatst geopende tijd voor meer informatie over het gebruik van het bijhouden van laatste toegangstijd.
Levenscyclusbeleid wordt uitgevoerd
Wanneer u een levenscyclusbeleid configureert of bewerkt, kan het tot 24 uur duren voordat wijzigingen van kracht worden en de eerste uitvoering wordt gestart. De tijd die nodig is om beleidsacties te voltooien, is afhankelijk van het aantal geëvalueerde en uitgevoerde blobs.
Als u een beleid uitschakelt, worden er geen nieuwe beleidsuitvoeringen gepland, maar als er al een uitvoering wordt uitgevoerd, wordt die uitvoering voortgezet totdat deze is voltooid en worden alle acties gefactureerd die nodig zijn om de uitvoering te voltooien. Zie Regionale beschikbaarheid en prijzen.
Voltooide gebeurtenis levenscyclusbeleid
De gebeurtenis LifecyclePolicyCompleted wordt gegenereerd wanneer de acties worden uitgevoerd die zijn gedefinieerd door een levenscyclusbeheerbeleid. Er wordt een overzichtssectie weergegeven voor elke actie die is opgenomen in de beleidsdefinitie. In de volgende json ziet u een voorbeeld LifecyclePolicyCompleted van een gebeurtenis voor een beleid. Omdat de beleidsdefinitie de delete, tierToCoolen tierToColdtierToArchive de acties bevat, wordt voor elke definitie een overzichtssectie weergegeven.
{
"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"
}
In de volgende tabel wordt het schema van de LifecyclePolicyCompleted gebeurtenis beschreven.
| Veld | Type | Description |
|---|---|---|
| scheduleTime | tekenreeks | Het tijdstip waarop het levenscyclusbeleid is gepland |
| deleteSummary | vector-byte<> | De resultatenoverzicht van blobs die zijn gepland voor verwijderingsbewerking |
| tierToCoolSummary | vector-byte<> | De resultatensamenvatting van blobs die zijn gepland voor de laag-naar-statische bewerking |
| tierToColdSummary | vector-byte<> | De resultatenoverzicht van blobs die zijn gepland voor laag-naar-koude bewerking |
| tierToArchiveSummary | vector-byte<> | De resultatenoverzicht van blobs die zijn gepland voor de laag-naar-archiefbewerking |
Voorbeelden van levenscyclusbeleid
In de volgende voorbeelden ziet u hoe u veelvoorkomende scenario's met levenscyclusbeleidsregels kunt aanpakken.
Verouderde gegevens verplaatsen naar een koeler laag
In dit voorbeeld ziet u hoe u blok-blobs met voorvoegsel sample-container/blob1 container2/blob2of . Het beleid gaat over van blobs die meer dan 30 dagen niet zijn gewijzigd in statische opslag en blobs die in 90 dagen niet zijn gewijzigd in de archieflaag:
{
"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 }
}
}
}
}
]
}
Gegevens verplaatsen op basis van laatste toegangstijd
U kunt het bijhouden van de laatste toegangstijd inschakelen om een record bij te houden wanneer uw blob voor het laatst is gelezen of geschreven en als filter voor het beheren van lagen en het bewaren van uw blobgegevens. Zie Optioneel toegangstijd bijhouden inschakelen voor informatie over het inschakelen van het bijhouden van laatste toegangstijd.
Wanneer het bijhouden van de laatste toegangstijd is ingeschakeld, wordt de aangeroepen LastAccessTime blobeigenschap bijgewerkt wanneer een blob wordt gelezen of geschreven. Een Get Blob-bewerking wordt beschouwd als een toegangsbewerking. Blobeigenschappen ophalen, Blobmetagegevens ophalen en Blob-tags ophalen hebben geen toegang tot bewerkingen en werk daarom de laatste toegangstijd niet bij.
Als het bijhouden van de laatste toegangstijd is ingeschakeld, wordt gebruikgemaakt LastAccessTime van levenscyclusbeheer om te bepalen of aan de uitvoeringsvoorwaarde daysAfterLastAccessTimeGreaterThan wordt voldaan. Levenscyclusbeheer gebruikt de datum waarop het levenscyclusbeleid is ingeschakeld in plaats van LastAccessTime in de volgende gevallen:
De waarde van de eigenschap van de
LastAccessTimeblob is een null-waarde.Notitie
De
lastAccessedOneigenschap van de blob is null als een blob niet is geopend sinds het bijhouden van de laatste toegangstijd is ingeschakeld.Het bijhouden van de laatste toegangstijd is niet ingeschakeld.
Als u het effect op de latentie van leestoegang wilt minimaliseren, wordt alleen de laatste 24 uur bijgewerkt met de eerste leesbewerking van de afgelopen 24 uur. Latere leesbewerkingen in dezelfde periode van 24 uur werken de laatste toegangstijd niet bij. Als een blob wordt gewijzigd tussen leesbewerkingen, is de laatste toegangstijd de laatste van de twee waarden.
In het volgende voorbeeld worden blobs verplaatst naar statische opslag als ze 30 dagen niet zijn geopend. De enableAutoTierToHotFromCool eigenschap is een Booleaanse waarde die aangeeft of een blob automatisch moet worden gelaagd van statisch naar dynamisch als deze opnieuw wordt geopend nadat deze is gelaagd naar statisch.
Tip
Als een blob wordt verplaatst naar de statische laag en vervolgens automatisch terug wordt verplaatst voordat 30 dagen zijn verstreken, worden kosten in rekening gebracht voor vroegtijdige verwijdering. Voordat u de enablAutoTierToHotFromCool eigenschap instelt, moet u de toegangspatronen van uw gegevens analyseren, zodat u onverwachte kosten kunt verlagen.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Gegevens archiveren na opname
Sommige gegevens blijven inactief in de cloud en worden zelden, indien ooit, geopend. Het volgende levenscyclusbeleid is geconfigureerd voor het archiveren van gegevens kort nadat deze zijn opgenomen. In dit voorbeeld worden blok-blobs in een container met de naam omgezet archivecontainer in een archieflaag. De overgang wordt uitgevoerd door blobs 0 dagen na de laatste wijzigingstijd uit te voeren.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Notitie
Microsoft raadt u aan uw blobs rechtstreeks naar de archieflaag te uploaden voor een grotere efficiëntie. U kunt de archieflaag opgeven in de header x-ms-access-tier op de bewerking Put Blob of Put Block List . De header x-ms-access-tier wordt ondersteund met REST-versie 2018-11-09 en hoger of de nieuwste blob storage-clientbibliotheken.
Gegevens laten verlopen op basis van leeftijd
Sommige gegevens verlopen naar verwachting dagen of maanden na het maken. U kunt een levenscyclusbeheerbeleid configureren om gegevens te laten verlopen door gegevens te verwijderen op basis van de leeftijd van de gegevens. In het volgende voorbeeld ziet u een beleid waarmee alle blok-blobs worden verwijderd die de afgelopen 365 dagen niet zijn gewijzigd.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Gegevens verwijderen met blobindextags
Sommige gegevens mogen alleen verlopen als ze expliciet zijn gemarkeerd voor verwijdering. U kunt een levenscyclusbeheerbeleid configureren om gegevens te laten verlopen die zijn gelabeld met kenmerken van de blob-indexsleutel/-waarde. In het volgende voorbeeld ziet u een beleid waarmee alle blok-blobs worden verwijderd die zijn getagd met Project = Contoso. Zie Gegevens beheren en zoeken in Azure Blob Storage met blob-index voor meer informatie over blobindex.
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Vorige versies beheren
Voor gegevens die gedurende de hele levensduur regelmatig worden gewijzigd en geopend, kunt u versiebeheer van blob-opslag inschakelen om automatisch eerdere versies van een object te onderhouden. U kunt een beleid maken om eerdere versies te tieren of te verwijderen. De leeftijd van de versie wordt bepaald door de aanmaaktijd van de versie te evalueren. Met deze beleidsregel worden eerdere versies binnen de container activedata verplaatst die 90 dagen of ouder zijn na het maken van de versie naar de statische laag en worden eerdere versies verwijderd die 365 dagen of ouder zijn.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Regionale beschikbaarheid en prijzen
De functie voor levenscyclusbeheer is beschikbaar in alle Azure-regio's.
Beleid voor levenscyclusbeheer is gratis. Klanten worden gefactureerd voor de standaardbewerkingskosten voor de API-aanroepen van de Blob-laag instellen. Verwijderingsbewerkingen zijn gratis. Andere Azure-services en -hulpprogramma's, zoals Microsoft Defender for Storage , kunnen echter kosten in rekening brengen voor bewerkingen die worden beheerd via een levenscyclusbeleid.
Elke update van de laatste toegangstijd van een blob wordt gefactureerd onder de andere bewerkingscategorie . Elke update van de laatste toegangstijd wordt maximaal één keer per 24 uur per object in rekening gebracht als een 'andere transactie', zelfs als deze 1000 keer per dag wordt geopend. Dit is gescheiden van kosten voor leestransacties.
Zie de Prijzen voor blok-blobs voor meer informatie over prijzen.
Bekende problemen en beperkingen
Lagen worden nog niet ondersteund in een premium blok-blob-opslagaccount. Voor alle andere accounts is lagen alleen toegestaan voor blok-blobs en niet voor toevoeg- en pagina-blobs.
Een levenscyclusbeheerbeleid moet volledig worden gelezen of geschreven. Gedeeltelijke updates worden niet ondersteund.
Elke regel kan maximaal 10 hoofdlettergevoelige voorvoegsels en maximaal 10 blobindextagvoorwaarden hebben.
Een levenscyclusbeheerbeleid kan de laag van een blob die gebruikmaakt van een versleutelingsbereik niet wijzigen.
De verwijderactie van een levenscyclusbeheerbeleid werkt niet met een blob in een onveranderbare container. Met een onveranderbaar beleid kunnen objecten worden gemaakt en gelezen, maar niet gewijzigd of verwijderd. Zie Bedrijfskritieke blobgegevens opslaan met onveranderbare opslag voor meer informatie.
Veelgestelde vragen
Zie veelgestelde vragen over levenscyclusbeheer.