Replication of domains between Swarm clusters provides for disaster recovery and locality of access to content. Many replication strategies are supported by Swarm including single-direction roll-up, multi-master, and cascading topographies. This section focuses on the content replicated to host storage domains in multiple clusters.

A different domain sharing the same name is created if a domain with the same name is created using an SCSP operation or with the initgateway command in multiple Swarm clusters. This leads to incorrect results if the different domains are ever replicated into the same cluster due to the name collision. Create a domain name one time and use a Replication Feed to copy it to other clusters.

Verify the administrative domain is available in the other cluster if intending to use a storage domain within a cluster other than the one in which it was initially created. To use a storage domain means client requests (read, write, delete) are performed in the cluster. Replication of the administrative domain is unnecessary if the storage domain is replicated to another cluster purely for Disaster Recovery (DR) and client requests are ever sent to it. The initgateway command must be used in one cluster and then use Replication Feeds to duplicate the administrative domain into all other clusters.

Required Permission

Swarm needs to perform a "GET /" request during replication to check the Swarm cluster name and version when replicating through Gateway.

Add a policy.json rule providing "anonymous" permission to "GET /" (GetObject) to enable Swarm to perform this check:

See https://perifery.atlassian.net/wiki/spaces/public/pages/2443816981.

Example Replication

The following diagram shows three Swarm storage clusters, storage domains A1 and A2, and an administrative domain A. Domains A, A1, and A2 are all initially created in Cluster Alpha. Remote replication is then configured to mirror domains A and A1 to Cluster Bravo. Additionally, domains A and A2 are configured to mirror to Cluster Charlie.

Open

Each cluster can support a Content Gateway configured to use domain A as the administrative domain by configuring the domains to mirror, bi-directional replication. With Gateways deployed in all three clusters and all using administrative domain A, clients may access storage domain A1 from Cluster Alpha and Cluster Bravo. Clients may access storage domain A2 from Cluster Alpha and Cluster Charlie.

Content is available for reading from all clusters to which it is mirrored and content changes (create, update, or delete) propagate to the other clusters by mirroring the storage domains. Notice the administrative domain for a storage domain must be mirrored to any cluster where the clients access the storage domain. This is required so the IDSYS, Policy, XFORM, authentication tokens, and other tracking information used to manage the storage domain are available to the Gateways running in the other clusters. Although replication of the administrative domain is not required if clients do not access a storage domain from another cluster, it is recommended to simplify DR if it becomes necessary to restore.

It is also possible to replicate storage domains with different administrative domains into the same Swarm storage cluster while providing client access to all storage domains.

Open

Client access is enabled by deploying a Content Gateway server for each set of storage domains when a Swarm storage cluster hosts multiple sets of storage domains and the corresponding administrative domains. Although a Gateway uses one administrative domain, it can access any storage domain associated with the administrative domain as long as the storage domain exists in the local Swarm storage cluster. The previous diagram shows storage domains A1, A2, and A3 accessed through Gateway A in both Cluster Alpha and Cluster Central. The deployment of Gateway A in both clusters makes use of the mirrored administrative domain A to manage the mirrored storage domains.

The client use cases and application architecture must account for replication latency when remote replication is being used as described. Following the creation, update, or deletion of content in one domain, there is a time delay before the change is observed within another cluster. This latency depends on the inter-cluster bandwidth and the total replication workload between the Swarm clusters.