NetApp ONTAP FabricPool: Cloud Tiering Policies & CLI

Flash capacity gets expensive the moment it holds data nobody reads. FabricPool is ONTAP’s answer: it moves cold 4KB data blocks out of the local aggregate into object storage while every byte of filesystem metadata stays on flash. Clients see no stubs, no reparse points and no path changes. This article explains the mechanics, which tiering policy to choose for which workload, and how to attach a cloud tier with the ONTAP CLI.

What FabricPool Is - and What It Is Not

It helps to separate FabricPool from the three things operators most often confuse it with:

• Not a filesystem gateway. There is no namespace redirect and no client-side component. The S3 bucket is not mounted and has no path in the SVM namespace; it is a private block store owned by ONTAP.
• Not a tier of the WAFL filesystem. WAFL metadata - inodes, directory entries, indirect block pointers - never leaves the performance tier. Only user data blocks are candidates for tiering.
• Not a backup. The capacity tier alone cannot reconstruct a lost aggregate; it stores data blocks but not the metadata that makes them a filesystem.

The practical consequence is that FabricPool buys capacity economics without changing the client experience or the recovery model. Reads still hit flash for metadata, and any read of a tiered block is served through the local node.

Architecture: block-level, metadata pinned to flash

• 4KB granularity. Each block is judged independently, so a partially updated file only tiers the part that went cold.
• Metadata stays local. Inodes, directory structures and indirect block pointers remain on SSD/NVMe, which is why ls -la and backup catalogues stay fast and cost nothing in cloud egress.
• Objects, not blocks. ONTAP aggregates roughly a thousand cold 4KB blocks into a ~4MB compressed object before issuing a PUT, which keeps S3 API rates and request billing sane.
• Transparent reads. A read of a tiered block triggers a range GET and is served to the client; whether it is cached or re-warmed depends on the retrieval policy in use.

Choosing a tiering policy

• snapshot-only (default) — tiers only snapshot blocks that are not shared with the active filesystem. Cooling window 2–183 days, default 31. Safe first step: it cannot slow down active reads by definition.
• auto — tiers cold snapshot blocks and cold blocks in the active filesystem, based on the volume’s inactivity cooling period. This is what actually reclaims capacity on file shares and archive volumes.
• all — writes are buffered locally and then tiered; designed for backup repositories and read-rarely datasets.
• backup — for data protection volumes where cold data is expected to stay cold.
• none — disables tiering for the volume.

Set the cooling window to match the workload: a nightly batch job that reads yesterday’s data means auto with a 7–14 day window is far more effective than the 31-day default. Remember that any read resets the heat map — virus scanning, indexing and backup jobs that read the source files will keep blocks hot forever if they run more often than the cooling period.

How the heat map decides what is cold

Tiering is driven by a per-block temperature tracked in WAFL metadata, and the algorithm is deliberately conservative:

• Reads reset heat. Even a metadata-light sequential scan that touches a block promotes it back to hot for a full cooling period. This is why a weekly antivirus sweep with a 7-day window tiers almost nothing.
• Writes always land hot. New and modified blocks are written to the performance tier first; only after they go untouched for the cooling period do they become tiering candidates.
• Shared blocks are treated carefully. Blocks referenced by both the active filesystem and a snapshot are not tiered under snapshot-only; under auto, only the snapshot-exclusive copy leaves.
• Cooling is measured per volume. Two volumes in the same aggregate can have different cooling windows, so policy is best set at the volume level even when the aggregate has a default.

Because the decision is per block and per volume, the same aggregate can simultaneously hold a hot database that never tiers and an archive share that tiers aggressively - without a separate aggregate for each.

Attaching the cloud tier with the CLI

# Define the object store (StorageGRID example)
cluster1::> storage aggregate object-store config create
  -object-store-name mySGWS -provider-type SGWS -server mySGWSserver
  -container-name mySGWScontainer -access-key mySGWSkey
  -secret-password mySGWSpass

# Verify
cluster1::> storage aggregate object-store config show

# Attach the tier to an aggregate and set the volume policy
cluster1::> storage aggregate modify -aggregate aggr1 -tiering-policy auto
cluster1::> volume modify -vserver svm1 -volume vol1 -tiering-policy auto
cluster1::> volume modify -vserver svm1 -volume vol1 -tiering-minimum-cooling-days 14

Use signed certificates (-is-certificate-validation-enabled true) in production, and for SAN workloads NetApp recommends a private cloud tier such as StorageGRID rather than a hyperscaler, because read latency on tiered blocks lands directly in the I/O path.

Before attaching a tier, decide the object store's own characteristics: its latency, its durability model, and whether it is reachable from every node in the cluster. A cloud tier that is slow or intermittently unreachable turns a capacity optimisation into a random performance incident, because ONTAP will block on a tiered read rather than silently returning an error.

Object store sizing and network considerations

storage aggregate object-store config show -instance
storage aggregate object-store show
network interface show -role data

Three numbers drive whether a cloud tier behaves well in production:

• Bandwidth. Tiering moves at the speed of the slowest link in the path. A 1GbE management network used for object traffic will make the first tiering window take days.
• Latency. Every tiered read pays the round trip. Keep the object store in the same metro, or use a private StorageGRID grid for anything latency-sensitive.
• Object count. 4MB objects across tens of terabytes add up to millions of objects; make sure the capacity tier's own limits - bucket policies, per-account request rates, lifecycle rules - can absorb that.

Also confirm that no existing lifecycle rule on the bucket deletes or transitions objects the grid put there. A bucket lifecycle policy that expires objects after 90 days will quietly shred parts of your capacity tier.

Operations that matter

volume show -fields tiering-policy,tiering-minimum-cooling-days
storage aggregate show-space -fields object-store-space-used
volume object-store-tag show

FabricPool is not a backup. WAFL metadata never goes to the cloud tier, so a destroyed performance tier cannot be rebuilt from the capacity tier — keep SnapMirror or your existing backup tooling in place and treat FabricPool purely as a capacity optimisation.

Monitoring tiering health

storage aggregate show -fields tiering-policy
volume show-footprint -vserver svm1 -volume vol1
storage aggregate object-store config check

What you are watching for is progress, not perfection. object-store-space-used should climb steadily after a policy change and then plateau; a flat line means blocks are not reaching the cooling threshold (usually a scanner keeping them hot). A value that oscillates up and down in large steps means blocks are being tiered and immediately read back, which is the signature of a cooling window shorter than the workload's real access interval.

Two operational habits pay for themselves: set the tiering policy at the volume level rather than relying on an aggregate default, and re-check volume show-footprint after every major workload change, because a new backup job scanning a previously cold share can reset the entire heat map in a single run.

Object store options: StorageGRID, ONTAP S3 or a hyperscaler

The table hides one important nuance: using ONTAP S3 as the capacity tier means both the performance tier and the capacity tier are the same cluster, so it is a capacity-management feature rather than a true off-cluster cloud tier. It is still useful for testing a policy before committing to external object storage, because tiering behaviour and cool-down logic are identical.

Retrieval and read behaviour on a tiered block

A read that lands on a tiered block is not simply a slow read - it is a different code path, and knowing it explains most FabricPool performance questions:

• Range GET. ONTAP issues an S3 range GET for the ~4MB object that contains the requested block, not a full-object GET.
• Inline local cache. The fetched object is cached on the local node's SSD, so a second read of the same region is served at flash speed.
• No automatic re-warm by default. Reading a block marks it hot, but the next tiering pass decides whether it moves back. A single read can therefore produce a repeat GET on the next access if the object is evicted from cache first.
• Read-modify-write. A write to a tiered block must fetch the current object, modify it, and write back - so write-heavy workloads on tiered data pay double.

This is why the workload profile, not the capacity figure, should drive the policy choice: random-write databases are hostile to tiering, while append-only archives are nearly ideal.

Common FabricPool mistakes

• Tiering the only copy. FabricPool moves data out of the aggregate; it does not create a second copy. If the aggregate is the single source of truth, the capacity tier is an availability dependency, not a safety net.
• Cooling window shorter than the access cycle. A 7-day window on a share read every 5 days produces continuous tier-in/tier-out churn and worse performance than leaving the data on flash.
• Ignoring the object store's latency SLA. Hyperscaler cold tiers can add hundreds of milliseconds per read; for SAN, choose a private grid.
• Forgetting snapshot policy interaction. Higher snapshot retention means more snapshot-only candidates, which can make snapshot-only far more effective than expected - measure before switching to auto.

When FabricPool is the wrong answer

Skip the cloud tier and buy flash when: the dataset is small enough that the object-store overhead exceeds the savings; the data is genuinely active (a database, a VDI pool, an AI training set read continuously); or compliance requires that data never leave the site and a private grid is not available. FabricPool shines on archives, aged project data, backup targets and snapshot-heavy volumes where the read rate is low and the capacity pressure is real.

Related reading: ONTAP S3 object store buckets, SnapMirror configuration with the CLI and FlexGroup create and expand with the CLI.

原文链接：https://docs.netapp.com/us-en/ontap-apps-dbs/pdfs/sidebar/Tiering_strategies.pdf