Kosten optimaliseren door de levenscyclus van gegevens automatisch te beheren

Gegevenssets hebben unieke levenscycli. Vroeg in de levenscyclus hebben mensen vaak toegang tot bepaalde gegevens. Maar de behoefte aan toegang daalt vaak drastisch naarmate de gegevens ouder worden. Sommige gegevens blijven inactief in de cloud en worden zelden gebruikt nadat ze zijn opgeslagen. Sommige gegevenssets verlopen dagen of maanden na het maken, terwijl andere gegevenssets actief worden gelezen en gewijzigd gedurende hun levensduur. Azure Storage levenscyclusbeheer biedt een op regels gebaseerd beleid dat u kunt gebruiken om blobgegevens over te brengen naar de juiste toegangslagen of om gegevens aan het einde van de gegevenslevenscyclus te laten verlopen.

Met het beleid voor levenscyclusbeheer kunt u het volgende doen:

• Blobs direct overstappen van 'cool' naar 'hot' wanneer ze worden openen, om de prestaties te optimaliseren.
• Overgang van blobs, blobversies en blob-momentopnamen naar een lagere opslaglaag als deze objecten een bepaalde tijd niet zijn gebruikt of gewijzigd, om de kosten te optimaliseren. In dit scenario kan het beleid voor levenscyclusbeheer objecten verplaatsen van 'hot' naar 'cool', 'hot' naar 'archive' of van 'cool' naar 'archive'.
• Verwijder blobs, blobversies en blob-momentopnamen aan het einde van hun levenscyclus.
• Definieer regels die eenmaal per dag moeten worden uitgevoerd op het niveau van het opslagaccount.
• Regels toepassen op containers of op een subset van blobs, met behulp van naam voorvoegsels of blob-indextags als filters.

Denk aan een scenario waarin gegevens vaak worden gebruikt in de beginfasen van de levenscyclus, maar slechts af en toe na twee weken. Na de eerste maand wordt de gegevensset zelden geopend. In dit scenario is hot-opslag het beste tijdens de vroege fasen. Cool Storage is het meest geschikt voor incidentele toegang. Archive Storage is de beste optie na de leeftijden van gegevens gedurende een maand. Door gegevens naar de juiste opslaglaag te verplaatsen op basis van hun leeftijd met beleidsregels voor levenscyclusbeheer, kunt u de minst dure oplossing voor uw behoeften ontwerpen.

Levenscyclusbeheerbeleid wordt ondersteund voor blok-blobs en append-blobs in accounts voor algemeen gebruik v2, premium blok-blobs en blob-Storage accounts. Levenscyclusbeheer heeft geen invloed op systeemcontainers zoals de $logs of $web containers.

Beleidsdefinitie voor levenscyclusbeheer

Een beleid voor levenscyclusbeheer is een verzameling regels in een JSON-document. In het volgende voorbeeld van 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:

Elke regel binnen het beleid heeft verschillende parameters, zoals beschreven in de volgende tabel:

Definitie van levenscyclusbeheerregel

Elke regeldefinitie binnen een beleid bevat een filterset en een actieset. De filterset beperkt regelacties 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 aanwezig zijn in sample-container en te beginnen met blob1 .

• Laag-blob naar cool-laag 30 dagen na de laatste wijziging
• Laag-blob naar archieflaag 90 dagen na de laatste wijziging
• Blob 2555 dagen (zeven jaar) na de laatste wijziging verwijderen
• Vorige blobversies 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
            },
            "delete": {
              "daysAfterModificationGreaterThan": 2555
            }
          }
        },
        "filters": {
          "blobTypes": [
            "blockBlob"
          ],
          "prefixMatch": [
            "sample-container/blob1"
          ]
        }
      }
    }
  ]
}

Regelfilters

Filters beperken regelacties tot een subset van blobs binnen het opslagaccount. Als er meer dan één filter is gedefinieerd, wordt een AND logische filter uitgevoerd op alle filters.

Filters omvatten:

Zie Manage and find data on Azure Blob Storage with blob index (Gegevens beheren en vinden in Azure Blob Storage met blob-index) voor meerinformatie over de functie blob-index, samen met bekende problemen en beperkingen.

Regelacties

Acties worden toegepast op de gefilterde blobs wanneer aan de voorwaarde van de run wordt voldaan.

Levenscyclusbeheer ondersteunt opslaglagen en verwijdering van blobs, eerdere blobversies en blob-momentopnamen. Definieer ten minste één actie voor elke regel op basis-blobs, eerdere blobversies of blob-momentopnamen.

De voorwaarden voor de run zijn gebaseerd op leeftijd. Basis-blobs gebruiken het tijdstip waarop het laatst is gewijzigd, blobversies maken gebruik van de aanmaaktijd van de versie en blob-momentopnamen gebruiken de aanmaaktijd van de momentopname om de leeftijd bij te houden.

Voorbeelden van levenscyclusbeleid

De volgende voorbeelden laten zien hoe u algemene scenario's met levenscyclusbeleidsregels kunt aanpakken.

Verouderde gegevens verplaatsen naar een lagere categorie

In dit voorbeeld ziet u hoe u blok-blobs kunt overstappen met het voorvoegsel sample-container/blob1 of container2/blob2 . Met het beleid worden blobs die gedurende meer dan 30 dagen niet zijn gewijzigd, overge brengen naar cool storage en blobs die niet binnen 90 dagen zijn gewijzigd naar 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 de tijd die het laatst is gebruikt

U kunt bijhouden van de laatste toegangstijd inschakelen om een record bij te houden van wanneer uw blob voor het laatst is gelezen of geschreven, en als filter om opslaglagen en retentie van uw blobgegevens te beheren. Zie Optioneel toegangstijd bijhouden inschakelen voor meer informatie over het inschakelen van het bijhouden van tijd voor laatste toegang.

Wanneer het bijhouden van de laatste toegangstijd is ingeschakeld, wordt de blob-eigenschap met de naam LastAccessTime bijgewerkt wanneer een blob wordt gelezen of geschreven. Een Get Blob-bewerking wordt beschouwd als een toegangsbewerking. Blob-eigenschappen, Blobmetagegevens ophalen en Blob-tags op halen zijn geen toegangsbewerkingen en werken daarom niet de laatste toegangstijd bij.

Om de impact op de latentie van leestoegang te minimaliseren, wordt alleen de laatste toegangstijd bijgewerkt bij de eerste leestijd van de afgelopen 24 uur. Volgende lees leest in dezelfde periode van 24 uur worden de laatste toegangstijd niet bijgewerkt. Als een blob wordt gewijzigd tussen leeswaarden, is de laatste toegangstijd de recentste van de twee waarden.

In het volgende voorbeeld worden blobs verplaatst naar cool storage als ze al 30 dagen niet zijn gebruikt. De eigenschap is een Booleaanse waarde die aangeeft of een blob automatisch moet worden gelaagd van cool terug naar hot als deze opnieuw wordt gebruikt nadat deze is gelaagd enableAutoTierToHotFromCool naar cool.

{
  "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 of nooit gebruikt. 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 archivecontainer overge zetten naar een archieflaag. De overgang wordt bereikt door 0 dagen na de laatste wijzigingstijd op blobs te handelen:

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

Gegevens laten verlopen op basis van leeftijd

Sommige gegevens verlopen naar verwachting dagen of maanden na het maken. U kunt een beleid voor levenscyclusbeheer configureren om gegevens te laten verlopen door verwijdering op basis van gegevensleeftijd. In het volgende voorbeeld ziet u een beleid dat alle blok-blobs verwijdert die ouder zijn dan 365 dagen.

{
  "rules": [
    {
      "name": "expirationRule",
      "enabled": true,
      "type": "Lifecycle",
      "definition": {
        "filters": {
          "blobTypes": [ "blockBlob" ]
        },
        "actions": {
          "baseBlob": {
            "delete": { "daysAfterModificationGreaterThan": 365 }
          }
        }
      }
    }
  ]
}

Gegevens verwijderen met blob-indextags

Sommige gegevens mogen alleen verlopen als ze expliciet zijn gemarkeerd voor verwijdering. U kunt een beleid voor levenscyclusbeheer configureren om gegevens te laten verlopen die zijn getagd met kenmerken van de blobindexsleutel/-waarde. In het volgende voorbeeld ziet u een beleid dat alle blok-blobs verwijdert die zijn getagd met Project = Contoso . Zie Manage and find data on Azure Blob Storage with blob index (Preview) (Gegevens beheren en vinden in Azure Blob Storage met blob-index) voor meer informatie over de blob-index.

{
    "rules": [
        {
            "enabled": true,
            "name": "DeleteContosoData",
            "type": "Lifecycle",
            "definition": {
                "actions": {
                    "baseBlob": {
                        "delete": {
                            "daysAfterModificationGreaterThan": 0
                        }
                    }
                },
                "filters": {
                    "blobIndexMatch": [
                        {
                            "name": "Project",
                            "op": "==",
                            "value": "Contoso"
                        }
                    ],
                    "blobTypes": [
                        "blockBlob"
                    ]
                }
            }
        }
    ]
}

Versies beheren

Voor gegevens die gedurende de levensduur regelmatig worden gewijzigd en gebruikt, kunt u versieversies van blob-opslag inschakelen om automatisch eerdere versies van een object te onderhouden. U kunt een beleid maken om eerdere versies in een laag op te lagen of te verwijderen. De leeftijd van de versie wordt bepaald door de aanmaaktijd van de versie te evalueren. Met deze beleidsregel worden eerdere versies in een container geplaatst die 90 dagen of ouder zijn nadat de versie is gemaakt in de cool-laag en worden eerdere versies verwijderd die 365 dagen of ouder activedata zijn.

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

Functieondersteuning

In deze tabel ziet u hoe deze functie wordt ondersteund in uw account en wat de gevolgen zijn voor de ondersteuning wanneer u bepaalde mogelijkheden inschakelen.

Type opslagaccount	Blob Storage (standaardondersteuning)	Data Lake Storage Gen2 1	NFS 3.0 1	SFTP 1
Standaard algemeen gebruik v2
Premium blok-blobs maken

¹ Voor Data Lake Storage Gen2, het NFS-protocol (Network File System) 3.0 en de ondersteuning voor Secure File Transfer Protocol (SFTP) is allemaal een opslagaccount vereist waarvoor een hiërarchische naamruimte is ingeschakeld.

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 standaardkosten voor de API-aanroepen voor blob-lagen instellen. Verwijderbewerkingen zijn gratis.

Elke update van de laatste toegangstijd van een blob wordt gefactureerd in de andere bewerkingencategorie.

Zie Prijzen van Blok-blob voor meer informatie over prijzen.

Veelgestelde vragen

Ik heb een nieuw beleid gemaakt. Waarom worden de acties niet onmiddellijk uitgevoerd?

Het platform voert het levenscyclusbeleid eenmaal per dag uit. Zodra u een beleid hebt geconfigureerd, kan het tot 24 uur duren voordat sommige acties voor de eerste keer worden uitgevoerd.

Hoe lang duurt het voordat de acties worden uitgevoerd als ik een bestaand beleid bij werk?

Het duurt maximaal 24 uur voordat het bijgewerkte beleid van kracht wordt. Zodra het beleid van kracht is, kan het tot 24 uur duren voordat de acties worden uitgevoerd. Daarom kan het tot 48 uur duren voordat de beleidsacties zijn voltooid. Als de update is om een regel uit te schakelen of te verwijderen en enableAutoTierToHotFromCool is gebruikt, vindt automatische opslag in de laag Hot nog steeds gebruik. Stel bijvoorbeeld een regel in met enableAutoTierToHotFromCool op basis van de laatste toegang. Als de regel is uitgeschakeld/verwijderd en een blob momenteel in cool is en vervolgens wordt gebruikt, wordt deze teruggehebt naar Hot, omdat deze wordt toegepast op toegang buiten levenscyclusbeheer. De blob wordt dan niet verplaatst van Hot naar Cool, omdat de regel voor levenscyclusbeheer is uitgeschakeld/verwijderd. De enige manier om autoTierToHotFromCool te voorkomen, is door het bijhouden van de laatste toegangstijd uit te schakelen.

Ik heb een gearchiveerde blob handmatig gerehydrateerd. Hoe voorkom ik dat deze tijdelijk wordt verplaatst naar de archieflaag?

Wanneer een blob van de ene toegangslaag naar de andere wordt verplaatst, verandert de laatste wijzigingstijd niet. Als u een gearchiveerde blob handmatig rehydrateert naar een hot-laag, wordt deze door de engine voor levenscyclusbeheer terug naar de archieflaag verplaatst. Schakel de regel die van invloed is op deze blob tijdelijk uit om te voorkomen dat deze opnieuw wordt gearchiveerd. Schakel de regel opnieuw in wanneer de blob veilig kan worden verplaatst naar de archieflaag. U kunt de blob ook kopiëren naar een andere locatie als deze permanent in de hot- of cool-laag moet blijven.

Volgende stappen

• Een beleid voor levenscyclusbeheer configureren
• Hot-, Cool- en Archive-toegangslagen voor blobgegevens
• Gegevens beheren en vinden in Azure Blob-Storage met blob-index