Delen via


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 LastAccessTime blob is een null-waarde.

    Notitie

    De lastAccessedOn eigenschap 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.

Volgende stappen