Glossary

Storage tiering

Storage tiering places data on different classes of media by how often and how quickly it is accessed, and moves it between those classes as its access pattern changes. Active data sits on fast, expensive media and inactive data on slower, cheaper media.

Tier 0 to tier 3, from DRAM to tape

In most large datasets a small working set takes most of the requests, while the bulk is written, read for a while and then left alone. Holding all of it on the fastest media pays performance prices for idle data, and holding all of it on capacity media slows the workloads that count. A common numbering scheme runs from hot storage at the top to cold storage at the bottom:

A tier differs from a flash cache in ownership. The tier holds the single authoritative copy and moves it, while a cache keeps a disposable duplicate; caches react in milliseconds and tiering over hours or days, and many systems run both.

Promotion, demotion and the flash hit rate

A tiering engine tracks access per unit (a block extent, a file or an object), scores each unit against policy, and moves units that cross a threshold, verifying the copy and updating location metadata before releasing the source. Policies are age-based, which most object lifecycle rules use; access-based, which demotes after a quiet period and promotes on the next read; heat-based, which block arrays use to keep the busiest extents on flash; pinned, which fixes data to one tier; and metadata-based, which places data by project, tag or owner.

Granularity follows the storage model. Block arrays move sub-volume extents without the host seeing anything. File tiering moves whole files and leaves a stub that recalls the file when opened. Object tiering changes an object's storage class while its key stays the same.

Take relative costs of 5 per terabyte for flash and 1 for hard drives. A 1,000 TB estate costs 5,000 units on all-flash, 1,000 on all-disk and 1,400 with 10% on flash. Latency depends on where reads land: with 90% served from flash at 0.1 ms and 10% from disk at 8 ms, the average is (0.9 × 0.1) + (0.1 × 8) = 0.89 ms, and at 99% from flash it drops to about 0.18 ms. The fast tier's hit rate moves performance far more than its share of capacity.

Cloud storage tiering between storage classes

Cloud storage tiering applies the same idea to a provider's storage classes, or to the boundary between on-premises systems and the cloud. Each step down the list lowers the capacity price and raises some other cost:

Lifecycle rules attach to a bucket or prefix with a condition, usually age since creation, and an action: transition to a class or expire. A typical rule set moves objects to infrequent access at 30 days and to archive at 180 days, then deletes them when retention ends, the wider discipline covered by storage lifecycle management. Access-based tiering watches each object's last read instead and moves it back up when it is read again, for a per-object monitoring fee, with very small objects usually excluded.

Objects in a delayed-retrieval archive class stay listed, but a read returns an error until a restore request completes and a temporary readable copy exists for a set number of days, so applications that read archived data issue the restore and wait. When an on-premises system tiers ageing data to a cloud class while keeping the metadata needed to find it, one of the patterns of hybrid cloud, reads of that data add network transfer charges to the provider's retrieval charge.

The saving depends on how much comes back. With hypothetical rates of $0.023 per GB-month for standard, $0.0125 for infrequent access and $0.01 per GB retrieved, moving 1 PB (1,000,000 GB) down saves 1,000,000 × 0.0105 = $10,500 a month, and reading 200 TB of it back each month costs 200,000 × 0.01 = $2,000, leaving $8,500. Data deleted or overwritten before a class's minimum duration is billed for the remainder, and per-object transition and monitoring fees that are trivial for large media files can outweigh a year of savings on hundreds of millions of small objects.

Recalls, reheated archives and policy drift

Across tens of petabytes, cost and performance come down to how accurately policy places data. Data placed too low brings recall delays and, in a public cloud archive class, retrieval charges, minimum durations and egress fees; data placed too high fills capacity priced for performance. Policies written once drift as applications change, so placement accuracy decays unless access data is checked against it. Demoting a petabyte also reads from one tier and writes to another, so large estates rate-limit movement and a policy change can take weeks to land.

Recovery inherits the placement. Backup or DR copies held in a delayed-retrieval class add hours of restore requests to every recovery that depends on them, which is why backup software keeps recent restore points on fast storage and ages older ones down, the arrangement described under backup storage tiers. AI and analytics reheat data: a training run or reprocessing job can pull years of archive back into use at high throughput, and a dataset sent to deep archive on the assumption it would never return takes days and retrieval fees to restore before a GPU cluster can read it. Estates serving those workloads favour online capacity tiers over offline ones.

Scality RING and storage tiering

Inside RING, placement starts with the storage class, and every class has a distinct erasure coding layout, so data assigned to a capacity-oriented class and data on a performance-oriented one cost differently on the same cluster. Movement across media is handled by Scality's Autonomous Data Infrastructure, which puts hot, warm and cold data on matching media under one namespace and one policy-driven lifecycle, so data changes tier without changing the path applications use. Scality's Azure partner page describes tiering from on-premises Scality storage to Azure Blob, where tiered data stays reachable by Azure services.