Skip to main content

FabricPool volume tiering policies

Contributors netapp-aaron-holt netapp-lenida netapp-bhouser johnlantz netapp-ahibbard netapp-thomi netapp-dbagwell netapp-aherbin
PDFs

FabricPool volume tiering policies determine what data in a volume is eligible to be tiered and the tiering minimum cooling days parameter determines when the data is considered to be inactive and eligible to be tiered.

Note

Access control lists (ACLs), directory structures, and metadata is never tiered always stays on the local tier.

A daily background tiering scan looks for cold blocks. When enough 4KB blocks from the same volume have been collected, they are concatenated into a 4MB object and moved to the cloud tier based on the volume tiering policy.

Understanding how tiering policies work will help you select the right policy for your storage management needs.

Volume tiering policy options

By default, volumes use the None volume tiering policy. The exception to this are newly created FlexVol volumes on FabricPool aggregates which use the Snapshot-Only volume tiering policy.

You can use the volume object-store tiering show command to view the tiering status of a FabricPool volume. Learn more about volume object-store tiering show in the ONTAP command reference.

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

Snapshot-only

The snapshot-only tiering policy tiers snapshot data that is no longer associated with the active file system. By default, it takes two days of inactivity before a snapshot is eligible to be tiered. Most data protection schedules are hourly or daily, and will read data locally before it is tiered.

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.

When read, cold blocks associated with snapshot copies stay cold and are not written back to the local tier.

Auto

The auto tiering policy tiers all cold data in the volume—​both the snapshots 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 snapshots.

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.

When read randomly, cold blocks in a volume with a tiering policy set to Auto are made hot and written back to the local tier.

When read sequentially, cold blocks in a volume with a tiering policy set to Auto stay cold and remain on the cloud tier. They are not written back to the local tier.

All

The all tiering policy immediately marks all data in the volume as cold and begins tiering it to the cloud tier as soon as possible. There is no need to wait 48 hours for new blocks in a volume using the all tiering policy to become cold.

The tiering minimum cooling period does not apply because the data moves to the cloud tier as soon as the tiering scan runs, and you cannot modify the setting.

When cold blocks in a volume with a tiering policy set to All are read, they remain cold and stay on the cloud tier. They are not written back to the local tier.

Note

The all volume tiering policy should not be used on read/write volumes that have normal client traffic.

Object storage is not transactional like file or block storage. Making changes to files being stored as objects in volumes using the All tiering policy can result in the creation of new objects, fragmentation of existing objects, decreased read performance, and the addition of storage inefficiencies.

None

The none tiering policy keeps a volume's data in the performance tier and does not tier data.

Setting the tiering policy to none prevents new tiering. Volume data that has previously been moved to the cloud tier remains in the cloud tier until it becomes hot and is automatically moved back to the local tier.

The tiering minimum cooling period does not apply because the data never moves to the cloud tier, and you cannot modify the setting.

When cold blocks in a volume with a tiering policy set to none are read, they are made hot and written to the local tier.

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.

Note When in an SVM DR relationship, source and destination volumes do not need to use FabricPool aggregates, but they must use the same tiering policy.

What happens when you modify a volume tiering policy

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 snapshots to the cloud as soon as possible. Prior to ONTAP 9.8, blocks needed to wait until the next tiering scan ran.

    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

  • Beginning with 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

Beginning with 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.

Learn more about the commands described in this procedure in the ONTAP command reference.