Compare cross-grid replication and CloudMirror replication
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? |
|
|
Who is responsible for setting it up? |
|
Typically, a tenant user. |
What is the destination? |
A corresponding and identical S3 bucket on the other StorageGRID system in the grid federation connection. |
|
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? |
|
The results will vary based on the versioning state of the source and destination buckets (which don't need to be the same):
Similarly, objects in the destination bucket can be deleted without affecting the source. |