Release notes
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 do not 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. Changing a system's tiering level enables you to choose a different S3 storage class.
- 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. - Tiering levels
-
If you don't plan to access the inactive data, you can reduce your storage costs by changing a system's tiering level to one of the following: Intelligent Tiering, One-Zone Infrequent Access, or Standard-Infrequent Access. When you change the tiering level, inactive data starts in the Standard storage class and moves 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 tiering level. Learn more about Amazon S3 storage classes.
Changing the tiering level is possible after you create the system. For details, see Tiering inactive data to low-cost object storage.
The tiering level is system wide—it is 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. Changing a system's tiering level enables you to choose a different Azure storage tier.
- 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. - Tiering levels
-
If you don't plan to access the inactive data, you can reduce your storage costs by changing a system's tiering level to the Azure cool storage tier. When you change the tiering level, inactive data starts in the hot storage tier and moves 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 tiering level. Learn more about Azure Blob storage access tiers.
Changing the tiering level is possible after you create the system. For details, see Tiering inactive data to low-cost object storage.
The tiering level is system wide—it is 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. - Tiering levels
-
No other GCP storage classes are supported at this time.
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.
- 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.