Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Compare la replicación entre grid y la replicación de CloudMirror

05/18/2023 Colaboradores

PDF

A medida que comience a utilizar la federación de cuadrícula, revise las similitudes y diferencias entre "replicación entre grid" y la "Servicio de replicación CloudMirror de StorageGRID".

	Replicación entre grid	Servicio de replicación de CloudMirror
¿Cuál es el objetivo principal?	Un sistema StorageGRID actúa como sistema de recuperación ante desastres. Los objetos de un depósito se pueden replicar entre las cuadrículas en una o en ambas direcciones.	Permite que un inquilino replique automáticamente objetos de un bloque en StorageGRID (origen) a un bloque S3 externo (destino). La replicación de CloudMirror crea una copia independiente de un objeto en una infraestructura de S3 independiente. Esta copia independiente no se usa como backup, pero suele procesarse en el cloud.
¿Cómo se configura?	Configure una conexión de federación de grid entre dos cuadrículas. Agregar nuevas cuentas de inquilino, que se clonan automáticamente en el otro grid. Añadir usuarios y grupos de inquilinos nuevos que también se clonan. Crea los bloques correspondientes en cada grid y permite que la replicación entre grid se realice en una o en ambas direcciones.	Un usuario de inquilino configura la replicación de CloudMirror definiendo un extremo de CloudMirror (dirección IP, credenciales, etc.) mediante el administrador de inquilinos o la API de S3. Se puede configurar cualquier bloque que pertenezca a esa cuenta de inquilino para que apunte al extremo de CloudMirror.
¿Quién es responsable de su configuración?	Un administrador de grid configura la conexión y los inquilinos. Los usuarios inquilinos configuran los grupos, los usuarios, las claves y los buckets.	Normalmente, un usuario inquilino.
¿Cuál es el destino?	Un bloque de S3 correspondiente e idéntico en el otro sistema StorageGRID de la conexión de federación de grid.	Cualquier infraestructura S3 compatible (incluido Amazon S3). Google Cloud Platform (GCP)
¿Se requiere el control de versiones de objetos?	Sí, tanto los depósitos de origen como de destino deben tener activado el control de versiones de objetos.	No, la replicación de CloudMirror admite cualquier combinación de buckets sin versiones y con versiones tanto en el origen como en el destino.
¿Qué hace que los objetos se muevan al destino?	Los objetos se replican automáticamente cuando se añaden a un bloque que tiene habilitada la replicación entre grid.	Los objetos se replican automáticamente cuando se añaden a un bloque que se ha configurado con un extremo de CloudMirror. Los objetos que existían en el bloque de origen antes de que se configurara con el extremo de CloudMirror no se replican, a menos que se modifiquen.
¿Cómo se replican los objetos?	La replicación entre grid crea objetos con versiones y replica el identificador de versión del bloque de origen al bloque de destino. Esto permite mantener el orden de versión en ambas cuadrículas.	La replicación de CloudMirror no requiere buckets habilitados para el control de versiones, por lo que CloudMirror solo puede mantener el pedido de una clave dentro de un sitio. No hay garantías de que el pedido se mantendrá para las solicitudes a un objeto en un sitio diferente.
¿Qué pasa si un objeto no se puede replicar?	El objeto se pone en cola para la replicación, sujeto a los límites de almacenamiento de metadatos.	El objeto se pone en cola para la replicación, sujeto a los límites de servicios de la plataforma (consulte "Recomendaciones para el uso de servicios de plataformas").
¿Se replican los metadatos del sistema del objeto?	Sí, cuando un objeto se replica en la otra cuadrícula, sus metadatos del sistema también se replican. Los metadatos serán idénticos en ambas cuadrículas.	No, cuando un objeto se replica en el depósito externo, sus metadatos del sistema se actualizan. Los metadatos variarán entre ubicaciones, en función del tiempo de procesamiento y del comportamiento de la infraestructura S3 independiente.
¿Cómo se recuperan los objetos?	Las aplicaciones pueden recuperar o leer objetos mediante la realización de una solicitud al depósito en cualquier cuadrícula.	Las aplicaciones pueden recuperar o leer objetos realizando una solicitud en StorageGRID o en el destino de S3. Por ejemplo, supongamos que usa la replicación de CloudMirror para reflejar objetos en una organización asociada. El partner puede utilizar sus propias aplicaciones para leer o actualizar objetos directamente desde el destino S3. No es necesario usar StorageGRID.
¿Qué sucede si se elimina un objeto?	Las solicitudes de supresión que incluyan un ID de versión nunca se replican en la cuadrícula de destino. Las solicitudes de eliminación que no incluyen un ID de versión agregan un marcador de eliminación al depósito de origen, que opcionalmente se puede replicar en la cuadrícula de destino. Si la replicación entre grid se configura para una sola dirección, los objetos del bucket de destino se pueden eliminar sin afectar al origen.	Los resultados variarán en función del estado de control de versiones de los depósitos de origen y destino (que no necesitan ser los mismos): Si ambos cubos están versionados, una solicitud de eliminación agregará un marcador de eliminación en ambas ubicaciones. Si sólo se ha versionado el depósito de origen, una solicitud de supresión agregará un marcador de supresión al origen pero no al destino. Si ninguno de los depósitos está versionado, una solicitud de supresión suprimirá el objeto del origen pero no del destino. Del mismo modo, los objetos del bloque de destino se pueden eliminar sin que ello afecte al origen.

Replicación entre grid

Servicio de replicación de CloudMirror

¿Cuál es el objetivo principal?

Un sistema StorageGRID actúa como sistema de recuperación ante desastres. Los objetos de un depósito se pueden replicar entre las cuadrículas en una o en ambas direcciones.

Permite que un inquilino replique automáticamente objetos de un bloque en StorageGRID (origen) a un bloque S3 externo (destino).

La replicación de CloudMirror crea una copia independiente de un objeto en una infraestructura de S3 independiente. Esta copia independiente no se usa como backup, pero suele procesarse en el cloud.

¿Cómo se configura?

Configure una conexión de federación de grid entre dos cuadrículas.
Agregar nuevas cuentas de inquilino, que se clonan automáticamente en el otro grid.
Añadir usuarios y grupos de inquilinos nuevos que también se clonan.
Crea los bloques correspondientes en cada grid y permite que la replicación entre grid se realice en una o en ambas direcciones.

Un usuario de inquilino configura la replicación de CloudMirror definiendo un extremo de CloudMirror (dirección IP, credenciales, etc.) mediante el administrador de inquilinos o la API de S3.
Se puede configurar cualquier bloque que pertenezca a esa cuenta de inquilino para que apunte al extremo de CloudMirror.

¿Quién es responsable de su configuración?

Un administrador de grid configura la conexión y los inquilinos.
Los usuarios inquilinos configuran los grupos, los usuarios, las claves y los buckets.

Normalmente, un usuario inquilino.

¿Cuál es el destino?

Un bloque de S3 correspondiente e idéntico en el otro sistema StorageGRID de la conexión de federación de grid.

Cualquier infraestructura S3 compatible (incluido Amazon S3).
Google Cloud Platform (GCP)

¿Se requiere el control de versiones de objetos?

Sí, tanto los depósitos de origen como de destino deben tener activado el control de versiones de objetos.

No, la replicación de CloudMirror admite cualquier combinación de buckets sin versiones y con versiones tanto en el origen como en el destino.

¿Qué hace que los objetos se muevan al destino?

Los objetos se replican automáticamente cuando se añaden a un bloque que tiene habilitada la replicación entre grid.

Los objetos se replican automáticamente cuando se añaden a un bloque que se ha configurado con un extremo de CloudMirror. Los objetos que existían en el bloque de origen antes de que se configurara con el extremo de CloudMirror no se replican, a menos que se modifiquen.

¿Cómo se replican los objetos?

La replicación entre grid crea objetos con versiones y replica el identificador de versión del bloque de origen al bloque de destino. Esto permite mantener el orden de versión en ambas cuadrículas.

La replicación de CloudMirror no requiere buckets habilitados para el control de versiones, por lo que CloudMirror solo puede mantener el pedido de una clave dentro de un sitio. No hay garantías de que el pedido se mantendrá para las solicitudes a un objeto en un sitio diferente.

¿Qué pasa si un objeto no se puede replicar?

El objeto se pone en cola para la replicación, sujeto a los límites de almacenamiento de metadatos.

El objeto se pone en cola para la replicación, sujeto a los límites de servicios de la plataforma (consulte "Recomendaciones para el uso de servicios de plataformas").

¿Se replican los metadatos del sistema del objeto?

Sí, cuando un objeto se replica en la otra cuadrícula, sus metadatos del sistema también se replican. Los metadatos serán idénticos en ambas cuadrículas.

No, cuando un objeto se replica en el depósito externo, sus metadatos del sistema se actualizan. Los metadatos variarán entre ubicaciones, en función del tiempo de procesamiento y del comportamiento de la infraestructura S3 independiente.

¿Cómo se recuperan los objetos?

Las aplicaciones pueden recuperar o leer objetos mediante la realización de una solicitud al depósito en cualquier cuadrícula.

Las aplicaciones pueden recuperar o leer objetos realizando una solicitud en StorageGRID o en el destino de S3. Por ejemplo, supongamos que usa la replicación de CloudMirror para reflejar objetos en una organización asociada. El partner puede utilizar sus propias aplicaciones para leer o actualizar objetos directamente desde el destino S3. No es necesario usar StorageGRID.

¿Qué sucede si se elimina un objeto?

Las solicitudes de supresión que incluyan un ID de versión nunca se replican en la cuadrícula de destino.
Las solicitudes de eliminación que no incluyen un ID de versión agregan un marcador de eliminación al depósito de origen, que opcionalmente se puede replicar en la cuadrícula de destino.
Si la replicación entre grid se configura para una sola dirección, los objetos del bucket de destino se pueden eliminar sin afectar al origen.

Los resultados variarán en función del estado de control de versiones de los depósitos de origen y destino (que no necesitan ser los mismos):

Si ambos cubos están versionados, una solicitud de eliminación agregará un marcador de eliminación en ambas ubicaciones.
Si sólo se ha versionado el depósito de origen, una solicitud de supresión agregará un marcador de supresión al origen pero no al destino.
Si ninguno de los depósitos está versionado, una solicitud de supresión suprimirá el objeto del origen pero no del destino.

Del mismo modo, los objetos del bloque de destino se pueden eliminar sin que ello afecte al origen.

Compare la replicación entre grid y la replicación de CloudMirror

Creating your file...