Implementing Versioning
Swarm Versioning is an optional feature introduced in release 8.0; it is modelled on Amazon S3 Versioning to extend Gateway's support for S3.
Guidelines for Versioning
Review these guidelines before implementing versioning in your cluster:
Plan for higher disk utilization with versioning: each update to a versioned object adds a new object to the cluster (one object updated twice results in three objects stored).
Make use of lifepoints (https://perifery.atlassian.net/wiki/spaces/public/pages/2443821972) to control the lifetime - and thus the cost of storing - multiple versions of your objects.
For resource management, limit versioning to the specific domains and/or buckets for which it is needed.
For best performance, enable the Overlay Index (https://perifery.atlassian.net/wiki/spaces/public/pages/2443811756) on your cluster.
When replicating between clusters that both enable versioning, avoid unnecessary updates to versioning policies: new policies cannot take effect in the remote cluster until the domain or bucket is replicated, which may take a while.
Legal hold buckets cannot be versioning-enabled. If using legal hold, the ETag header value (which is the version identifier) needs to be used to hold a previous object version.
Upgrades: Versioning is integrated with Swarm and available on upgrade, but take these steps before enabling versioning:
Complete the upgrade of both the storage cluster (https://perifery.atlassian.net/wiki/spaces/public/pages/2443809380) and the search cluster ().
If you are using , upgrade both the source and target clusters to the same release of Swarm before enabling versioning.
Configuring Versioning
Versioning is one of several content protection features in Swarm, all are controlled by way of policies. Swarm evaluates policies for each object based on its cluster and context values:
Policy-related settings for the cluster (required)
Policy-related headers on domain and bucket objects (optional)
For how to set policies at the cluster level, see .
Context
The versioning state of a given object depends on its context:
Alias Object: context = cluster + domain in which it is tenanted
Named Object: context = cluster + domain + bucket
Important
Untenanted alias objects cannot be versioned. Alias objects are always tenanted if cluster.enforceTenancy is enabled in the cluster (which is required for Gateway).
Policy
Swarm uses the versioning policy (set via cluster settings and domain/bucket headers) to determine what versioning-related operations are allowed on each object. The versioning state of the immediate context applies to every object in that context, without exception.
Each alias or named object has one of three versioning states:
disabled | (default) This state is the normal behavior of Swarm. | If you change the state from enabled to disabled, the health processor erases the prior versions, which are now obsolete. |
|---|---|---|
suspended | No new versions are accumulated but old versions are retained. This is a hybrid between enabled and disabled that preserves history. | If you re-enable versioning from this state, the chain of versions |
enabled | New versions are accumulated as they are created, starting with any version |
To implement versioning, you need to enable it by setting your versioning policy across all affected container objects, starting with the cluster:
Cluster: set the configuration parameter
policy.versioning. (This is a , so set it via SNMP.)Domain(s): set the domain object's
Policy-VersioningandPolicy-Versioning-Unnamedheader values.Bucket(s): set the bucket object's
Policy-Versioningheader value.
Important
Setting a header does not necessarily enable versioning. For example, you may have added Policy-Versioning: enabled to a bucket, but it has no effect if its domain does not have versioning explicitly enabled.
Status Settings
The statuses for versioning vary by type of container object:
Setting | Values | Description | |
|---|---|---|---|
Cluster | Config parameter: | disallowed | Status of versioning within the cluster. Defaults to disallowed. ImportantThis is a , so set it by SNMP, not via configuration file:
|
Domain | Object header: | disabled | Status of versioning for named objects within the domain, subject to the cluster setting. |
Object header: | disabled | Status of versioning for unnamed objects that are tenanted in the domain, subject to the cluster setting. Add a | |
Bucket | Object header: | disabled | Status of versioning within the specific bucket, subject to the cluster and domain settings. |
You can verify versioning is enabled within a domain or bucket by making a HEAD request and checking the policy-related headers, Policy-Versioning[-Unnamed] (which you add) and Policy-Versioning[-Unnamed]-Evaluated (which Swarm generates). You control all Policy-Versioning[-Unnamed] headers, but Swarm computes and Policy-Versioning[-Unnamed]-Evaluated based on the policy of the complete context.
The versioning state of a domain depends on the cluster's state:
Domain Cluster |
|
|
|
|
|---|---|---|---|---|
disallowed | disabled | disabled | disabled | disabled |
suspended | disabled | suspended | suspended | suspended |
allowed | disabled | suspended | enabled | enabled |
The versioning state of a bucket depends on the parent domain's state:
Bucket Domain |
|
|
|
|---|---|---|---|
disabled | disabled | disabled | disabled |
suspended | disabled | suspended | suspended |
enabled | disabled | suspended | enabled |
required | enabled | enabled | enabled |
Managing Policies across Clusters
If you are using while using versioning, both the source and target clusters must run the same release of Swarm, but you choose how versioning occurs in the target:
Goal for Target | Target Cluster Policy | Effect |
|---|---|---|
No versioning | (default) | In the target cluster, Swarm maintains the current versions (no versioning) and cleans up any obsolete versions that are replicated. The domain and bucket objects replicate with the same policies, but the cluster-wide setting overrides them. |
No versioning, |
| In the target cluster, Swarm does not accumulate versions on local updates but preserves all prior replicated versions. |
Identical versioning |
| In the target cluster, Swarm performs versioning identically to the source cluster. The health processors in each cluster do the work of repairing the sequence of prior versions as they expand on both sides. |
Custom versioning |
| In the target cluster, Swarm performs versioning identically to the source cluster, except where you configured special context policies. Contact DataCore Support for the specific syntax needed to override policies at the domain or bucket level. |
Policies are carried on contexts, and a remote cluster evaluates policies locally based on the contexts it currently holds. Rapid changes to policies in a source cluster with changing content in those domains and buckets returns the correct results, but when those changes are replicated to the target cluster, results may differ.
© DataCore Software Corporation. · https://www.datacore.com · All rights reserved.