Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 la 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.
- Aumento de 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.
- Optimización de la distribución de datos. Puede procesar o analizar datos en una sola ubicación y, a continuación, replicar solo los resultados en regiones adicionales.
- Optimización de costes. Una vez replicados los datos, puede reducir los costos moviendolos al nivel de archivo mediante 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 las cuentas de origen y destino. Para información sobre cómo habilitar el control de versiones, consulte Habilitación y administración del control de versiones de blobs.
La habilitación de la fuente de cambios y el control de versiones de blobs 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 blobs en bloques; no se admiten blob en anexos ni 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.
La replicación de objetos aún no se admite en las cuentas que tienen habilitado un espacio de nombres jerárquico.
No se admite la replicación de objetos para blobs cargados mediante las API de Data Lake Storage .
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
Dado que los datos de blobs en bloques se replican de forma asincrónica, la cuenta de origen y la cuenta de destino no están sincronizadas inmediatamente.
OR ahora admite la replicación prioritaria, que prioriza la replicación de todas las operaciones en la política OR. Cuando se habilita la replicación de prioridad OR, se mejora el rendimiento de la replicación de todas las operaciones. Cuando la cuenta de origen y la de destino de una directiva de replicación están en el mismo continente, la replicación de prioridad OR también replica el 99,0% de los objetos en 15 minutos para las cargas de trabajo admitidas. El rendimiento de las características se garantiza con un acuerdo de nivel de servicio (SLA). Para obtener más información, visite los términos del Acuerdo de Nivel de Servicio y el artículo Prioridad de Replicación de Objetos.
También puede comprobar el estado de replicación en el blob de origen para determinar si la replicación está completa. 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 cualquier directiva de replicación de objetos en la cuenta antes de deshabilitar el control de versiones de blob.
Nota:
Solo se copian blobs en el destino. El identificador de versión de un blob no se copia. Después de colocar un blob en la ubicación de destino, se asigna un nuevo identificador de versión.
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 en 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 en el blob de destino.
Niveles de blob
La replicación de objetos se admite cuando las cuentas de origen y destino están en cualquier nivel en línea (caliente, templado o frío). Las cuentas de origen y destino pueden estar en distintos niveles. Sin embargo, se produce un error en la replicación de objetos si un blob de la cuenta de origen o de destino se mueve 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 una directiva de inmutabilidad está en vigor en la cuenta de destino, la replicación de objetos podría 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 el contenedor de destino tiene una política de inmutabilidad a nivel de contenedor, es posible que las modificaciones de los objetos en el contenedor de origen, como actualizaciones o eliminaciones, aún puedan tener éxito. Sin embargo, esos cambios podrían no replicarse en el contenedor de destino debido a la restricción de inmutabilidad. 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 la versión del blob de una cuenta de destino tiene una directiva de inmutabilidad de nivel de versión activa, podría lograrse una operación de eliminación o actualización en la versión del blob del contenedor de origen correspondiente. Sin embargo, se produce un error en la replicación de esa 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 varias reglas que especifican un contenedor de origen y destino e indican qué blobs de origen se replican.
Después de configurar la replicación de objetos, Azure Storage comprueba la fuente de cambios de la cuenta de origen periódicamente y replica de forma asincrónica las operaciones de escritura o eliminación en 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 servir como cuenta de destino para no más de dos directivas de replicación.
Las cuentas de origen y 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 distintos inquilinos de Microsoft Entra. Solo se puede crear una directiva de replicación para cada par de cuentas de origen o de destino.
Reglas de replicación
Las reglas de replicación especifican cómo Azure Storage replica blobs de un contenedor de origen en un contenedor de destino. Puede especificar hasta 1000 reglas de replicación para cada directiva de replicación. Cada regla de replicación define un único contenedor de origen y destino, y cada contenedor de origen y destino solo se puede usar en una sola regla. Como resultado, un máximo de 1000 contenedores de origen y 1000 contenedores de destino pueden participar en una sola directiva de replicación.
Después de crear una regla de replicación, se omiten los blobs preexistentes; solo los nuevos blobs en bloques agregados después de crear la regla se copian de forma predeterminada. Sin embargo, puede especificar que se copien tanto los blobs de bloques nuevos como los existentes. También puede definir un ámbito de copia personalizado que copie los blobs de bloques creados después de un tiempo especificado.
También puede especificar uno o varios filtros como parte de una regla de replicación para filtrar los blobs en bloques por prefijo. Al especificar un prefijo, solo los blobs que coinciden con ese prefijo en el contenedor de origen se copian 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 con una regla de replicación, primero debe deshabilitar la replicación. Para deshabilitar la regla, puede eliminarla para ese contenedor o quitar toda 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 cambia el nivel de acceso de ese blob en la cuenta de destino.
Archivo de definición de directiva
Un archivo JSON se usa para definir una directiva de replicación de objetos. Puede obtener el archivo de definición de directiva de una directiva de replicación de objetos existente o 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 establece una directiva de replicación en la cuenta de destino con una regla. La regla tiene como destino los blobs con el prefijo b y especifica un tiempo de creación mínimo para la replicación. 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 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 solo se admite el uso del nombre de cuenta para la replicación entre inquilinos, Microsoft recomienda usar 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 muestra cómo difiere el comportamiento de la directiva de replicación cuando se usa un identificador de recurso completo frente a un nombre de cuenta. La comparación depende de si se permite 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 crea automáticamente el valor del identificador de directiva para ti. | Una cadena vacía. Azure Storage crea automáticamente los valores de ID de regla para ti. |
| 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 nuevas cuentas creadas a partir del 15 de diciembre 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). Al deshabilitar la replicación de objetos entre inquilinos para una cuenta de almacenamiento, Azure Storage impone un requisito adicional. Para cualquier directiva de replicación de objetos que use esta cuenta de almacenamiento como origen o destino, ambas cuentas deben pertenecer al 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 de almacenamiento creadas antes del 15 de diciembre de 2023, cuando el valor de la propiedad AllowCrossTenantReplication para 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 deny efecto para evitar que un usuario cree una cuenta de almacenamiento en la que la propiedad AllowCrossTenantReplication esté establecida en true o modifique una cuenta de almacenamiento existente para cambiar el valor de la propiedad a true.
Métricas de replicación
La replicación de objetos admite dos métricas para proporcionarle información sobre el progreso de la replicación:
- Operaciones pendientes de replicación: número total de operaciones pendientes de replicación desde la cuenta de almacenamiento de origen hasta la de destino emitidas por intervalos de tiempo
- Bytes pendientes de replicación: suma de bytes pendientes de replicación emitida por intervalos de tiempo desde las cuentas de almacenamiento de origen a las de destino
Cada una de las métricas enumeradas anteriormente se puede ver con la dimensión de los cubos de tiempo. Este desglose permite obtener información detallada sobre cuántos bytes o operaciones están pendientes para la replicación por depósitos de tiempo como se indica a continuación:
- 0-5 minutos
- 5-10 minutos
- 10-15 minutos
- 15-30 minutos
- 30 minutos a 2 horas
- 2-8 horas
- 8-24 horas
-
>24 horas
En la imagen de ejemplo siguiente se muestra la operación pendiente y la métrica bytes de los siete días anteriores:
Puede habilitar las métricas de replicación en la cuenta de origen para supervisar bytes pendientes y operaciones pendientes. Para más información, consulte Configuración de métricas de replicación.
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 ninguna manera de determinar el porcentaje o los datos replicados.
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 se ha eliminado y que no está en proceso de eliminación. 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 cifra con una clave proporcionada por el cliente como parte de una operación de escritura, se produce 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 mueve al nivel de archivo. Los blobs archivados no se pueden replicar a través de 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 costo para configurar la replicación de objetos, incluida 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 conlleva costos en transacciones de lectura y escritura en las cuentas de origen y destino. Los cargos de salida por la replicación de datos de la cuenta de origen a la de destino también implican costos, al igual que los de lectura durante el procesamiento del flujo 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 |
| Costos de recuperación de datos en niveles de almacenamiento intermedio y frío | 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 unos pocos objetos. A continuación, mida el impacto en el costo antes de habilitar la característica en una configuración de producción.