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 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. En este escenario, la directiva de administración del ciclo de vida puede mover objetos del nivel de acceso frecuente al esporádico o de archivo y, asimismo, del nivel de acceso esporádico al de archivo.
  • 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.
  • Definir reglas que se ejecutarán una vez al día en el nivel de cuenta de almacenamiento
  • Aplicar reglas a contenedores o a un subconjunto de blobs mediante prefijos de nombre 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.

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.

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. En appendBlob solo se puede eliminar, no se puede establecer el nivel.
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 quiere que todos los blobs de https://myaccount.blob.core.windows.net/sample-container/blob1/... coincidan en una regla, prefixMatch es sample-container/blob1. Si no define prefixMatch, la regla se aplica a todos los blobs de la cuenta de almacenamiento. 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
enableAutoTierToHotFromCool Se admite para blockBlob No compatible No compatible
tierToArchive Se admite para blockBlob Compatible Compatible
delete1 Compatible en blockBlob y appendBlob. Compatible Compatible

1 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 24 horas. 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 24 horas, etc.

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 una versión anterior de un blob o una instantánea de blob
daysAfterLastAccessTimeGreaterThan 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.

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.

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.

{
  "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"
          ]
        }
      }
    }
  ]
}

Compatibilidad de características

La compatibilidad con esta característica puede verse afectada al habilitar Data Lake Storage Gen2, el protocolo Network File System (NFS) 3.0 o el Protocolo de transferencia de archivos SSH (SFTP).

Si ha habilitado cualquiera de estas funcionalidades, consulte Compatibilidad con características de Blob Storage en cuentas de Azure Storage para evaluar la compatibilidad con esta característica.

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.

Preguntas más frecuentes

He creado una directiva. ¿Por qué las acciones no se ejecutan inmediatamente?

La plataforma ejecuta la directiva del ciclo de vida una vez al día. Una vez configurada una directiva, puede tardar hasta 24 horas en entrar en vigor. Una vez que la directiva está en vigor, las acciones pueden tardar hasta 24 horas en ejecutarse por primera vez.

Si actualizo una directiva existente, ¿cuánto tiempo tardan en ejecutarse las acciones?

La directiva actualizada tarda hasta 24 horas en entrar en vigor. Una vez que la directiva está en vigor, las acciones pueden tardar hasta 24 horas en ejecutarse. Por lo tanto, las acciones de la directiva pueden tardar hasta 48 horas en completarse. Si la actualización va a deshabilitar o eliminar una regla y se ha usado enableAutoTierToHotFromCool, se seguirán haciendo niveles automáticos en el nivel de acceso de acceso frecuente. Por ejemplo, establezca una regla que incluya enableAutoTierToHotFromCool en función del último acceso. Si la regla está deshabilitada o eliminada, y un blob se encuentra actualmente en estado de nivel de acceso esporádico y, después, se accede a él, volverá al nivel de acceso frecuente, que es el que se aplica en el acceso fuera de la administración del ciclo de vida. Luego, el blob no pasará de nivel de acceso frecuente a nivel de acceso esporádico, ya que la regla de administración del ciclo de vida está deshabilitada o eliminada. La única manera de evitar autoTierToHotFromCool es desactivar el seguimiento de la hora del último acceso.

He rehidratado un blob archivado. ¿Cómo evito que vuelva temporalmente al nivel de archivo?

Si hay una directiva de administración del ciclo de vida en vigor para la cuenta de almacenamiento, la rehidratación de un blob cambiando su nivel puede dar lugar a un escenario en el que la directiva de ciclo de vida mueva el blob de nuevo al nivel de archivo. Esto puede ocurrir si la hora de la última modificación, la hora de creación o la hora de último acceso es posterior al umbral establecido para la directiva. Hay tres maneras de evitar que esto suceda:

  • Agregue la condición daysAfterLastTierChangeGreaterThan a la acción tierToArchive de la directiva. Esta condición solo se aplica a la hora de la última modificación. Vea Uso de directivas de administración del ciclo de vida para archivar blobs.

  • Deshabilite la regla que afecte temporalmente a este blob para impedir que se vuelva a archivar. Vuelva a habilitar la regla cuando el blob se pueda volver a mover con seguridad al nivel de archivo.

  • Si el blob debe permanecer permanentemente en el nivel de acceso frecuente o esporádico, copie el blob en otra ubicación donde la directiva de administración del ciclo de vida no esté en vigor.

La cadena de coincidencia del prefijo del blob no ha aplicado la directiva a los blobs previstos.

El campo de coincidencia del prefijo del blob de una directiva es una ruta de acceso de blob completa o parcial, que se usa para comparar la coincidencia con los blobs a los que desea que se apliquen las acciones de la directiva. La ruta de acceso debe comenzar con el nombre del contenedor. Si no se especifica ninguna coincidencia de prefijo, la directiva se aplicará a todos los blobs de la cuenta de almacenamiento. El formato de la cadena de coincidencia del prefijo es [container name]/[blob name].

Tenga en cuenta los puntos siguientes sobre la cadena de coincidencia del prefijo:

  • Una cadena de coincidencia del prefijo como container1/ se aplica a todos los blobs del contenedor denominado container1. Una cadena de coincidencia del prefijo como container1, sin el carácter de barra diagonal final (/), se aplica a todos los blobs de todos los contenedores en los que el nombre del contenedor comienza con la cadena container1. El prefijo coincidirá con los contenedores denominados container11, container1234, container1ab, etc.
  • Una cadena de coincidencia del prefijo como container1/sub1/ se aplica a todos los blobs del contenedor denominado container1 que empiecen por la cadena sub1/. Por ejemplo, el prefijo coincidirá con blobs denominados container1/sub1/test.txt o container1/sub1/sub2/test.txt.
  • El carácter de asterisco * es un carácter válido en un nombre de blob. Si el carácter de asterisco se usa en un prefijo, este coincidirá con blobs que tengan un asterisco en sus nombres. El asterisco no funciona como carácter comodín.
  • El signo de interrogación ? es un carácter válido en un nombre de blob. Si el signo de interrogación se usa en un prefijo, este coincidirá con blobs que tengan un signo de interrogación en sus nombres. El signo de interrogación no funciona como carácter comodín.
  • La coincidencia de prefijo solo tiene en cuenta comparaciones lógicas positivas (=). Las comparaciones lógicas negativas (!=) se ignoran.

¿Hay alguna manera de identificar el momento en el que se ejecutará la directiva?

Desafortunadamente, no hay forma de hacer un seguimiento del momento en el que se ejecutará la directiva, ya que es un proceso de programación en segundo plano. Pero la plataforma ejecutará la directiva una vez al día.

Pasos siguientes