Compartir por

Escritura en el nivel de contenedor una vez, leer muchas directivas (WORM) para datos de blobs inmutables

  • Artigo

Una vez que se escribe en el nivel de contenedor, se lee muchas directivas (WORM) es un tipo de directiva de inmutabilidad que se puede establecer en el nivel de contenedor. Para más información sobre el almacenamiento inmutable para Azure Blob Storage, consulte Almacenar datos de blobs críticos para la empresa con almacenamiento inmutable en una sola vez, leer muchos (WORM) de estado

Disponibilidad

Las directivas WORM (CLW) de nivel de contenedor están disponibles para todos los contenedores nuevos y existentes. Estas directivas son compatibles con cuentas de uso general v2, blob en bloques premium, v1 de uso general v1 (heredado) y almacenamiento de blobs (heredado).

Sugerencia

Microsoft recomienda actualizar las cuentas de uso general v1 a la versión 2 de uso general para que pueda aprovechar más características. Para obtener información sobre la actualización de una cuenta de almacenamiento de uso general v1 existente, vea Actualización de una cuenta de almacenamiento.

Esta característica es compatible con las cuentas de espacio de nombres jerárquicos. Si el espacio de nombres jerárquico está habilitado, no puede cambiar el nombre ni mover un blob cuando el blob está en estado inmutable. Tanto el nombre del blob como la estructura del directorio proporcionan datos esenciales de nivel de contenedor que no se pueden modificar una vez que la directiva inmutable está en vigor.

No hay ningún proceso de habilitación para esta característica; está disponible automáticamente para todos los contenedores. Para obtener más información acerca de cómo establecer una directiva en un contenedor nuevo o existente, consulte Configuración de directivas de inmutabilidad WORM de nivel de contenedor.

Eliminación

Un contenedor con un conjunto de directivas WORM de nivel de contenedor debe estar vacío antes de que se pueda eliminar el contenedor. Si hay una directiva establecida en un contenedor con el espacio de nombres jerárquico habilitado, un directorio debe estar vacío para poder eliminarlo.

Diagrama que muestra el orden de las operaciones en la eliminación de una cuenta que tiene una directiva WORM de nivel de contenedor.

Escenarios

Escenario Operaciones prohibidas Protección de blobs Protección de contenedores Protección de cuentas
Un contenedor está protegido por una directiva de retención con duración definida activa con ámbito de contenedor o hay en vigor una suspensión legal. Delete Blob, Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 Todos los blobs del contenedor son inmutables para los metadatos de contenido y usuario. Se produce un error en la eliminación de contenedores si una directiva WORM de nivel de contenedor está en vigor. Se produce un error en la eliminación de la cuenta de almacenamiento si hay un contenedor con al menos un blob presente.
Un contenedor está protegido por una directiva de retención con duración definida expirada con ámbito de contenedor y no hay en vigor una suspensión legal. Put Blob1, Set Blob Metadata, Put Page, Set Blob Properties, Snapshot Blob, Incremental Copy Blob, Append Block2 Se permiten las operaciones de eliminación. No se permiten las operaciones de sobrescritura. Se produce un error en la eliminación del contenedor si existe al menos un blob en el contenedor, independientemente de si la directiva está bloqueada o desbloqueada. Se produce un error en la eliminación de la cuenta de almacenamiento si hay al menos un contenedor con una directiva de retención con duración definida bloqueada.
Las directivas desbloqueadas no proporcionan protección de eliminación.

1 Azure Storage permite que la operación Put Blob cree un blob. No se permiten las operaciones de sobrescritura posteriores en una ruta de acceso de blob existente en un contenedor inmutable.

2 La operación Append Block solo se permite para las directivas con la propiedad allowProtectedAppendWrites o allowProtectedAppendWritesAll habilitada.

Permitir escrituras de blobs en anexos protegidos

Los blobs en anexos se componen de bloques de datos y se optimizan para las operaciones de anexión de datos necesarias en escenarios de auditoría y registro. Por diseño, los blobs en anexos solo permiten agregar nuevos bloques al final del blob. Con independencia de la inmutabilidad, la modificación o eliminación de los bloques existentes en un blob en anexos básicamente no se permite. Para más información sobre los blobs en anexos, vea Acerca de los blobs en anexos.

El valor de la propiedad allowProtectedAppendWrites permite escribir nuevos bloques en un blob en anexos y mantener la protección y el cumplimiento de la inmutabilidad. Si se habilita esta configuración, puede crear un blob en anexos directamente en el contenedor protegido por la directiva y, luego, continuar para agregar bloques nuevos de datos al final del blob en anexos con la operación Anexar bloque. Solo se pueden agregar bloques nuevos y los bloques existentes no se pueden modificar ni eliminar. La habilitación de esta configuración no afecta al comportamiento de inmutabilidad de los blobs en bloques ni los blobs en páginas.

El valor de la propiedad AllowProtectedAppendWritesAll proporciona los mismos permisos que la propiedad allowProtectedAppendWrites y agrega la capacidad de escribir nuevos bloques en un blob en bloques. La API de Blob Storage no proporciona una manera de que las aplicaciones lo hagan directamente. Sin embargo, las aplicaciones pueden hacerlo mediante métodos de anexión y vaciado, que están disponibles en la API de Data Lake Storage Gen2. Además, esta propiedad permite a las aplicaciones de Microsoft, como Azure Data Factory, anexar bloques de datos mediante api internas. Si las cargas de trabajo dependen de cualquiera de estas herramientas, puede usar esta propiedad para evitar errores que pueden aparecer cuando esas herramientas intentan anexar datos a blobs.

Los blobs anexos permanecen en estado inmutable durante el período de retención efectivo. Como se pueden anexar nuevos datos más allá de la creación inicial del blob en anexos, hay una ligera diferencia en el modo de determinar el período de retención. El período de retención efectivo es la diferencia entre la hora de última modificación del blob en anexos y el intervalo de retención especificado por el usuario. Como sucede al ampliar el intervalo de retención, el almacenamiento inmutable usa el valor más reciente del intervalo de retención especificado por el usuario para calcular el período de retención efectivo.

Por ejemplo, supongamos que un usuario crea una directiva de retención basada en el tiempo con el allowProtectedAppendWrites propiedad habilitada y un intervalo de retención de 90 días. En el día de hoy, se crea un blob en anexos, logblob1, en el contenedor y se siguen agregando registros nuevos al blob en anexos durante los próximos 10 días; por lo tanto, el período de retención efectivo de logblob1 es de 100 días a partir de hoy (la hora de la última anexión + 90 días).

Las directivas de retención de tiempo desbloqueadas permiten que los allowProtectedAppendWrites y la AllowProtectedAppendWritesAll configuración de propiedad se habilite y deshabilite en cualquier momento. Una vez bloqueada la directiva de retención basada en el tiempo, el allowProtectedAppendWrites y la AllowProtectedAppendWritesAll configuración de propiedad no se puede cambiar.

Límites

  • Para una cuenta de almacenamiento, el número máximo de contenedores con una directiva inmutable (retención basada en tiempo o suspensión legal) es de 10 000.

  • Para un contenedor, el número máximo de etiquetas de suspensión legal en cualquier momento es 10.

  • La longitud mínima de una etiqueta de suspensión legal es de tres caracteres alfanuméricos. La longitud máxima es de 23 caracteres alfanuméricos.

  • En el caso de un contenedor, se conservan un máximo de 10 registros de auditoría de directivas de suspensión legal durante la duración de la directiva.

Pasos siguientes