Data tiering overview
Suggest changes
PDFs
Reduce your storage costs by enabling automated tiering of inactive data to low-cost object storage. Active data remains in high-performance SSDs or HDDs, while inactive data is tiered to low-cost object storage. This enables you to reclaim space on your primary storage and shrink secondary storage.
Cloud Volumes ONTAP supports data tiering in AWS, Azure, and Google Cloud Platform. Data tiering is powered by FabricPool technology.
|
You don't need to install a feature license to enable data tiering (FabricPool). |
Data tiering in AWS
When you enable data tiering in AWS, Cloud Volumes ONTAP uses EBS as a performance tier for hot data and AWS S3 as a capacity tier for inactive data.
- Performance tier
-
The performance tier can be General Purpose SSDs, Provisioned IOPS SSDs, or Throughput Optimized HDDs.
- Capacity tier
-
A Cloud Volumes ONTAP system tiers inactive data to a single S3 bucket using the Standard storage class. Standard is ideal for frequently accessed data stored across multiple Availability Zones.
Cloud Manager creates a single S3 bucket for each working environment and names it fabric-pool-cluster unique identifier. A different S3 bucket is not created for each volume. - Storage classes
-
The default storage class for tiered data in AWS is Standard. If you don't plan to access the inactive data, you can reduce your storage costs by changing the storage class to one of the following: Intelligent Tiering, One-Zone Infrequent Access, or Standard-Infrequent Access. When you change the storage class, inactive data starts in the Standard storage class and transitions to the storage class that you selected, if the data is not accessed after 30 days.
The access costs are higher if you do access the data, so take that into consideration before you change the storage class. Learn more about Amazon S3 storage classes.
You can select a storage class when you create the working environment and you can change it any time after. For details about changing the storage class, see Tiering inactive data to low-cost object storage.
The storage class for data tiering is system wide—it's not per volume.
Data tiering in Azure
When you enable data tiering in Azure, Cloud Volumes ONTAP uses Azure managed disks as a performance tier for hot data and Azure Blob storage as a capacity tier for inactive data.
- Performance tier
-
The performance tier can be either SSDs or HDDs.
- Capacity tier
-
A Cloud Volumes ONTAP system tiers inactive data to a single Blob container using the Azure hot storage tier. The hot tier is ideal for frequently accessed data.
Cloud Manager creates a new storage account with a single container for each Cloud Volumes ONTAP working environment. The name of the storage account is random. A different container is not created for each volume. - Storage access tiers
-
The default storage access tier for tiered data in Azure is the hot tier. If you don't plan to access the inactive data, you can reduce your storage costs by changing to the cool storage tier. When you change the storage tier, inactive data starts in the hot storage tier and transitions to the cool storage tier, if the data is not accessed after 30 days.
The access costs are higher if you do access the data, so take that into consideration before you change the storage tier. Learn more about Azure Blob storage access tiers.
You can select a storage tier when you create the working environment and you can change it any time after. For details about changing the storage tier, see Tiering inactive data to low-cost object storage.
The storage access tier for data tiering is system wide—it's not per volume.
Data tiering in GCP
When you enable data tiering in GCP, Cloud Volumes ONTAP uses persistent disks as a performance tier for hot data and a Google Cloud Storage bucket as a capacity tier for inactive data.
- Performance tier
-
The performance tier can be either SSDs or HDDs (standard disks).
- Capacity tier
-
A Cloud Volumes ONTAP system tiers inactive data to a single Google Cloud Storage bucket using the Regional storage class.
Cloud Manager creates a single bucket for each working environment and names it fabric-pool-cluster unique identifier. A different bucket is not created for each volume. - Storage classes
-
The default storage class for tiered data is the Standard Storage class. If the data is infrequently accessed, you can reduce your storage costs by changing to Nearline Storage or Coldline Storage. When you change the storage class, inactive data starts in the Standard Storage class and transitions to the storage class that you selected, if the data is not accessed after 30 days.
The access costs are higher if you do access the data, so take that into consideration before you change the storage class. Learn more about storage classes for Google Cloud Storage.
You can select a storage tier when you create the working environment and you can change it any time after. For details about changing the storage class, see Tiering inactive data to low-cost object storage.
The storage class for data tiering is system wide—it's not per volume.
Data tiering and capacity limits
If you enable data tiering, a system's capacity limit stays the same. The limit is spread across the performance tier and the capacity tier.
Volume tiering policies
To enable data tiering, you must select a volume tiering policy when you create, modify, or replicate a volume. You can select a different policy for each volume.
Some tiering policies have an associated minimum cooling period, which sets the time that user data in a volume must remain inactive for the data to be considered "cold" and moved to the capacity tier.
Cloud Manager enables you to choose from the following volume tiering policies when you create or modify a volume:
- Snapshot Only
-
After an aggregate has reached 50% capacity, Cloud Volumes ONTAP tiers cold user data of Snapshot copies that are not associated with the active file system to the capacity tier. The cooling period is approximately 2 days.
If read, cold data blocks on the capacity tier become hot and are moved to the performance tier.
- All
-
All data (not including metadata) is immediately marked as cold and tiered to object storage as soon as possible. There is no need to wait 48 hours for new blocks in a volume to become cold. Note that blocks located in the volume prior to the All policy being set require 48 hours to become cold.
If read, cold data blocks on the cloud tier stay cold and are not written back to the performance tier. This policy is available starting with ONTAP 9.6.
- Auto
-
After an aggregate has reached 50% capacity, Cloud Volumes ONTAP tiers cold data blocks in a volume to a capacity tier. The cold data includes not just Snapshot copies but also cold user data from the active file system. The cooling period is approximately 31 days.
This policy is supported starting with Cloud Volumes ONTAP 9.4.
If read by random reads, the cold data blocks in the capacity tier become hot and move to the performance tier. If read by sequential reads, such as those associated with index and antivirus scans, the cold data blocks stay cold and do not move to the performance tier.
- None
-
Keeps data of a volume in the performance tier, preventing it from being moved to the capacity tier.
When you replicate a volume, you can choose whether to tier the data to object storage. If you do, Cloud Manager applies the Backup policy to the data protection volume. Starting with Cloud Volumes ONTAP 9.6, the All tiering policy replaces the backup policy.
Turning off Cloud Volumes ONTAP impacts the cooling period
Data blocks are cooled by cooling scans. During this process, blocks that haven't been used have their block temperature moved (cooled) to the next lower value. The default cooling time depends on the volume tiering policy:
-
Auto: 31 days
-
Snapshot Only: 2 days
Cloud Volumes ONTAP must be running for the cooling scan to work. If Cloud Volumes ONTAP is turned off, cooling will stop, as well. As a result, you might experience longer cooling times.
Setting up data tiering
For instructions and a list of supported configurations, see Tiering inactive data to low-cost object storage.