Understanding FabricPool tiering policies

Types of FabricPool tiering policies

FabricPool tiering policies determine when or whether the user data blocks of a volume in FabricPool are moved to the cloud tier, based on the volume temperature of hot (active) or cold (inactive). The volume temperature increases when it is accessed frequently and decreases when it is not. Some tiering policies have an associated tiering minimum cooling period, which sets the time that user data in a volume of FabricPool must remain inactive for the data to be considered cold and moved to the cloud tier.

The FabricPool tiering policy is specified at the volume level. Four options are available:

The snapshot-only tiering policy (the default) moves user data blocks of the volume Snapshot copies that are not associated with the active file system to the cloud tier.
The tiering minimum cooling period is 2 days. You can modify the default setting for the tiering minimum cooling period with the -tiering-minimum-cooling-days parameter in the advanced privilege level of the volume create and volume modify commands. Valid values are 2 to 183 days using ONTAP 9.8 and later. If you are using a version of ONTAP earlier than 9.8, valid values are 2 to 63 days.
The auto tiering policy, supported only on ONTAP 9.4 and later releases, moves cold user data blocks in both the Snapshot copies and the active file system to the cloud tier.
The default tiering minimum cooling period is 31 days and applies to the entire volume, for both the active file system and the Snapshot copies.

You can modify the default setting for the tiering minimum cooling period with the -tiering-minimum-cooling-days parameter in the advanced privilege level of the volume create and volume modify commands. Valid values are 2 to 183 days.
The all tiering policy, supported only on ONTAP 9.6 and later, moves all user data blocks in both the active file system and Snapshot copies to the cloud tier. It replaces the backup tiering policy.
The tiering minimum cooling period does not apply because the data moves the cloud tier as soon as the tiering scan runs, and you cannot modify the setting.
The none tiering policy keeps data of a volume in the performance tier, preventing it from being moved to the cloud tier.
The tiering minimum cooling period does not apply because the data never moves to the cloud tier, and you cannot modify the setting.

The volume show command output shows the tiering policy of a volume. A volume that has never been used with FabricPool shows the none tiering policy in the output.

What happens when you modify the tiering policy of a volume in FabricPool

You can modify the tiering policy of a volume by performing a volume modify operation. You must understand how changing the tiering policy might affect how long it takes for data to become cold and be moved to the cloud tier.

Changing the tiering policy from snapshot-only or none to auto causes ONTAP to send user data blocks in the active file system that are already cold to the cloud tier, even if those user data blocks were not previously eligible for the cloud tier.
Changing the tiering policy to all from another policy causes ONTAP to move all user blocks in the active file system and in the Snapshot copies to the cloud tier the next time the tiering scan runs.
Moving blocks back to the performance tier is not allowed.
Changing the tiering policy from auto to snapshot-only or none does not cause active file system blocks that are already moved to the cloud tier to be moved back to the performance tier.
Volume reads are needed for the data to be moved back to the performance tier.
Any time you change the tiering policy on a volume, the tiering minimum cooling period is reset to the default value for the policy.

What happens to the tiering policy when you move a volume

Unless you explicitly specify a different tiering policy, a volume retains its original tiering policy when it is moved in and out of a FabricPool-enabled aggregate.
However, the tiering policy takes effect only when the volume is in a FabricPool-enabled aggregate.
The existing value of the -tiering-minimum-cooling-days parameter for a volume moves with the volume unless you specify a different tiering policy for the destination.
If you specify a different tiering policy, then the volume uses the default tiering minimum cooling period for that policy. This is the case whether the destination is FabricPool or not.
You can move a volume across aggregates and at the same time modify the tiering policy.

You should pay special attention when a volume move operation involves the auto tiering policy.

Assuming that both the source and the destination are FabricPool-enabled aggregates, the following table summarizes the outcome of a volume move operation that involves policy changes related to auto:

When you move a volume that has a tiering policy of...	And you change the tiering policy with the move to...	Then after the volume move...
all	auto	All data is moved to the performance tier.
snapshot-only, none, or auto	auto	Data blocks are moved to the same tier of the destination as they previously were on the source.
auto or all	snapshot-only	All data is moved to the performance tier.
auto	all	All user data is moved to the cloud tier.
snapshot-only,auto or all	none	All data is kept at the performance tier.

What happens to the tiering policy when you clone a volume

Starting in ONTAP 9.8, a clone volume always inherits both the tiering policy and the cloud retrieval policy from the parent volume.
In releases earlier than ONTAP 9.8, a clone inherits the tiering policy from the parent except when the parent has the all tiering policy.
If the parent volume has the never cloud retrieval policy, its clone volume must have either the never cloud retrieval policy or the all tiering policy, and a corresponding cloud retrieval policy default.
The parent volume cloud retrieval policy cannot be changed to never unless all its clone volumes have a cloud retrieval policy never.

When you clone volumes, keep the following best practices in mind:

The -tiering-policy option and tiering-minimum-cooling-days option of the clone only controls the tiering behavior of blocks unique to the clone. Therefore, we recommend using tiering settings on the parent FlexVol that are either move the same amount of data or move less data than any of the clones
The cloud retrieval policy on the parent FlexVol should either move the same amount of data or should move more data than the retrieval policy of any of the clones

How tiering policies work with cloud migration

FabricPool cloud data retrieval is controlled by tiering policies that determine data retrieval from the cloud tier to performance tier based on the read pattern. Read patterns can be either sequential or random.

The following table lists the tiering policies and the cloud data retrieval rules for each policy.

Tiering policy	Retrieval behavior
none	Sequential and random reads
snapshot-only	Sequential and random reads
auto	Random reads
all	No data retrieval

Starting in ONTAP 9.8, the cloud migration control cloud-retrieval-policy option overrides the default cloud migration or retrieval behavior controlled by the tiering policy.

The following table lists the supported cloud retrieval policies and their retrieval behavior.

Cloud retrieval policy	Retrieval behavior
default	Tiering policy decides what data should be pulled back, so there is no change to cloud data retrieval with default, cloud-retrieval-policy. This policy is the default value for any volume regardless of the hosted aggregate type.
on-read	All client-driven data read is pulled from cloud tier to performance tier.
never	No client-driven data is pulled from cloud tier to performance tier
promote	For tiering policy none, all cloud data is pulled from the cloud tier to the performance tier For tiering policy snapshot-only, AFS data is pulled.