| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Using Replication Feeds
Replication feeds enable the replication of objects from one or more domains or the entire cluster to another cluster. Replication provides extra protection and can be a crucial component of a high-availability design. Replication occurs as a background process that is considered "best effort" and subject to inter-cluster bandwidth. For those who require more deterministic replication, a remote synchronous write feature can be employed in gateways serving the source cluster of a replication feed.
Types of Replication
What type of replication method is chosen and how to configure it depends on whether a legacy Swarm implementation exists and on the needs for securing replication traffic over untrusted networks. (v10.0)
Secure Replication — : Swarm Storage supports remote replication over a WAN, so replication feeds can operate through the Content Gateway. When a replication feed is defined, specify which replication mode to use: either the legacy bidirectional GET method of replication (which may be needed for specific application compatibility or network requirements) or the recommended direct POST method, which offers better performance and flow management. With Swarm Storage 10.0 and later, TLS/SSL security can be implemented as it fits the implementation:
Upload a trusted certificate to Swarm
Replicate to an SSL offloader that services the target cluster
Replicate from a forward proxy on the source cluster.
See Replicating Replication Feeds over Untrusted Networksand Adding a Trusted Certificate to Swarm.
Replication Methods — Methods: Below are two replication methods available, along with the configuration variants of each that are supported. For best performance, choose direct POST replication, which can go through Gateway. GET replication is the legacy method, which may be needed for application compatibility or networking requirements.
...
| Drawio | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Note
Using the legacy Bidirectional GET for remote replication requires populating the Storage configuration setting cluster.proxyIpList for any cluster using a reverse proxy. The setting is a comma-separated list of reverse proxy IP addresses or names, including ports in name:port format. If using Direct POST replication, this setting can be populated or left blank, as it has no effect.
Adding a Replication Feed
To add a feed to the cluster, click the +Add button at the top right of the page and then select the Replication button.
...
The following table describes the data entry fields in the dialog box.
ID (existing Existing feeds) | Read-only; system-assigned identifier | ||
|---|---|---|---|
Status (existing Existing feeds) | Read-only; the current feed processing state. | ||
Name | The name attached to a feed. | ||
Scope | The feed filters that were selected for the replication feed. The object is replicated to the domain(s) indicated in this field.
The field value allows pattern matching with the Python regular expression (RE) syntax, so multiple domain names can be matched. The exception to the RE matching is that the "{m,n}" repetition qualifier may not be used. An example domain list value using RE is: 
| ||
Target Remote Cluster Name | The configuration setting for the target cluster (the configure the Gateway setting | ||
Proxy or Host(s) | The IP address(es) or host name(s) of either:
Enter each address with a comma or space between them to enter two or more node IP addresses. | ||
Port | Defaults to 80. Allows specifying a custom port for the remote cluster. | ||
Replication Mode | Defaults to Direct POST. Choose replication via direct POST (recommended) or bidirectional GET. Switching modes does not require a feed restart. (v9.6) For best performance, choose direct POST replication, which can go through Gateway. GET replication is the legacy method, which may be needed for application compatibility or networking requirements. | ||
Threads | Replication via direct POST. The default replication speed (20 simultaneous threads) is best for same-sized clusters with minimal replication backlog. When processing backlog, the new default push thread count is 20 per node (in releases prior to v15.0, it was 6 per volume) Reduce the threads to avoid overwhelming a smaller target cluster. For faster replication against a backlog, increase the threads temporarily and monitor bandwidth and cluster performance, as boosting the speed stresses both clusters. | ||
SSL Server | Replication via direct POST. Defaults to none. Enable Require trusted SSL if replicating over an untrusted network; Allow untrusted SSL is available but not intended for production systems. (v10.0) | ||
Remote Admin Name/Password | Inherit from source cluster: Uncheck the enabled box, if the remote cluster user name is different from the source cluster name in the same realm. Then enter: User/Password credentials
|
Propagate Deletes
| Info |
|---|
The legacy option Propagate Deletes is deprecated; it existed to allow setting a target cluster to preserve all deleted objects. This need is now covered by Object Versioning; historical versions of deleted objects can be accessed to recover mistakenly deleted content. Versioning to the target cluster serving as the archive can be limited, to minimize space usage. (v11.1) Note these restrictions and behaviors if an existing feed has this option specified:
|
| Excerpt | ||||||||
|---|---|---|---|---|---|---|---|---|
Using Feed ActionsClicking on an existing feed in the Feeds list opens the Feed Settings page, with the existing settings populated. The Actions (gear) icon menu at the top right supports multiple feed actions, appropriate to the type of feed: 
Troubleshooting Feeds
|
...