Based on the context (location in the cluster) policies can be created to control how many copies of a replicated object Swarm maintains. Swarm allows maintaining separate replication policies for the cluster and any domain and bucket. 

Understanding how Swarm chooses among policies is crucial to design policies because Swarm allows specifying different policies at multiple levels simultaneously. Replication specified at the object level have first priority, but the context policies constrain the minimum and maximum, as well as provide the default:

Open

See Lifepoint Metadata Headers for setting lifepoints with replication.

See SCSP Query Arguments for using replication query arguments.

Specifying Replication

Replication is one of several content protection features in Swarm. All are controlled by way of policies. Swarm evaluates policies for each object based on the cluster and context values:

• Policy-related settings for the cluster (required) 

• Policy-related headers on domain and bucket objects (optional)

For an overview of Swarm policies and how to set them at the cluster level, see Configuring Cluster Policies.

The replication policy has three parameters. All are required at the cluster level because they establish the baseline for how the cluster replicates. To lock out lower-level policies apply the optional anchored parameter to cluster and domains.

Using this 2-part setting define a different replication policy at the cluster and each context (domain and bucket) level:

Summary of value constraints:

Example: 

Starting with the cluster set the replication policy for each level with the appropriate naming and method:

Replication is subject to policy resolution on each write request. For contexts, Swarm uses the policy at the given level unless a level above it is anchored. Swarm uses the anchored policy.

A new domain has a separate required policy for named objects (which bucket are unable to override). Tenanted unnamed objects follow this policy regardless of "anchored":

Writing a domain policy

This new bucket increases the maximum, but note this policy is canceled by any policies "anchored" above it at the domain or cluster level:

Writing a bucket policy

How Replication Policies Resolve

The goal of policy resolution is to determine the correct number of replicas to keep for a content object if subject to a set of conflicting policies. This evaluation must be bounded by a minimum and maximum, and, as with all types of Swarm policies, must honor the anchored option, which inhibits evaluation at lower levels. 

Swarm evaluates replication policy according to scope, which is tied to object type (because types can be stored in a certain type of context):

Every cluster update must supply all three values (min, max, default), but any subset is allowed for domain, bucket, and unnamed. They can be in any order, and any case.

Conflict Example

Policies at different levels can conflict, such as in this example:

The most restrictive min is 6, and the most restrictive max is 5, which is not a valid pair, because the max is lower than the min. Given such a conflict, Swarm logs a warning message and reevaluates the policy, omitting the lowest level in the hierarchy (bucket, in this example), until the conflict is resolved. The lowest level is dropped because Swarm privileges the values of the cluster owner over those of the domain owner, over those of the bucket owner.