Replicación de objetos para blobs en bloques
La replicación de objetos copia asincrónicamente los blobs en bloques entre una cuenta de almacenamiento de origen y una de destino. Algunos escenarios que admite la replicación de objetos son:
- Minimización de latencia. La replicación de objetos puede reducir la latencia de las solicitudes de lectura al permitir a los clientes consumir datos de una región que esté más cerca físicamente.
- Aumentar la eficiencia de las cargas de trabajo de proceso. Con la replicación de objetos, las cargas de trabajo de proceso pueden procesar los mismos conjuntos de blob en bloques en diferentes regiones.
- Optimizar la distribución de datos. Puede procesar o analizar los datos en una sola ubicación y luego replicar sólo los resultados en regiones adicionales.
- Optimizar los costos. Después de replicar los datos, puede reducir los costos moviéndolos al nivel de archivo mediante las directivas de administración del ciclo de vida.
El siguiente diagrama muestra cómo la replicación de objetos replica blob en bloques de una cuenta de almacenamiento de origen en una región a cuentas de destino en dos regiones diferentes.
Para información sobre cómo configurar la replicación de objetos, consulte Configuración de la replicación de objetos.
Requisitos previos y advertencias para la replicación de objetos
La replicación de objetos requiere que también estén habilitadas las características de Azure Storage siguientes:
- Fuente de cambios: debe estar habilitada en la cuenta de origen. Para información sobre cómo habilitar la fuente de cambios, consulte Habilitar y deshabilitar la fuente de cambios.
- Control de versiones de blobs: debe estar habilitado en la cuenta de origen y en la cuenta de destino. Para información sobre cómo habilitar el control de versiones, consulte Habilitación y administración del control de versiones de blobs.
Habilitar la fuente de cambios y el control de versiones de blob puede suponer costos adicionales. Para obtener más información, consulte la página de precios de Azure Storage.
La replicación de objetos es compatible con las cuentas de almacenamiento de uso general v2 y las cuentas de almacenamiento de blobs en bloques prémium. Las cuentas de origen y de destino deben ser cuentas de uso v2 o de blob en bloques prémium. La replicación de objetos solo admite los blobs en bloques; no se admiten los blobs en anexos ni los blobs en páginas.
La replicación de objetos es compatible con cuentas cifradas con claves gestionadas por Microsoft o por el cliente. Para más información sobre las claves administradas por el cliente, consulte Claves administradas por el cliente para el cifrado de Azure Storage.
La replicación de objetos no se admite para los blobs de la cuenta de origen que se cifran con una clave proporcionada por el cliente. Para más información sobre las claves proporcionadas por el cliente, consulte Especificación de una clave de cifrado en una solicitud a Blob Storage.
No se admite la conmutación por error administrada por el cliente de la cuenta de origen o de destino en una directiva de replicación de objetos.
No se admite la replicación de objetos para blobs cargados mediante las API de Data Lake Storage Gen2.
Funcionamiento de la replicación de objetos
La replicación asincrónica de objetos copia blobs en bloques en un contenedor según las reglas que configure. El contenido del blob, las versiones asociadas al blob y los metadatos y las propiedades del blob se copian desde el contenedor de origen al contenedor de destino.
Importante
Debido a que los datos de blob en bloques se replican asincrónicamente, la cuenta de origen y la de destino no están inmediatamente sincronizadas. Actualmente no hay ningún acuerdo de nivel de servicio sobre cuánto tiempo se tarda en replicar los datos en la cuenta de destino. Puede comprobar el estado de replicación en el blob de origen para determinar si se ha completado la replicación. Para más información, consulte el apartado Comprobación del estado de replicación de un blob.
Control de versiones de blobs
La replicación de objetos requiere que el control de versiones de los blobs esté habilitado en las cuentas de origen y de destino. Cuando se modifica un blob replicado de la cuenta de origen, se crea una nueva versión del blob en la cuenta de origen que refleja el estado anterior del mismo antes de la modificación. La versión actual de la cuenta de origen refleja las actualizaciones más recientes. Tanto la versión actual como cualquier versión anterior se replican en la cuenta de destino. Para más información sobre la forma en que las operaciones de escritura afectan a las versiones del blob, consulte Control de versiones en operaciones de escritura.
Si la cuenta de almacenamiento tiene directivas de replicación de objetos en vigor, no puede deshabilitar el control de versiones de blobs para esa cuenta. Debe eliminar las directivas de replicación de objetos de la cuenta para poder deshabilitar el control de versiones de blobs.
Eliminación de un blob en la cuenta de origen
Cuando se elimina un blob de la cuenta de origen, la versión actual del blob se convierte en una versión anterior y deja de haber una versión actual. Todas las versiones del blob que ya existieran previamente se conservan. Este estado se replica en la cuenta de destino. Para obtener más información sobre la forma en que las operaciones de eliminación afectan a las versiones del blob, consulte Control de versiones en operaciones de eliminación.
Instantáneas
La replicación de objetos no admite instantáneas de blobs. Las instantáneas de un blob de la cuenta de origen no se replican en la cuenta de destino.
Etiquetas de índice de blobs
La replicación de objetos no copia las etiquetas de índice del blob de origen al blob de destino.
Niveles de blob
La replicación de objetos se admite cuando las cuentas de origen y de destino se encuentran en el nivel de acceso frecuente o esporádico. Las cuentas de origen y destino pueden estar en niveles diferentes. Sin embargo, se producirá un error en la replicación de objetos si un blob de las cuentas de origen o destino se ha movido al nivel de archivo. Para obtener más información sobre los niveles de blob, vea Niveles de acceso para datos de blob.
Blobs inalterables
Las directivas de inmutabilidad para Azure Blob Storage incluyen directivas de retención de duración definida y suspensiones legales. Cuando hay una directiva de inmutabilidad en vigor en la cuenta de destino, la replicación de objetos puede verse afectada. Para obtener más información sobre las directivas de inmutabilidad, consulte Almacenamiento de datos de blobs críticos para la empresa con almacenamiento inmutable.
Si hay una directiva de inmutabilidad de nivel de contenedor en vigor para un contenedor de la cuenta de destino y un objeto del contenedor de origen se actualiza o se elimina, puede que la operación del contenedor de origen se realice correctamente, pero se producirá un error en la replicación de dicha operación en el contenedor de destino. Para obtener más información sobre qué operaciones están prohibidas con una directiva de inmutabilidad cuyo ámbito es un contenedor, consulte Escenarios con ámbito a nivel de contenedor.
Si hay una directiva de inmutabilidad de nivel de versión en vigor para la versión de un blob de la cuenta de destino y se realiza una operación de eliminación o actualización en la versión del blob del contenedor de origen, puede que la operación se realice correctamente en el objeto de origen, pero se producirá un error en la replicación de dicha operación en el objeto de destino. Para obtener más información sobre qué operaciones están prohibidas con una directiva de inmutabilidad cuyo ámbito es un contenedor, consulte Escenarios con ámbito a nivel de versión.
Reglas y directivas de replicación de objetos
Al configura la replicación de objetos, se crea una política de replicación que especifica la cuenta de almacenamiento de origen y la cuenta de destino. Una directiva de replicación incluye una o más reglas que especifican un contenedor de origen y un contenedor de destino e indican qué blob en bloques del contenedor de origen se replicarán.
Después de configurar la replicación de objetos, Azure Storage comprueba periódicamente la fuente de cambios de la cuenta de origen y replica asincrónicamente cualquier operación de escritura o borrada a la cuenta de destino. La latencia de replicación depende del tamaño del blob en bloques que se está replicando.
Directivas de replicación
Al configurar la replicación de objetos, se crea una directiva de replicación en la cuenta de destino a través del proveedor de recursos de Azure Storage. Una vez creada la directiva de replicación, Azure Storage le asigna un identificador de directiva. A continuación, debe asociar esa directiva de replicación con la cuenta de origen mediante el identificador de directiva. El identificador de directiva de las cuentas de origen y de destino debe ser el mismo para que tenga lugar la replicación.
Una cuenta de origen se puede replicar en un máximo de dos cuentas de destino, con una directiva para cada cuenta de destino. De forma similar, una cuenta puede actuar como cuenta de destino para un máximo de dos directivas de replicación.
Las cuentas de origen y de destino pueden estar en la misma región o en regiones diferentes. También pueden residir en la misma suscripción o en suscripciones diferentes. Opcionalmente, las cuentas de origen y destino pueden residir en diferentes inquilinos de Microsoft Entra. Solo se puede crear una directiva de replicación para cada par de cuentas de origen/cuentas de destino.
Reglas de replicación
Las reglas de replicación especifican el modo en que Azure Storage replicará los blobs de un contenedor de origen a un contenedor de destino. Puede especificar un máximo de 1000 reglas de replicación para cada directiva de replicación. Cada regla de replicación define un solo contenedor de origen y otro de destino, y cada contenedor de origen y de destino solo se puede usar en una regla, lo que significa que en una única directiva de replicación no pueden participar más de 1000 contenedores de origen y 1000 contenedores de destino.
Al crear una regla de replicación, de forma predeterminada solo se copian los blobs en bloques nuevos que se agreguen posteriormente al contenedor de origen. Puede especificar que se copien tanto los blob en bloques nuevos como los ya existentes, o bien puede definir un ámbito de copia personalizado que copie los blobs en bloques creados a partir de un momento determinado.
También puede especificar uno o varios filtros como parte de una regla de replicación para filtrar los blobs en bloques por prefijo. Cuando se especifica un prefijo, solo los blobs que coinciden con ese prefijo en el contenedor de origen se copiarán en el contenedor de destino.
Los contenedores de origen y de destino deben existir antes de poder especificarlos en una regla. Después de crear la directiva de replicación, no se permiten las operaciones de escritura en el contenedor de destino. Cualquier intento de escribir en el contenedor de destino producirá un error con el código de error 409 (Conflicto). Para escribir en un contenedor de destino para el que esté configurada una regla de replicación, debe eliminar la regla que está configurada para ese contenedor o quitar la directiva de replicación. Las operaciones de lectura y eliminación en el contenedor de destino se permiten cuando la directiva de replicación está activa.
Puede llamar a la operación Establecer el nivel del blob en un blob en el contenedor de destino para moverla al nivel de archivo. Para obtener más información sobre el nivel de archivo, vea Niveles de acceso para datos de blobs.
Nota:
Cambiar el nivel de acceso de un blob en la cuenta de origen no cambiará el nivel de acceso de ese blob en la cuenta de destino.
Archivo de definición de directiva
Un archivo JSON define una directiva de replicación de objetos. Puede obtener el archivo de definición de directiva de una directiva de replicación de objetos ya existente. También puede crear una directiva de replicación de objetos cargando un archivo de definición de directiva.
Archivo de definición de directiva de ejemplo
En el ejemplo siguiente se define una directiva de replicación en la cuenta de destino con una única regla que coincide con el prefijo b y se establece el tiempo de creación mínimo para los blobs que se van a replicar. No olvide reemplazar los valores entre corchetes angulares por sus propios valores:
{
"properties": {
"policyId": "default",
"sourceAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"destinationAccount": "/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>",
"rules": [
{
"ruleId": "",
"sourceContainer": "<source-container>",
"destinationContainer": "<destination-container>",
"filters": {
"prefixMatch": [
"b"
],
"minCreationTime": "2021-08-028T00:00:00Z"
}
}
]
}
}
Especificar identificadores de recursos completos para las cuentas de origen y de destino
Al crear el archivo de definición de directiva, especifique los identificadores completos de los recursos de Azure Resource Manager para las entradas sourceAccount y destinationAccount, como se indica en el ejemplo de la sección anterior. Para más información sobre cómo buscar el identificador de recurso de una cuenta de almacenamiento, consulte Obtención del identificador de recurso de una cuenta de almacenamiento.
El identificador de recurso completo tiene el formato siguiente:
/subscriptions/<subscriptionId>/resourceGroups/<resource-group>/providers/Microsoft.Storage/storageAccounts/<storage-account>
Anteriormente, el archivo de definición de directiva solo requería el nombre de cuenta, en lugar del identificador de recurso completo de la cuenta de almacenamiento. Con la introducción de la propiedad de seguridad AllowCrossTenantReplication en la versión 2021-02-01 de la API REST del proveedor de recursos de Azure Storage, ahora debe proporcionar el identificador de recurso completo para todas las directivas de replicación de objetos que se crean cuando no se permite la replicación entre inquilinos para una cuenta de almacenamiento que participa en la directiva de replicación. Azure Storage usa el identificador de recurso completo para comprobar si las cuentas de origen y destino residen en el mismo inquilino. Para obtener más información sobre la desactivación de las directivas de replicación entre inquilinos, vea Impedir la replicación entre inquilinos de Microsoft Entra.
Aunque se admite proporcionar solo el nombre de cuenta cuando se permite la replicación entre inquilinos de una cuenta de almacenamiento, Microsoft recomienda proporcionar siempre el identificador de recurso completo como procedimiento recomendado. Todas las versiones anteriores de la API REST del proveedor de recursos de Azure Storage admiten el uso de la ruta de acceso del identificador de recurso completo en las directivas de replicación de objetos.
En la tabla siguiente se describe lo que sucede cuando se crea una directiva de replicación con el identificador de recurso completo especificado, en lugar de especificar el nombre de cuenta, en los escenarios en los que se permite o no la replicación entre inquilinos para la cuenta de almacenamiento.
| Identificador de la cuenta de almacenamiento en la definición de directiva | Se permite la replicación entre inquilinos | No se permite la replicación entre inquilinos |
|---|---|---|
| Identificador completo del recurso | Se pueden crear directivas del mismo inquilino. Se pueden crear directivas entre inquilinos. |
Se pueden crear directivas del mismo inquilino. No se pueden crear directivas entre inquilinos. |
| Solo el nombre de cuenta | Se pueden crear directivas del mismo inquilino. Se pueden crear directivas entre inquilinos. |
No se pueden crear directivas entre inquilinos ni en el mismo inquilino. Se produce un error porque Azure Storage no puede comprobar que las cuentas de origen y destino están en el mismo inquilino. El error indica que debe especificar el identificador de recurso completo para las entradas sourceAccount y destinationAccount en el archivo de definición de directiva. |
Especificación de los identificadores de directiva y regla
En la tabla siguiente se resumen los valores que se deben usar para las entradas policyId y ruleId en el archivo JSON en cada escenario.
| Cuando cree el archivo de definición de directiva para esta cuenta... | Establezca el id. de la directiva en este valor | Establezca los id. de regla en este valor |
|---|---|---|
| Cuenta de destino | Valor de cadena predeterminado. Azure Storage creará el id. de directiva automáticamente. | Una cadena vacía. Azure Storage creará los valores de id. de regla automáticamente. |
| Cuenta de origen | El valor del identificador de directiva devuelto al descargar el archivo de definición de directiva para la cuenta de destino. | Los valores de los identificadores de reglas devueltos al descargar el archivo de definición de directiva para la cuenta de destino. |
Impedir la replicación entre inquilinos de Microsoft Entra
Un inquilino de Microsoft Entra es una instancia dedicada de Microsoft Entra ID que representa una organización para la administración de identidades y acceso. Cada suscripción Azure tiene una relación de confianza con un único inquilino de Microsoft Entra. Todos los recursos de una suscripción, incluidas las cuentas de almacenamiento, están asociados al mismo inquilino de Microsoft Entra. Para obtener más información, vea ¿Qué es Microsoft Entra ID?
De forma predeterminada, la replicación entre inquilinos está deshabilitada para las cuentas creadas a partir del 15 de dic de 2023. Si las directivas de seguridad requieren que limite la replicación de objetos a cuentas de almacenamiento que residan solo en el mismo inquilino, puede no permitir la replicación entre inquilinos estableciendo una propiedad de seguridad denominada AllowCrossTenantReplication (versión preliminar). Cuando no permite la replicación de objetos entre inquilinos para una cuenta de almacenamiento, para cualquier directiva de replicación de objetos que esté configurada con esa cuenta de almacenamiento como cuenta de origen o destino, Azure Storage requiere que tanto la cuenta de origen como la de destino residan en el mismo inquilino de Microsoft Entra. Para obtener más información sobre cómo impedir la replicación de objetos entre inquilinos, vea Impedir la replicación de objetos entre inquilinos de Microsoft Entra.
Para no permitir la replicación de objetos entre inquilinos para una cuenta de almacenamiento, establezca la propiedad AllowCrossTenantReplication en false. Si la cuenta de almacenamiento no participa actualmente en ninguna directiva de replicación de objetos entre inquilinos, establecer la propiedad AllowCrossTenantReplication en false impide la configuración futura de directivas de replicación de objetos entre inquilinos con esta cuenta de almacenamiento como origen o destino.
Si la cuenta de almacenamiento participa actualmente en una o varias directivas de replicación de objetos entre inquilinos, no se permite establecer la propiedad AllowCrossTenantReplication en false. Debe eliminar las directivas entre inquilinos existentes para poder no permitir la replicación entre inquilinos.
De forma predeterminada, la propiedad AllowCrossTenantReplication se establece en false para una cuenta de almacenamiento creada a partir del 15 de diciembre de 2023. En el caso de las cuentas creadas antes del 15 de diciembre de 2023, cuando el valor de la propiedad AllowCrossTenantReplication de una cuenta de almacenamiento es null o true, los usuarios autorizados pueden configurar directivas de replicación de objetos entre inquilinos con esta cuenta como origen o destino. Para más información sobre cómo configurar directivas entre inquilinos, consulte Configuración de la replicación de objetos para blobs en bloques.
Puede usar Azure Policy para auditar un conjunto de cuentas de almacenamiento para asegurarse de que la propiedad AllowCrossTenantReplication esté establecida para evitar la replicación de objetos entre inquilinos. También puede usar Azure Policy para aplicar la gobernanza para un conjunto de cuentas de almacenamiento. Por ejemplo, puede crear una directiva con el efecto deny para impedir que un usuario cree una cuenta de almacenamiento donde la propiedad AllowCrossTenantReplication esté establecida en true, o modificar una cuenta de almacenamiento existente para cambiar el valor de la propiedad a true.
Estado de replicación
Puede comprobar el estado de replicación de un blob en la cuenta de origen. Para más información, consulte el apartado Comprobación del estado de replicación de un blob.
Nota
Aunque la replicación está en curso, no hay forma de determinar el porcentaje de datos que se han replicado.
Si el estado de replicación de un blob en la cuenta de origen indica un error, investigue las posibles causas que se mencionan a continuación:
- Asegúrese de que la directiva de replicación de objetos está configurada en la cuenta de destino.
- Compruebe que la cuenta de destino aún existe.
- Compruebe que el contenedor de destino aún existe.
- Compruebe que el contenedor de destino no está en proceso de eliminación, o que no se acaba de eliminar. La eliminación de un contenedor puede tardar hasta 30 segundos.
- Compruebe que el contenedor de destino sigue participando en la directiva de replicación de objetos.
- Si el blob de origen se cifró con una clave proporcionada por el cliente como parte de una operación de escritura, se producirá un error en la replicación de objetos. Para más información sobre las claves proporcionadas por el cliente, consulte Especificación de una clave de cifrado en una solicitud a Blob Storage.
- Compruebe si el blob de origen o de destino se ha movido al nivel de archivo. Los blobs archivados no se pueden replicar mediante la replicación de objetos. Para obtener más información sobre el nivel de archivo, vea Niveles de acceso para datos de blobs.
- Compruebe que el contenedor o blob de destino no esté protegido por una directiva de inmutabilidad. Tenga en cuenta que un contenedor o blob puede heredar una directiva de inmutabilidad de su elemento primario. Para más información sobre las directivas de inmutabilidad, consulte Introducción al almacenamiento inmutable para datos de blobs.
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.
Facturación
No hay ningún coste para configurar la replicación de objetos. Esto incluye la tarea de habilitar la fuente de cambios, habilitar el control de versiones y agregar directivas de replicación. Sin embargo, la replicación de objetos incurre en costos por las transacciones de lectura y escritura en las cuentas de origen y de destino, así como los cargos de salida por la replicación de datos de la cuenta de origen a la cuenta de destino y cargos de lectura para procesar la fuente de cambios.
Este es un desglose de los costos. Para encontrar el precio de cada componente de costo, consulte precios de Azure Blob Storage.
| Costo para actualizar un blob en la cuenta de origen | Costo de la replicación de datos en la cuenta de destino |
|---|---|
| Costo de transacción de una operación de escritura | Costo de transacción para leer un registro de fuente de cambios |
| Costo de almacenamiento del blob y de cada versión de blob1 | El costo de transacción para la lectura de blobs y las versiones de blobs2 |
| Costo para agregar un registro de fuente de cambios | El costo de transacción para la escritura de blobs y las versiones de blobs2 |
| Costo de almacenamiento del blob y de cada versión de blob1 | |
| Costo de salida de red3 |
1 En la cuenta de origen, si no ha cambiado el nivel de un blob o de una versión, se le facturarán los bloques únicos de datos en ese blob, sus versiones. Consulte Precios y facturación de versiones de blobs. En la cuenta de destino, para una versión, se facturan todos los bloques de una versión, independientemente de si son únicos o no.
2 Esto incluye solo las versiones de blobs creadas desde la última replicación completada.
3 La replicación de objetos copia toda la versión al destino (no solo los bloques únicos de la versión). Esta transferencia incurre en el costo de salida de red. Consulte Detalles de precios de ancho de banda.
Sugerencia
Para reducir el riesgo de una factura inesperada, habilite la replicación de objetos en una cuenta que contenga solo un pequeño número de objetos. A continuación, mida el impacto en el costo antes de habilitar la característica en una configuración de producción.