Object Storage Classes and Cloud Tiering

From OSNEXUS Online Documentation Site
Revision as of 17:40, 28 September 2026 by Qadmin (talk | contribs) (New page: object storage classes and tiering from local Ceph to AWS S3 / Glacier (6.9). Verified end to end on a 6.9.0 cluster against a real AWS S3 bucket)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


An Object Storage Class decides where the data of an S3 object lives. This page covers the two kinds QuantaStor creates on a scale-out object cluster -- pool-backed classes that place objects on a particular Ceph data pool, and cloud-tier classes that move objects out to a bucket on AWS S3, S3 Glacier or another S3-compatible service -- and walks through tiering objects from a local bucket to the cloud end to end.

Section Purpose
Tiering objects to a cloud bucket, end to end The complete workflow: credentials, cloud storage class, lifecycle rule, verification
Tiering is not replication How cloud tiering differs from bucket sync, Cloud Containers and backup
How storage classes work STANDARD, pool-backed classes and cloud-tier classes
Which cloud providers can back a storage class Providers and their storage classes
Creating a storage class Every field of the Create Object Storage Class dialog
Tiering to S3 Glacier and other archive classes Retrieval settings, which only the CLI accepts
Steering new uploads with auto-tiering rules Picking a class at upload time instead of by age
Deleting a storage class What is removed, what is refused, and Force
Managing storage classes from the CLI Command reference

Tiering objects to a cloud bucket, end to end

Cloud tiering keeps recent objects on the local Ceph cluster and moves older ones to a cheaper bucket in the cloud, without the S3 client doing anything. It takes four steps: give QuantaStor a cloud account, create a cloud-tier storage class that points at it, add a lifecycle rule to the bucket that moves objects into that class after a number of days, and confirm the rule is in place.

You need a scale-out object cluster with at least one object gateway and an Object Storage Pool Group; see Scale-out Object Setup (ceph).

Step 1: Add cloud provider credentials

Navigation: Cloud Integration → Cloud Credentials → Add Credentials (toolbar)

Add the access key and secret key of the cloud account. Credentials are shared with Cloud Containers, and the dialog is described on Cloud Containers / NAS Gateway. Pick a provider that can back a storage class -- see Which cloud providers can back a storage class.

For an S3-compatible service that is not in the built-in list, add it as a private provider first and select Supports Ceph Cloud Tiering in the Add Cloud Provider dialog. Without that option its credentials are not offered for cloud tiering.

Step 2: Create a cloud-tier storage class

Navigation: Scale-out Storage Configuration → Scale-out Storage Pools (section) → select the Ceph Cluster → Object Storage (toolbar group) → Create Object Storage Class
Create Object Storage Class with Destination Cloud selected: the class name, the cloud credentials, the region, and the provider storage class that tiered objects are written into.

Select Destination Cloud, enter a Storage Class Name (for example AWS_IA), and pick the credentials, the Location/Region and the provider Storage Class that tiered objects are written into, such as STANDARD_IA. Pick a named provider storage class rather than Default; see the note under Creating a storage class. The fields are described in full there.

To tier into S3 Glacier or Glacier Deep Archive, create the class from the CLI instead; see Tiering to S3 Glacier and other archive classes.

Step 3: Add a lifecycle transition rule to the bucket

Navigation: Storage Management → Object Buckets (section) → search, then select a bucket → Bucket Lifecycle Policies (toolbar group) → Create
A lifecycle rule that moves every object in the bucket to the AWS_IA cloud-tier class 30 days after it is written.

Enter a Name (Rule Id), select Transition, set Transition Days and choose the storage class you created in step 2. Leave Prefix, Min Size and Max Size empty to tier every object in the bucket, or set them to tier only part of it. The dialog is described on Bucket Lifecycle Policy.

Step 4: Confirm the rule and watch objects move

Confirm the rule with qs bucket-lifecycle-policy-get --lifecycle-policy=<rule id> --bucket=<bucket>, or open View in the Bucket Lifecycle Policies toolbar group after a deep scan. An S3 client can read the same rule back with the S3 GetBucketLifecycleConfiguration call.

The object gateway runs lifecycle processing in the background, so an object moves some time after it reaches the rule's age rather than at that exact moment. Once it has moved, its data is in the cloud bucket and the local copy is reduced to a head object that keeps the object listed in the local bucket. A HEAD request on it reports the cloud storage class name, and a listing of the local bucket shows the object with a size of 0.

The same workflow from the CLI, with the IDs taken from the list commands in the first three lines:

qs cloud-provider-credentials-list
qs cloud-provider-location-list
qs cloud-provider-storage-class-list
qs object-storage-class-create --storage-class-name=AWS_IA --custom-storage-class-name=true --ceph-cluster=<cluster> --tiering-cloud-credentials=<credentials id> --tiering-cloud-location=<location id> --tiering-cloud-storage-class=<provider storage class id>
qs bucket-lifecycle-policy-create --bucket=<bucket> --rule-id=to-aws-ia --transition-days=30 --transition-storage-class=AWS_IA
qs bucket-lifecycle-policy-get --lifecycle-policy=to-aws-ia --bucket=<bucket>

The commands are qs cloud-provider-credentials-list, qs cloud-provider-location-list, qs cloud-provider-storage-class-list and qs object-storage-class-create, followed by the lifecycle commands described on Bucket Lifecycle Policy.

Tiering is not replication

Cloud tiering moves an object: after the transition there is one copy of its data, in the cloud bucket. It is not a second copy and it does not protect against losing the cloud account. Pick the feature by what you want to end up with.

Feature Result Between
Cloud tiering (this page) Older objects move to a cloud bucket; the local bucket keeps a small head object for each A local Object Bucket and a bucket at an S3 provider
Bucket sync policies Objects are copied continuously so both sides hold the data Two zones of one RGW multi-site zone group, both QuantaStor
Cloud Containers One external bucket is presented as an NFS/SMB share A Network Share and a bucket at an S3 provider
Backup policies Files are copied, moved or auto-tiered on a schedule A Network Share and an NFS/SMB export or a Cloud Container

How storage classes work

An S3 client names a storage class when it writes an object, and the object gateway maps each class name to a place to store the data. Every object zone starts with one class, STANDARD, which is backed by the zone's default data pool and is used whenever a client names no class.

  • A pool-backed class has its own Ceph data pool, with its own layout (replica or erasure coding) and its own media, so a class can put objects on flash or on high-capacity disk.
  • A cloud-tier class has no local data pool. QuantaStor registers it on the zone group as a cloud tier that points at a bucket at an S3 provider. Objects reach it through a lifecycle transition; a cloud-tier class is a destination for transitions, not a class that clients write to directly.

Storage class names use letters and underscores only and are converted to upper case. STANDARD is reserved. Many S3 tools only accept the AWS class names (STANDARD_IA, ONEZONE_IA, INTELLIGENT_TIERING, GLACIER_IR, REDUCED_REDUNDANCY, EXPRESS_ONEZONE, OUTPOSTS); any other name needs the custom-name option. The dialog sets it for you when you create a cloud-tier class; from the CLI, add --custom-storage-class-name=true to use a name such as AWS_IA.

A class name is unique within a Ceph cluster.

Which cloud providers can back a storage class

Only providers that speak the S3 protocol can back a cloud-tier class. Of the built-in providers these are:

Provider Provider storage classes offered
Amazon S3 STANDARD, REDUCED_REDUNDANCY, STANDARD_IA, ONEZONE_IA, GLACIER, DEEP_ARCHIVE, INTELLIGENT_TIERING, GLACIER_IR
Wasabi S3 Standard, reduced redundancy, standard infrequent access
Backblaze B2 None pre-populated. Add one with qs cloud-provider-storage-class-add before creating a class, because a named provider storage class is required
IBM Cloud Object Storage (COS) standard, vault, cold and others

Microsoft Azure Blob, Google Cloud Storage, Google Drive and Dropbox cannot back a cloud-tier class, and their credentials are not offered. A private provider added with Supports Ceph Cloud Tiering selected can, which is how an on-premises or third-party S3 service becomes a tiering target. Add storage classes to a private provider with qs cloud-provider-storage-class-add; there is no dialog for it.

The provider list and its storage classes are read from /opt/osnexus/quantastor/conf/qs_cloud_providers.conf.

Creating a storage class

Navigation: Scale-out Storage Configuration → Scale-out Storage Pools (section) → select the Ceph Cluster → Object Storage (toolbar group) → Create Object Storage Class

The dialog is also on the Ceph Cluster's right-click menu. On a narrow window the Object Storage toolbar group is behind the toolbar's overflow arrow. It creates either kind of class, chosen by two radio buttons. Destination Cloud is unavailable until at least one set of cloud credentials exists.

Field Shown for Notes
Ceph Cluster both The cluster the class is created on. Only clusters with an Object Storage Pool Group are listed.
Destination Data Pool / Destination Cloud both Chooses the kind of class. Data Pool is the default.
Storage Class Name Destination Cloud The name S3 clients and lifecycle rules use. Letters and underscores only.
Cloud Provider Destination Cloud Despite the label this lists credentials, shown as provider (access key). Only providers that support cloud tiering are listed.
Location/Region Destination Cloud The provider endpoint the tiered objects are written to. Defaults to the provider's default region.
Storage Class Destination Cloud The provider's storage class for the tiered objects, for example STANDARD_IA. Choose a named class; see the note below.
Storage class name and layout fields Destination Data Pool The class name, the Object Storage Pool Group, and the data pool layout (replica or erasure coding, scaling factor), as for any scale-out pool.
Force (Required for Erasure M=1) Destination Data Pool Required to create an erasure-coded data pool with a single parity chunk.

Choose a named provider storage class. In this release the Default entry in the cloud Storage Class list does not create a class: the request is refused because no provider storage class was given. Pick the provider class you want the objects stored in.

A cloud-tier class is created by registering a cloud-s3 tier on the zone group's default placement and committing the gateway configuration. If any step fails the partial registration is rolled back, so a failed create can simply be retried.

The dialog does not ask which bucket at the provider receives the tiered objects; the gateway chooses the destination itself. To send them to a bucket you choose -- for example one that the credentials are restricted to -- create the class from the CLI with --tiering-path=<bucket>. Tiered objects are stored under a prefix named after the local bucket.

The tier configuration holds a copy of the access key and secret key. Changing or removing the credentials in QuantaStor afterwards does not update an existing class; to rotate the key, delete the class and create it again with the new credentials.

Tiering to S3 Glacier and other archive classes

Archive storage classes -- GLACIER, DEEP_ARCHIVE and GLACIER_IR at Amazon S3, and vault and cold at IBM COS -- do not return an object on a normal GET; the object has to be restored first. A cloud-tier class that targets one of them is registered as a cloud-s3-glacier tier and needs three extra settings that the Create Object Storage Class dialog does not have, so create it with qs object-storage-class-create:

Argument Required Meaning
--tiering-retrieval-duration yes Days a restored object is kept on local storage before it reverts to the archive tier. Must be a whole number above zero.
--tiering-retrieval-target-class yes The local storage class a restored object is placed in, for example STANDARD.
--tiering-retrieval-tier-type no The provider's retrieval speed: Standard (the default), Expedited or notier.
qs object-storage-class-create --storage-class-name=AWS_GLACIER --custom-storage-class-name=true --ceph-cluster=<cluster> --tiering-cloud-credentials=<credentials id> --tiering-cloud-location=<location id> --tiering-cloud-storage-class=<GLACIER storage class id> --tiering-retrieval-duration=7 --tiering-retrieval-target-class=STANDARD --tiering-retrieval-tier-type=Standard

Selecting one of these provider classes in the dialog fails, because the dialog cannot supply the retrieval settings.

Steering new uploads with auto-tiering rules

Lifecycle rules move objects by age. Auto-tiering rules pick a class when the object is uploaded, by name pattern, size, bucket or tenant, so that, for example, large objects land on a high-capacity pool-backed class from the start.

Manage auto-tiering rules from the CLI with qs object-storage-class-rule-add. Each rule is STORAGECLASS;PATTERN;OPERATOR;CAPACITY;BUCKET;TENANT;OPTIONS, and force in OPTIONS applies the rule even when the client named a class of its own:

qs object-storage-class-rule-add --rule-list="STANDARD_IA;*;>=;32768;*;*;force"

Deleting a storage class

Navigation: Scale-out Storage Configuration → Scale-out Storage Pools (section) → select the Ceph Cluster → Object Storage (toolbar group) → Delete Object Storage Class

The dialog shows the class's Type -- Cloud Tier or Pool-backed -- and its Data Pool Name, and asks for confirmation.

  • A pool-backed class is deleted together with its data pool and every object in it.
  • A cloud-tier class has its tier registration removed from the zone group. Objects already written to the cloud bucket are left there; QuantaStor does not delete them.
  • STANDARD cannot be deleted on its own, because the gateway would immediately recreate its data pool. It goes when the Object Storage Pool Group is destroyed.

The delete is refused while anything still names the class -- an auto-tiering rule, a bucket lifecycle transition, or another class that uses it as its Glacier retrieval target -- and, for a pool-backed class, while its data pool holds objects. Force (required if referenced, or the data pool is not empty) overrides both, and also deletes the rules and lifecycle transitions that reference the class. Without those references a lifecycle rule would keep trying to move objects to a class the gateway no longer knows.

When multi-admin approval covers Object Storage Class : Delete, the delete waits until the required number of administrators approve it.

The CLI equivalent is qs object-storage-class-delete --storage-class=<name> --ceph-cluster=<cluster>. Use the dialog when the delete needs Force.

Managing storage classes from the CLI

Command Purpose
qs object-storage-class-list List the storage classes, optionally for one --ceph-cluster
qs object-storage-class-get Show one class, by --storage-class
qs object-storage-class-create Create a pool-backed class (--ceph-object-pool-group and layout arguments) or a cloud-tier class (--tiering-* arguments)
qs object-storage-class-delete Delete a class
qs object-storage-class-rule-add, qs object-storage-class-rule-remove, qs object-storage-class-rule-list Manage auto-tiering rules
qs cloud-provider-add Add a private S3 provider; --supports-ceph-tiering=true makes it usable for cloud tiering
qs cloud-provider-storage-class-add Add a storage class to a provider, with --provider, --storage-class-tag and --storage-description

A pool-backed class, for comparison:

qs object-storage-class-create --storage-class-name=STANDARD_IA --ceph-object-pool-group=<pool group> --pool-type=erasure --k=4 --m=2

Related pages


Verified against QuantaStor 6.9.0.