Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

What is Synchronous Write to Remote Sites?

Swarm's replication feeds Replication Feeds are mature and resilient, with each feed syncing content iteratively and asynchronously, linking one source cluster to one target destination. Replication feeds keep target clusters continuously updated with object changes in the source cluster, and having multiple replication feeds allows the distribution of content across a set of remote Swarm clusters. Remote synchronous write is limited by inter-cluster bandwidth and the constraints of overall request timeouts. Hence, it should not be thought of as a synchronization guarantee. Remote synchronous write are built on the Swarm asynchronous feed, which acts as a safety net to ensure the eventual replication of new writes that may not have been synchronously replicated.

...

  • An application requires assurance that backups (replicas) are committed to every site.

  • The content publication needs newly added content to be readable from any remote site immediately upon the write completion.

Remote Site Synchronous Write Write or Remote Synchronous Write (RSW) — is is the option to have a client create or update a Swarm object and have that change committed in all active remote clusters immediately before the client receives a success code. An object written this way has the same UUID and metadata across all Swarm clusters as if it were replicated normally.

Info

RSW

  • Synchronous Write to Remote Sites is the same as Remote Synchronous Write (RSW). All commands and log messages use the acronym RSW.
    This is separate from Replicate on Write (ROW), which guarantees immediate replication within the same cluster.

  • RSW is implemented in Gateway using the SCSP SEND method. RSW requires writing to Gateway, and Gateway uses the SCSP SEND method for the Swarm nodes. This allows replicating objects normally.

...

  1. Complete the upgrade to Swarm 12 or higher, including the latest versions of Content Gateway, Content UI, and Swarm Storage. Current versions are required for this feature, but no additional components need to be installed.

  2. Complete provisioning and initialization for the additional remote Swarm clusters participating in remote synchronous writing.

    • Content protection policies do not need to match across all clusters. Versioning may not be enabled (which enlarges the footprint) on any but the primary cluster.

  3. Create separate replication feeds for each of the remote Swarm clusters in the primary (source) cluster.
    See Replication Feeds for more details.

    1. Navigate to Cluster > Feeds, select + Add, and select Replication in the Swarm UI.

    2. Leave the legacy setting Propagate Deletes enabled.

    3. Choose Replicate via direct POST rather than the legacy GET mode for the remote cluster's Replication Mode.

Note

...

Replication-type feeds with a Status of Active participate in RSW if enabled

...

.

...

  1. Set up replication feeds in the remote clusters if the remote clusters are accepting content to be mirrored back to the primary cluster.

  2. Verify that the feeds are running successfully in each of the target clusters, populating objects from the source cluster.

Enabling Remote Synchronous Writes

Click the Settings (gear icon) and set the Properties to be in force for that domain or bucket in the Content UI. The policy change takes effect on Save.

Constraints : As with the Storage Policies (replicas, encoding, versioning) for domains and buckets, this setting is constrained by the cluster's configuration. The constraints are whether the cluster has any replication feeds that are configured and whether they are in Active status for Remote Sites; no synchronous writes occur if there are not any remote clusters being replicated to.

Image Modified

Domains

The option must be enabled at this level if synchronous writes to remote sites to include unnamed objects (which do not reside in buckets) is desired.

Best

The best practice is to enable the option at the level of those buckets if synchronous writes for certain buckets

is

are desired.

  • Synchronous Write Enabled

 —
  • : Toggle to explicitly enable or discontinue the feature.

    • For a domain, enabling it means that each of its buckets also default to having it enabled, unless inheritance is overridden.

Image Modified

Buckets

Disable Inherit Policy and explicitly enable it for each affected bucket unless enabling synchronous write at the domain level:

  • Inherit Policy

 —
  • : (default) Select to accept the domain's policy, which is disabled by default until the domain explicitly enables it.

    • With inheritance off, the bucket does not respond to domain-level changes. 

  • Synchronous Write - Enabled

 —
  • : Toggle to explicitly enable or disable the feature.

Managing RSW Manually

Info

Required

PutPolicy and GetPolicy permissions are required to set or change RSW settings.

Manage and verify remote synchronous write settings from the command line:

...

A file is completely written to the original cluster and then sent to the remote clusters before the client is notified of completion, so this incurs some latency for the request when a large file is written with remote synchronization. The new object is accessible from the source cluster even if errors prevented prevent immediate replication in any remote clusters.

In Gateway log messages, find Remote Synchronous Write statuses by looking for the prefix "RSW: ". 

At the INFO Info level of logging, a remote replication report displays:

Code Block
2020-06-17 23:59:03,396 INFO [qtp412788346-59|9403B57E570AFA2C] RSW: domain1/bucket1/object1 replicated 2 of 2 feeds in 51.63s 

When enabling DEBUG Debug levels (see Gateway Logging), view all detail statuses, which show that the remote writes are resolved before the RSW completes:

...

  • 0 means the feed is empty (completed).

  • 1 means a timeout occurred.

  • 2 or higher indicates an error.

The RSW Resultresult is 1/2 or 0/2 instead of 2/2 if anything remains in the feed that cannot be remotely written.

...