Optimizar los costes mediante la administración automática del ciclo de vida de los datos
Los conjuntos de datos tienen ciclos de vida únicos. Al principio del ciclo de vida, las personas acceden con frecuencia a algunos datos. Pero la necesidad de acceso suele descender drásticamente a medida que los datos se hacen más antiguos. Algunos datos permanecen inactivos en la nube y, una vez almacenados, no se suele acceder a ellos. Algunos conjuntos de datos expiran días o meses después de su creación, mientras que otros conjuntos de datos se leen y modifican de forma activa en el transcurso de sus ciclos de vida. La administración del ciclo de vida de Azure Blob Storage ofrece una directiva basada en reglas que se puede usar para trasladar los datos de blob al nivel de acceso adecuado y para hacer que los datos expiren cuando finalice su ciclo de vida.
Nota:
Cada actualización de la última hora de acceso se cobra como "otra transacción" como máximo una vez cada 24 horas por objeto, aunque se acceda a él miles de veces en un día. Esto es independiente de los cargos de las transacciones de lectura.
La directiva de administración del ciclo de vida permite hacer lo siguiente:
- Pasar blobs de nivel de acceso esporádico a nivel de acceso frecuente en el mismo instante en que se accede a ellos para optimizar el rendimiento.
- Pasar versiones actuales de un blob, versiones anteriores de un blob o instantáneas de blob a un nivel de almacenamiento de acceso esporádico si no se accede a estos objetos o si se modifican durante un período de tiempo para optimizar el coste.
- Eliminar las versiones actuales de un blob, las versiones anteriores de un blob o las instantáneas de blob al final de su ciclo de vida.
- Aplique reglas a toda una cuenta de almacenamiento, a contenedores seleccionados o a un subconjunto de blobs utilizando prefijos de nombres o etiquetas de índice de blobs como filtros.
Pensemos en un escenario donde se accede frecuentemente a los datos durante las primeras fases del ciclo de vida, pero solo ocasionalmente al cabo de dos semanas. Transcurrido el primer mes, rara vez se accede al conjunto de datos. En este escenario, es mejor el almacenamiento de acceso frecuente durante las primeras etapas. El almacenamiento de acceso esporádico es más adecuado para un acceso ocasional. El almacenamiento de archivo es la mejor opción de nivel una vez que los datos tengan un mes. Al mover datos al nivel de almacenamiento adecuado en función de su antigüedad mediante las reglas de directivas de administración del ciclo de vida, se puede diseñar la solución más asequible para sus necesidades.
Se pueden usar directivas de administración del ciclo de vida con blobs en bloques y blobs en anexos en cuentas de uso general v2, en cuentas de almacenamiento Premium de blobs en bloques y en cuentas de Blob Storage. La administración del ciclo de vida no afecta a los contenedores del sistema como $logs o $web.
Importante
Si un conjunto de datos debe ser legible, no establezca una directiva para mover blobs al nivel de archivo, ya que los blobs en este nivel no se pueden leer a menos que se rehidraten antes, un proceso que puede conllevar mucho tiempo y dinero. Para más información, consulte Introducción a la rehidratación de blobs desde el nivel de archivo. Si un conjunto de datos debe leerse con frecuencia, no establezca una directiva para mover blobs a los niveles de acceso esporádico, ya que esto podría dar lugar a mayores costos de transacción.
Definición de la directiva de administración del ciclo de vida
Una directiva de administración del ciclo de vida es una colección de reglas en un documento JSON. En el siguiente JSON de ejemplo se muestra una definición de regla completa:
{
"rules": [
{
"name": "rule1",
"enabled": true,
"type": "Lifecycle",
"definition": {...}
},
{
"name": "rule2",
"type": "Lifecycle",
"definition": {...}
}
]
}
Una directiva es una colección de reglas, como se describe en la siguiente tabla:
| Nombre de parámetro | Tipo de parámetro | Notas |
|---|---|---|
rules |
Una matriz de objetos de regla | Se requiere al menos una regla en una directiva. Puede definir hasta 100 reglas en una directiva. |
Cada regla de la directiva tiene varios parámetros, descritos en la siguiente tabla:
| Nombre de parámetro | Tipo de parámetro | Notas | Obligatorio |
|---|---|---|---|
name |
String | Un nombre de regla puede incluir hasta 256 caracteres alfanuméricos. El nombre de regla distingue mayúsculas de minúsculas. Debe ser único dentro de una directiva. | True |
enabled |
Boolean | Un valor booleano opcional para permitir que una regla se deshabilite de forma temporal. El valor predeterminado es true si no se establece. | False |
type |
Un valor de enumeración | El tipo actual válido es Lifecycle. |
True |
definition |
Un objeto que define la regla del ciclo de vida | Cada definición se compone de un conjunto de filtros y un conjunto de acciones. | True |
Definición de regla de administración del ciclo de vida
Cada definición de regla incluye un conjunto de filtros y un conjunto de acciones. El conjunto de filtros limita las acciones de regla a un determinado conjunto de objetos dentro de un contenedor o nombres de objetos. El conjunto de acciones aplica las acciones de nivel o eliminación al conjunto filtrado de objetos.
Ejemplo de regla
La siguiente regla de ejemplo filtra la cuenta para ejecutar las acciones en objetos que existen dentro de sample-container y empiezan por blob1.
- Establecer el nivel de blob en nivel esporádico 30 días después de la última modificación
- Establecer el nivel de blob en nivel de almacenamiento de archivo 90 días después de la última modificación
- Eliminar el blob 2555 días (siete años) después de la última modificación
- Eliminar las versiones anteriores 90 días después de su creación
{
"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"
]
}
}
}
]
}
Nota
El elemento baseBlob de una directiva de administración del ciclo de vida hace referencia a la versión actual de un blob. El elemento version hace referencia a una versión anterior.
Filtros de reglas
Los filtros limitan las acciones de regla a un subconjunto de blobs dentro de la cuenta de almacenamiento. Si se define más de un filtro, se ejecuta un valor lógico AND en todos los filtros. Puede usar un filtro para especificar qué blobs se van a incluir. Un filtro no proporciona ningún medio para especificar qué blobs excluir.
Entre los filtros están los siguientes:
| Nombre de filtro | Tipo de filtro | Notas | Es obligatorio |
|---|---|---|---|
| blobTypes | Una matriz de valores de enumeración predefinidos. | La versión actual admite blockBlob y appendBlob. Solo se admite la acción Eliminar para appendBlob; No se admite el nivel establecido. |
Sí |
| prefixMatch | Una matriz de cadenas de prefijos con los que debe hacer coincidencias. Cada regla puede definir hasta 10 prefijos (con distinción entre mayúsculas y minúsculas). Una cadena de prefijos debe comenzar con el nombre de un contenedor. Por ejemplo, si desea coincidir con todos los blobs,https://myaccount.blob.core.windows.net/sample-container/blob1/... especifique el prefixMatch como sample-container/blob1. Este filtro coincidirá con todos los blobs de contenedor de muestra cuyos nombres comienzan por blob1.. |
Si no define prefixMatch, la regla se aplica a todos los blobs de la cuenta de almacenamiento. Las cadenas de prefijo no admiten la coincidencia de caracteres comodín. Los caracteres como * y ? se tratan como literales de cadena. |
No |
| blobIndexMatch | Una matriz de valores de diccionario que se compone de las condiciones de clave y valor de la etiqueta de índice de blobs con las que debe haber coincidencias. Cada regla puede definir hasta 10 condiciones de etiqueta de índice de blobs. Por ejemplo, si quiere que todos los blobs coincidan con Project = Contoso en https://myaccount.blob.core.windows.net/ en relación a una regla, el valor de blobIndexMatch es {"name": "Project","op": "==","value": "Contoso"}. |
Si no define blobIndexMatch, la regla se aplica a todos los blobs de la cuenta de almacenamiento. | No |
Para obtener más información sobre la característica de índice de blobs, así como sus limitaciones y problemas conocidos, consulte Administración y búsqueda de datos en Azure Blob Storage con el índice de blobs.
Acciones de regla
Las acciones se aplican a los blobs filtrados cuando se cumple la condición de ejecución.
La administración del ciclo de vida admite tanto la organización en niveles como la eliminación de versiones actuales, versiones anteriores e instantáneas de blobs. Defina al menos una acción para cada regla.
Nota
Todavía no se admite la creación de niveles en una cuenta de almacenamiento de blobs en bloques prémium. Para todas las demás cuentas, la organización por niveles solo se permite en los blobs en bloques y no para los blobs en anexos y en páginas.
| Acción | Versión actual | Instantánea | Versiones anteriores |
|---|---|---|---|
| tierToCool | Se admite para blockBlob |
Compatible | Compatible |
| tierToCold | Se admite para blockBlob |
Compatible | Compatible |
| enableAutoTierToHotFromCool1 | Se admite para blockBlob |
No compatible | No compatible |
| tierToArchive4 | Se admite para blockBlob |
Compatible | Compatible |
| delete2,3 | Compatible en blockBlob y appendBlob. |
Compatible | Compatible |
1 La acción enableAutoTierToHotFromCool solo está disponible cuando se usa con la condición de ejecución daysAfterLastAccessTimeGreaterThan. Esa condición se describe en la tabla siguiente.
2 Cuando se aplica a una cuenta con un espacio de nombres jerárquico habilitado, una acción de eliminación quita los directorios vacíos. Si el directorio no está vacío, la acción de eliminación quita los objetos que cumplen las condiciones de la directiva dentro del primer ciclo de ejecución de la directiva del ciclo de vida. Si esa acción da como resultado un directorio vacío que también cumple las condiciones de la directiva, ese directorio se quitará en el siguiente ciclo de ejecución, etc.
3 Una directiva de administración del ciclo de vida no eliminará la versión actual de un blob hasta que se hayan eliminado las versiones o instantáneas anteriores asociadas a ese blob. Si los blobs de la cuenta de almacenamiento tienen versiones o instantáneas anteriores, debe incluir versiones e instantáneas anteriores al especificar una acción de eliminación como parte de la directiva.
4 Solo las cuentas de almacenamiento configuradas para LRS, GRS o RA-GRS admiten el traslado de blobs al nivel de archivo. El nivel de archivo no se admite en las cuentas de ZRS, GZRS o RA-GZRS. Esta acción aparece en función de la redundancia configurada para la cuenta.
Nota
Si define más de una acción en el mismo blob, la administración del ciclo de vida aplica la acción menos cara al blob. Por ejemplo, la acción delete es más económica que la acción tierToArchive. La acción tierToArchive es más económica que la acción tierToCool.
Las condiciones de ejecución se basan en la antigüedad. Para realizar el seguimiento de la antigüedad, las versiones actuales usan la hora de la última modificación o del último acceso, las versiones anteriores usan la hora de creación de la versión y las instantáneas de blobs usan la hora de creación de la instantánea.
| Condición de ejecución de acción | Valor de la condición | Descripción |
|---|---|---|
| daysAfterModificationGreaterThan | Valor entero que indica la antigüedad en días | Condición de las acciones en una versión actual de un blob |
| daysAfterCreationGreaterThan | Valor entero que indica la antigüedad en días | Condición de las acciones en la versión actual o en una versión anterior de un blob o una instantánea de blob |
| daysAfterLastAccessTimeGreaterThan1 | Valor entero que indica la antigüedad en días | Condición de una versión actual de un blob cuando está habilitado el seguimiento de acceso |
| daysAfterLastTierChangeGreaterThan | Valor entero que indica la antigüedad en días después de la hora de cambio del último nivel de blob | Esta condición solo se aplica a las acciones tierToArchive y solo se puede usar con la condición daysAfterModificationGreaterThan. |
1 Si el seguimiento de la hora del último acceso no está habilitado, daysAfterLastAccessTimeGreaterThan usa la fecha en que se habilitó la directiva de ciclo de vida en lugar de la propiedad LastAccessTime del blob. Esta fecha también se usa cuando la propiedad LastAccessTime es un valor NULL. Para obtener más información sobre el uso del seguimiento de la hora de último acceso, consulte Traslado de datos en función de la hora de acceso anterior.
Ejecuciones de directivas de ciclo de vida
La plataforma ejecuta la directiva del ciclo de vida una vez al día. Al configurar o editar una directiva de ciclo de vida, los cambios pueden tardar hasta 24 horas en entrar en vigor y para que se inicie la primera ejecución. El tiempo necesario para que se completen las acciones de la directiva depende del número de blobs evaluados y operados.
Si deshabilita una directiva, no se programarán nuevas ejecuciones de directivas, pero si una ejecución ya está en curso, esa ejecución continuará hasta que se complete y se le facturarán las acciones necesarias para completar la ejecución. ConsulteDisponibilidad regional y precios.
Evento de la directiva del ciclo de vida completado
El evento LifecyclePolicyCompleted se genera se realizan las acciones definidas por una directiva de administración del ciclo de vida. En el siguiente fragmento de código JSON se muestra un evento LifecyclePolicyCompleted de ejemplo:
{
"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": ""
},
"tierToArchiveSummary": {
"totalObjectsCount": 0,
"successCount": 0,
"errorList": ""
}
},
"dataVersion": "1",
"metadataVersion": "1"
}
En la siguiente tabla se describe el esquema del evento LifecyclePolicyCompleted:
| Campo | Tipo | Descripción |
|---|---|---|
| scheduleTime | string | La hora a la que se programó la directiva del ciclo de vida. |
| deleteSummary | <byte>vectorial | Resumen de resultados de los blobs programados para la operación de eliminación |
| tierToCoolSummary | <byte>vectorial | Resumen de resultados de los blobs programados para la operación de nivel de acceso esporádico |
| tierToArchiveSummary | <byte>vectorial | Resumen de resultados de los blobs programados para la operación de nivel de acceso de archivo |
Ejemplos de directivas de ciclo de vida
Los ejemplos siguientes muestran cómo abordar escenarios comunes con las reglas de directivas del ciclo de vida.
Cambio de los datos antiguos a un nivel de acceso más esporádico
En este ejemplo se muestra cómo realizar la transición de blobs en bloques con el prefijo sample-container/blob1 o container2/blob2. La directiva realiza la transición de los blobs que no se han modificado durante más de 30 días al almacenamiento de acceso esporádico, y los blobs no modificados en 90 días al nivel de acceso de archivo:
{
"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 }
}
}
}
}
]
}
Mover datos en función de la hora de último acceso
Se puede habilitar el seguimiento de la hora de último acceso para mantener un registro de cuándo se lee o escribe por última vez el blob y también como filtro para administrar los niveles y la retención de los datos de blob. Para obtener información sobre cómo habilitar el seguimiento de la hora de último acceso, consulte Habilitar el seguimiento de hora de acceso opcionalmente.
Si se habilita el seguimiento de la hora del último acceso, la propiedad de blob denominada LastAccessTime se actualiza cuando se lee o se escribe en un blob. Una operación Get Blob se considera una operación de acceso. Get Blob Properties, Get Blob Metadata y Get Blob Tags no son operaciones de acceso y, por lo tanto, no actualizan la hora del último acceso.
Si el seguimiento de la hora de último acceso está habilitado, la administración del ciclo de vida usa LastAccessTime para determinar si se cumple la condición de ejecución daysAfterLastAccessTimeGreaterThan. La administración del ciclo de vida usa la fecha en que se ha habilitado la directiva de ciclo de vida en lugar de LastAccessTime en los casos siguientes:
El valor de la propiedad
LastAccessTimedel blob es un valor NULL.Nota
La propiedad
lastAccessedOndel blob es null si no se ha accedido a un blob desde que se ha habilitado el seguimiento de la hora de último acceso.El seguimiento de la hora de último acceso no está habilitado.
Para reducir el efecto en la latencia del acceso de lectura, solo la primera lectura de las últimas 24 horas actualiza la hora del último acceso. Las lecturas posteriores en el mismo período de 24 horas no la actualizan. Si se modifica un blob entre lecturas, la hora del último acceso es la más reciente de los dos valores.
En el siguiente ejemplo, los blobs se mueven al almacenamiento esporádico si no se ha accedido a ellos durante 30 días. La propiedad enableAutoTierToHotFromCool es un valor booleano que indica si un blob debe pasar automáticamente del nivel de acceso esporádico al nivel de acceso frecuente si se vuelve a acceder a él una vez que se haya pasado al nivel de acceso esporádico.
Sugerencia
Si un blob se traslada al nivel frío y luego se vuelve a trasladar automáticamente antes de que hayan transcurrido 30 días, se cobrará una tasa por eliminación anticipada. Antes de establecer la enablAutoTierToHotFromCool propiedad, asegúrese de analizar los patrones de acceso de los datos para que pueda reducir cargos inesperados.
{
"enabled": true,
"name": "last-accessed-thirty-days-ago",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"enableAutoTierToHotFromCool": true,
"tierToCool": {
"daysAfterLastAccessTimeGreaterThan": 30
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"mylifecyclecontainer/log"
]
}
}
}
Archivado de datos después de la ingesta
Algunos datos permanecen inactivos en la nube y no se accede a ellos prácticamente nunca. La siguiente directiva del ciclo de vida está configurada para archivar los datos poco después de que se ingieran. En este ejemplo se realiza la transición de blobs en bloques de un contenedor denominado archivecontainer a un nivel de archivo. La transición se realiza al actuar en los blobs 0 días después de la hora de la última modificación.
{
"rules": [
{
"name": "archiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ],
"prefixMatch": [ "archivecontainer" ]
},
"actions": {
"baseBlob": {
"tierToArchive": {
"daysAfterModificationGreaterThan": 0
}
}
}
}
}
]
}
Nota
Microsoft recomienda cargar los blobs directamente en el nivel de archivo para lograr una mayor eficacia. El nivel de archivo se puede especificar en el encabezado x-ms-access-tier de las operaciones Put Blob o Put Block List. El encabezado x-ms-access-tier se puede usar con la versión de REST 2018-11-09 y versiones más recientes o con las bibliotecas cliente de Blob Storage más recientes.
Expiración de datos en función de la antigüedad
Se espera que algunos datos expiren días o meses después de la creación. Puede configurar una directiva de administración del ciclo de vida para que los datos expiren mediante eliminación en función de su antigüedad. En el ejemplo siguiente se muestra una directiva que elimina todos los blobs en bloques que no se han modificado en los últimos 365 días.
{
"rules": [
{
"name": "expirationRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": {
"blobTypes": [ "blockBlob" ]
},
"actions": {
"baseBlob": {
"delete": { "daysAfterModificationGreaterThan": 365 }
}
}
}
}
]
}
Eliminar datos con etiquetas de índice de blobs
Algunos datos solo deben expirar si se marcan explícitamente para su eliminación. Puede configurar una directiva de administración del ciclo de vida para que expiren los datos etiquetados con los atributos de clave/valor del índice de blobs. En el ejemplo siguiente se muestra una directiva que elimina todos los blobs en bloques con Project = Contoso. Para más información sobre el índice de blobs, consulte Administración y búsqueda de datos en Azure Blob Storage con el índice de blobs (versión preliminar).
{
"rules": [
{
"enabled": true,
"name": "DeleteContosoData",
"type": "Lifecycle",
"definition": {
"actions": {
"baseBlob": {
"delete": {
"daysAfterModificationGreaterThan": 0
}
}
},
"filters": {
"blobIndexMatch": [
{
"name": "Project",
"op": "==",
"value": "Contoso"
}
],
"blobTypes": [
"blockBlob"
]
}
}
}
]
}
Administración de versiones anteriores
En el caso de datos que se modifican y a los que se accede de forma regular a lo largo de toda su duración, puede habilitar el control de versiones de Blob Storage para mantener de forma automática las versiones anteriores de un objeto. Puede crear una directiva para organizar en niveles o eliminar las versiones anteriores. La antigüedad de la versión se determina mediante la evaluación de la hora de creación de la misma. Esta regla de directiva mueve las versiones anteriores en el contenedor activedata que tengan 90 días, o más, posteriores a la creación de la versión en el nivel de acceso esporádico, y elimina las versiones anteriores que tengan 365 días, o más.
{
"rules": [
{
"enabled": true,
"name": "versionrule",
"type": "Lifecycle",
"definition": {
"actions": {
"version": {
"tierToCool": {
"daysAfterCreationGreaterThan": 90
},
"delete": {
"daysAfterCreationGreaterThan": 365
}
}
},
"filters": {
"blobTypes": [
"blockBlob"
],
"prefixMatch": [
"activedata/"
]
}
}
}
]
}
Disponibilidad regional y precios
La característica de administración del ciclo de vida está disponible en todas las regiones de Azure.
Las directivas de administración del ciclo de vida son gratuitas. A los clientes se les cobra el coste operativo estándar derivado de las llamadas API Set Blob Tier. Las operaciones de eliminación también son gratuitas. Sin embargo, otros servicios y utilidades de Azure, como Microsoft Defender para Storage, pueden cobrar por las operaciones que se administran mediante una directiva de ciclo de vida.
Cada actualización a la hora de último acceso de un blob se factura bajo la categoría Todas las demás operaciones.
Para más información sobre los precios, consulte Precios de los blobs en bloques.
Problemas y limitaciones conocidos
Todavía no se admite la creación de niveles en una cuenta de almacenamiento de blobs en bloques prémium. Para todas las demás cuentas, la organización por niveles solo se permite en los blobs en bloques y no para los blobs en anexos y en páginas.
Una directiva de administración del ciclo de vida se debe leer o escribir completamente. No se admiten las actualizaciones parciales.
Cada regla puede tener hasta 10 prefijos que distinguen mayúsculas de minúsculas y hasta 10 condiciones de etiqueta de índice de blobs.
Si habilita reglas de firewall para la cuenta de almacenamiento, puede que se bloqueen las solicitudes de administración del ciclo de vida. Puede desbloquear estas solicitudes proporcionando excepciones para los servicios de confianza de Microsoft. Para obtener más información, consulte la sección Excepciones de Configuración de redes virtuales y firewalls de Azure Storage.
Una directiva de administración del ciclo de vida no puede cambiar el nivel de un blob que usa un ámbito de cifrado.
La acción de eliminación de una directiva de administración del ciclo de vida no funcionará con ningún blob en un contenedor inmutable. Con una directiva inmutable, los objetos se pueden crear y leer, pero no modificar ni eliminar. Para más información, consulte Almacenamiento de datos de blobs críticos para la empresa con almacenamiento inmutable.
Preguntas más frecuentes
Consulte Preguntas más frecuentes sobre la administración del ciclo de vida.