Skip to main content
A newer release of this product is available.

Compare cross-grid replication and CloudMirror replication

Contributors netapp-madkat ssantho3
PDFs

As you begin using grid federation, review the similarities and differences between cross-grid replication and the StorageGRID CloudMirror replication service.

Cross-grid replication CloudMirror replication service

What is the primary purpose?

One StorageGRID system acts as a disaster recovery system. Objects in a bucket can be replicated between the grids in one or both directions.

Enables a tenant to automatically replicate objects from a bucket in StorageGRID (source) to an external S3 bucket (destination).

CloudMirror replication creates an independent copy of an object in an independent S3 infrastructure. This independent copy is not used as a backup, but often further processed in the cloud.

How is it set up?

  1. Configure a grid federation connection between two grids.

  2. Add new tenant accounts, which are automatically cloned to the other grid.

  3. Add new tenant groups and users, which are also cloned.

  4. Create corresponding buckets on each grid and enable cross-grid replication to occur in one or both directions.

  1. A tenant user configures CloudMirror replication by defining a CloudMirror endpoint (IP address, credentials, and so on) using the Tenant Manager or the S3 API.

  2. Any bucket owned by that tenant account can be configured to point to the CloudMirror endpoint.

Who is responsible for setting it up?

  • A grid admin configures the connection and the tenants.

  • Tenant users configure the groups, users, keys, and buckets.

Typically, a tenant user.

What is the destination?

A corresponding and identical S3 bucket on the other StorageGRID system in the grid federation connection.

  • Any compatible S3 infrastructure (including Amazon S3).

  • Google Cloud Platform (GCP)

Is object versioning required?

Yes, both the source and destination buckets must have object versioning enabled.

No, CloudMirror replication supports any combination of unversioned and versioned buckets on both the source and destination.

What causes objects to be moved to the destination?

Objects are automatically replicated when they are added to a bucket that has cross-grid replication enabled.

Objects are automatically replicated when they are added to a bucket that has been configured with a CloudMirror endpoint. Objects that existed in the source bucket before the bucket was configured with the CloudMirror endpoint aren't replicated, unless they are modified.

How are objects replicated?

Cross-grid replication creates versioned objects, and it replicates the version ID from the source bucket to the destination bucket. This allows the version order to be maintained across both grids.

CloudMirror replication doesn't require versioning-enabled buckets, so CloudMirror can only maintain ordering for a key within a site. There are no guarantees that ordering will be maintained for requests to an object at different site.

What if an object can't be replicated?

The object is queued for replication, subject to metadata storage limits.

The object is queued for replication, subject to platform services limits (see Recommendations for using platform services).

Is the object's system metadata replicated?

Yes, when an object is replicated to the other grid, its system metadata is also replicated. The metadata will be identical on both grids.

No, when an object is replicated to the external bucket, its system metadata is updated. The metadata will differ between locations, depending on time of ingest and the behavior of the independent S3 infrastructure.

How are objects retrieved?

Applications can retrieve or read objects by making a request to the bucket on either grid.

Applications can retrieve or read objects by making a request either to StorageGRID or to the S3 destination. For example, suppose you use CloudMirror replication to mirror objects to a partner organization. The partner can use its own applications to read or update objects directly from the S3 destination. Using StorageGRID is not required.

What happens if an object is deleted?

  • Delete requests that include a version ID are never replicated to the destination grid.

  • Delete requests that don't include a version ID add a delete marker to the source bucket, which can optionally be replicated to the destination grid.

  • If cross-grid replication is configured for only one direction, objects in the destination bucket can be deleted without affecting the source.

The results will vary based on the versioning state of the source and destination buckets (which don't need to be the same):

  • If both buckets are versioned, a delete request will add a delete marker in both locations.

  • If only the source bucket is versioned, a delete request will add a delete marker to the source but not to the destination.

  • If neither bucket is versioned, a delete request will delete the object from the source but not from the destination.

Similarly, objects in the destination bucket can be deleted without affecting the source.