¿Qué es la replicación entre grid?
La replicación entre grid es la replicación automática de objetos entre buckets S3 seleccionados en dos sistemas StorageGRID que están conectados en un "conexión de federación de grid". "Clon de cuenta" es necesario para la replicación entre grid.
Flujo de trabajo de replicación entre grid
El diagrama de flujo de trabajo resume los pasos para configurar la replicación entre redes entre depósitos en dos redes.
Requisitos de la replicación entre grid
Si una cuenta de inquilino tiene el permiso Usar conexión de federación de red para usar una o más"conexiones de federación de grid" Un usuario inquilino con permiso de acceso raíz puede crear depósitos en las cuentas de inquilino correspondientes en cada red. Estos cubos:
-
Pueden tener nombres diferentes entre sí
-
Puede tener diferentes regiones
-
Debe tener el control de versiones activado
-
Debe estar vacío
Una vez creados ambos bloques, la replicación entre grid se puede configurar para uno o ambos bloques.
Funcionamiento de la replicación entre grid
Puede configurar la replicación entre redes para que se produzca en una dirección o en ambas direcciones.
Replicación en una dirección
Si habilita la replicación entre cuadrículas para un depósito en una sola cuadrícula, los objetos agregados a ese depósito (el depósito de origen) se replican en el depósito correspondiente en la otra cuadrícula (el depósito de destino). Sin embargo, los objetos agregados al depósito de destino no se replican en el origen. En la figura, la replicación entre redes está habilitada para my-bucket de la cuadrícula 1 a la cuadrícula 2, pero no está habilitado en la otra dirección.
Replicación en ambas direcciones
Si habilita la replicación entre grid para el mismo bucket en ambos grids, los objetos agregados a cada bucket se replican en el otro grid. En la figura, la replicación entre grid está activada en my-bucket ambas direcciones.
¿Qué sucede cuando se ingieren objetos?
Cuando un cliente S3 agrega un objeto a un bloque que tiene habilitada la replicación entre grid, sucede lo siguiente:
-
StorageGRID replica automáticamente el objeto del bloque de origen al de destino. El tiempo para realizar esta operación de replicación en segundo plano depende de varios factores, incluidos la cantidad de otras operaciones de replicación pendientes.
El cliente S3 puede verificar el estado de replicación de un objeto emitiendo una solicitud GetObject o HeadObject. La respuesta incluye un StorageGRID específico
x-ntap-sg-cgr-replication-statusencabezado de respuesta, que tiene uno de los siguientes valores:Cuadrícula Estado de replicación Origen
-
COMPLETADO: La replicación fue exitosa para todas las conexiones de red.
-
PENDIENTE: El objeto no ha sido replicado en al menos una conexión de red.
-
FALLO: La replicación no está pendiente para ninguna conexión a la red y al menos una falló con una falla permanente. Un usuario debe resolver el error.
Destino
REPLICA: El objeto fue replicado desde la cuadrícula de origen.
StorageGRID no es compatible con x-amz-replication-statusencabezamiento. -
-
StorageGRID utiliza las políticas de ILM activas de cada grid para gestionar los objetos, al igual que lo haría con cualquier otro objeto. Por ejemplo, el objeto A en Grid 1 se puede almacenar como dos copias replicadas y conservarse permanentemente, mientras que la copia del objeto A replicado en Grid 2 se puede almacenar con el código de borrado 2+1 y eliminarse después de tres años.
¿Qué sucede cuando se eliminan los objetos?
Como se describe en "Eliminar flujo de datos", StorageGRID puede suprimir un objeto por cualquiera de los siguientes motivos:
-
El cliente S3 emite una solicitud de eliminación.
-
Un usuario del gestor de inquilinos selecciona "Suprimir objetos del depósito"la opción para eliminar todos los objetos de un depósito.
-
El bloque tiene una configuración del ciclo de vida que caduca.
-
El último periodo de tiempo de la regla de ILM para el objeto finaliza, y no se han especificado más ubicaciones.
Cuando StorageGRID elimina un objeto debido a una operación Eliminar objetos en el bloque, la caducidad del ciclo de vida del bloque o la caducidad de la ubicación de ILM, el objeto replicado nunca se elimina del otro grid en una conexión de la federación de grid. Sin embargo, los marcadores de borrado que se han añadido al bloque de origen mediante eliminaciones de clientes de S3 se pueden replicar opcionalmente en el bloque de destino.
Para comprender qué sucede cuando un cliente S3 elimina objetos de un bloque que tiene habilitada la replicación entre grid, revise cómo los clientes S3 eliminan objetos de los bloques que tienen el control de versiones activado, de la siguiente manera:
-
Si un cliente S3 emite una solicitud de eliminación que incluye un ID de versión, esa versión del objeto se elimina de forma permanente. No se ha añadido ningún marcador de borrado al depósito.
-
Si un cliente S3 emite una solicitud de eliminación que no incluye un ID de versión, StorageGRID no elimina ninguna versión de objeto. En lugar de ello, agrega un marcador de eliminación al depósito. El marcador de eliminación hace que StorageGRID actúe como si el objeto hubiera sido eliminado:
-
Una solicitud GetObject sin un ID de versión falla con
404 No Object Found -
Una solicitud GetObject con un ID de versión válido tiene éxito y devuelve la versión del objeto solicitada.
-
Cuando un cliente S3 elimina un objeto de un bloque que tiene habilitada la replicación entre grid, StorageGRID determina si desea replicar la solicitud de eliminación en el destino, de la siguiente manera:
-
Si la solicitud de eliminación incluye un ID de versión, esa versión del objeto se elimina de forma permanente de la cuadrícula de origen. Sin embargo, StorageGRID no replica las solicitudes de eliminación que incluyen un ID de versión, por lo que la misma versión del objeto no se elimina del destino.
-
Si la solicitud de eliminación no incluye un ID de versión, StorageGRID puede replicar opcionalmente el marcador de eliminación, según cómo esté configurada la replicación entre redes para el depósito:
-
Si decide replicar marcadores de eliminación (valor predeterminado), se agrega un marcador de eliminación al bloque de origen y se replica en el bloque de destino. De hecho, el objeto parece eliminarse en ambas cuadrículas.
-
Si elige no replicar los marcadores de eliminación, se agrega un marcador de eliminación al depósito de origen, pero no se replica en el depósito de destino. En efecto, los objetos que se eliminan en la cuadrícula de origen no se eliminan en la cuadrícula de destino.
-
En la figura, Replicar marcadores de eliminación se configuró en Sí cuando"se ha activado la replicación entre grid" . Las solicitudes de eliminación del depósito de origen que incluyen un ID de versión no eliminan objetos del depósito de destino. Las solicitudes de eliminación del depósito de origen que no incluyen un ID de versión parecen eliminar objetos en el depósito de destino.
|
|
Si desea mantener las eliminaciones de objetos sincronizadas entre las cuadrículas, cree las correspondientes "Configuraciones de ciclo de vida de S3" para los depósitos en ambas cuadrículas. |
Cómo se replican los objetos cifrados
Cuando se utiliza la replicación entre grid para replicar objetos entre grids, se pueden cifrar objetos individuales, utilizar el cifrado de bucket predeterminado o configurar el cifrado de toda la grid. Puede agregar, modificar o eliminar la configuración de cifrado predeterminada de bloque o de grid antes o después de habilitar la replicación entre grid para un bloque.
Para cifrar objetos individuales, puede utilizar SSE (cifrado del lado del servidor con claves gestionadas por StorageGRID) al agregar los objetos al depósito de origen. Utilice x-amz-server-side-encryption la cabecera de solicitud y especifique AES256. Consulte "Usar cifrado del servidor".
|
|
El uso de SSE-C (cifrado del lado del servidor con claves proporcionadas por el cliente) no es compatible con la replicación entre redes. La operación de ingesta fallará. |
Para utilizar el cifrado predeterminado para un depósito, utilice una solicitud PutBucketEncryption y defina el SSEAlgorithm parámetro en AES256. El cifrado de nivel de bloque se aplica a cualquier objeto ingerido sin x-amz-server-side-encryption la cabecera de solicitud. Consulte "Operaciones en bloques".
Para utilizar el cifrado a nivel de cuadrícula, establezca la opción cifrado de objetos almacenados en AES-256. El cifrado a nivel de grid se aplica a cualquier objeto que no esté cifrado en el nivel de bucket o que se ingiera sin la x-amz-server-side-encryption cabecera de solicitud. Consulte "Configure las opciones de red y objeto".
|
|
SSE no admite AES-128. Si la opción Cifrado de objetos almacenados está habilitada para la cuadrícula de origen que utiliza la opción AES-128, el uso del algoritmo AES-128 no se propaga al objeto replicado. En su lugar, el objeto replicado utiliza el depósito predeterminado del destino o la configuración de cifrado a nivel de cuadrícula, si está disponible. |
Al determinar cómo cifrar los objetos de origen, StorageGRID aplica estas reglas:
-
Utilice
x-amz-server-side-encryptionel encabezado de ingesta, si existe. -
Si no hay un encabezado de ingesta presente, utilice la configuración de cifrado predeterminada del depósito, si está configurada.
-
Si no se configura una configuración de depósito, utilice la configuración de cifrado de toda la red, si está configurada.
-
Si no hay una configuración para toda la cuadrícula, no cifre el objeto de origen.
Al determinar cómo cifrar los objetos replicados, StorageGRID aplica estas reglas en este orden:
-
Use el mismo cifrado que el objeto de origen, a menos que ese objeto utilice cifrado AES-128.
-
Si el objeto de origen no está cifrado o utiliza AES-128, utilice la configuración de cifrado predeterminada del depósito de destino, si está configurada.
-
Si el depósito de destino no tiene una configuración de cifrado, utilice la configuración de cifrado de toda la red del destino, si está configurada.
-
Si no hay una configuración para toda la cuadrícula, no cifre el objeto de destino.
Replicación entre cuadrículas con S3 Object Lock
Puede configurar la replicación entre redes entre depósitos StorageGRID con S3 Object Lock habilitado en las siguientes circunstancias.
| Cuando el bloqueo de objetos S3 en el depósito de origen es… | Y el bloqueo de objetos S3 en el depósito de destino es… |
|---|---|
Habilitado |
Habilitado |
Desactivado |
Habilitado |
Cuando el bloqueo de objetos S3 en el depósito de origen está habilitado:
-
Los objetos se bloquean con configuraciones de retención en el destino en este orden:
-
Valores del encabezado de retención del objeto de origen para:
x-amz-object-lock-modex-amz-object-lock-retain-until-date -
La retención predeterminada del depósito de origen, si está configurada.
-
La retención predeterminada del depósito de destino, si está configurada.
La retención predeterminada del depósito de destino no anula la configuración de retención replicada desde el objeto de origen.
-
-
Puede establecer el estado de retención legal para el objeto de destino mediante
x-amz-object-lock-legal-holdal cargar el objeto. -
Se produce un error si el inquilino o el depósito de destino no admiten la configuración de bloqueo de objetos S3 del objeto de origen. Consulte "Alertas y errores de replicación entre redes."
Cuando el bloqueo de objetos S3 en el depósito de origen está deshabilitado:
-
Puede configurar la retención predeterminada en el depósito de destino para aplicar la configuración de retención de Bloqueo de objetos S3 al objeto de destino.
-
El objeto de destino no puede establecer un estado de retención legal.
PutObjectTagging y DeleteObjectTagging no son compatibles
Las solicitudes PutObjectTagging y DeleteObjectTagging no están soportadas para los objetos de los depósitos que tienen activada la replicación entre grid.
Si un cliente S3 emite una solicitud PutObjectTagging o DeleteObjectTagging, 501 Not Implemented se devuelve. El mensaje es Put(Delete) ObjectTagging isn't available for buckets that have cross-grid replication configured .
PutObjectRetention y PutObjectLegalHold no son compatibles
Las solicitudes PutObjectRetention y PutObjectLegalHold no son totalmente compatibles con los objetos en depósitos que tienen habilitada la replicación entre cuadrículas.
Si un cliente S3 emite una solicitud PutObjectRetention o PutObjectLegalHold, se modifican las configuraciones del objeto de origen, pero los cambios no se aplican al destino.
Cómo se replican los objetos segmentados
El tamaño máximo de segmento de la cuadrícula de origen se aplica a los objetos replicados en la cuadrícula de destino. Cuando los objetos se replican en otra cuadrícula, la configuración Tamaño máximo de segmento (Configuración > Sistema > Opciones de almacenamiento) de la cuadrícula de origen se utiliza en ambas cuadrículas. Por ejemplo, supongamos que el tamaño máximo de segmento para la cuadrícula de origen es 1 GB, mientras que el tamaño máximo de segmento de la cuadrícula de destino es 50 MB. Si ingiere un objeto de 2 GB en la cuadrícula de origen, ese objeto se guarda como dos segmentos de 1 GB. También se replica en la red de destino como dos segmentos de 1 GB, aunque el tamaño máximo de segmento de esa red es de 50 MB.