Storage
Mobility
Protection
Analysis and control
TOPICShare
NetApp’s Cloud Tiering service is an intelligent data tiering technology that optimizes the usage of your NetApp AFF or SSD-backed FAS storage systems by moving cold data from those systems to object storage in the cloud. Cloud Tiering classifies data as cold and ready to be tiered once a certain amount of time passes without that data being accessed—a policy attribute known as minimum cooling days.
But what if that default cooling period isn’t optimal for your application or business requirements? In this blog, we’ll look at how to change your default Cloud Tiering cooling period.
Data Tiering and the Cooling Period
In conjunction with the tiering policy type that defines what types of cold data blocks are eligible for tiering, the policy’s cooling period defines when these types of blocks become cold. The cooling period defines how much time should elapse, without the data blocks being accessed, to declare them as cold and ready to be tiered.
To understand how the cooling period affects tiering, we first need to know what tiering policies are available and which of the tiering policies utilize cooling periods. Below are the tiering policies available on ONTAP 9.7, the current version.
No-policy (None): Nothing is tiered, therefore the cooling period cannot be used.
All user data (All, Formerly “Backup”): All the data blocks in the volume are immediately classified as cold, therefore, the cooling period cannot be used.
Cold-snapshots (Snapshot-only): Snapshot data blocks that are not shared with the volume’s active file system are moved to the capacity tier once marked as cold, and the cooling period determines when they become cold. The default cooling period for the snapshot-only policy is 2 days. This is also the minimum cooling period for this policy, though it can be changed to a longer period of time.
Cold user data and snapshots (Auto): User data blocks from the active file system and snapshot copies are tiered when classified as cold, based on the cooling period determining when they become cold. The default cooling period for data using this tiering policy is 31 days.
The Cooling Period
The cooling period itself defines how many days a data block should remain unaccessed before being marked as cold. Any access to the data block, whether it is read or rewritten, will reset the data block temperature back to hot and the cooling period clock back to the start. When the tiering process runs, only cold data blocks are moved to the capacity tier.
Let’s consider the following scenario. A volume used as storage for a centralized log management system is configured with the “cold user data and snapshots” tiering policy. Each day a new log file is created and written until the day ends; the log management system consumes the log files once written, and after that, the logs files are usually not needed. After two days, a process compresses the log files to save space. Under normal circumstances, after three days, the log files gather dust.
However, because the default cooling period of this tiering policy is 31 days, the log files, though compressed, will use precious space on the performance tier for 28 days longer than needed. Setting the cooling period to three days will move the log files’ data blocks to the capacity earlier, recovering the space for other use.
Conversely, consider a situation where a business produces reports that are compared month-by-month, and the database volumes are tiered to a capacity tier using the same tiering policy. Using the default 31-day cooling period could result in the previous month's data blocks having to move back to the performance tier when the database runs the report. That may cause some latency in the report and potential egress charges from your cloud storage provider. Increasing the cooling period to 62 days would ensure that the two months of data required for reporting remains available on the performance tier.
Based on the cooling period set in the policy, after a block was classified as cold, it is ready to be tiered. The movement of that cold block to the capacity tier would happen once enough 4KB blocks from the same volume are identified as cold, so a 4MB object can be created and tiered.
How to Change the Default Cloud Tiering Cooling Period
Changing the default number of cooling days for both of the Snapshot-Only and Auto tiering policies can be done through the Cloud Tiering service UI, now available through NetApp Cloud Manager. For CLI fans, changing the cooling period can be done through ONTAP’s clustershell with the volume modify command using the -tiering-minimum-cooling-days parameter.
In the following step-by-step example we will show how to use Cloud Tiering UI to change it on a NetApp All Flash FAS system, named AFF-AZURE2_2, that was already defined to use Cloud Tiering.
AFF-AZURE2_2 has two volumes, which are named volume_17 and volume_18. volume_17 is already cloud-tiered with the “cold user data and snapshots” (Auto) tiering policy. In the following steps we will change the cooling days associated with volume_17 tiering policy from 31 days to three days.
Step by Step
- First, log in to NetApp Cloud Manager and click on the Tiering tab at the header menu. Here you will be presented with Cloud Tiering’s cluster dashboard. Now scroll down the page until you allocate the cluster, AFF-AZURE2_2 in this case, which contains the designated volume to be changed.
We select "TIER VOLUMES" to view the volumes on AFF-AZURE2_2.
- Once the list of volumes appears, you can use the pencil icon to the right to edit the volume’s tiering settings. In this example, we can see AFF-AZURE2_2 and both its volumes; notice volume_17 is tiered using the "Cold user data & snapshots" (auto) policy.
Click the pencil icon at the right end of volumes_17's row to view or change its tiering details.
- In the volume’s tiering settings window, we can select the tiering policy to be used and, where applicable, adjust the cooling period. As shown below, the cooling period called "COOLING DAYS" is adjusted using a slider, which is currently set to the default of the selected policy, which in this case is 31 days.
- You can change the default cooling period simply by sliding the COOLING DAYS knob to 3 days and clicking the APPLY button. Your new cooling period is now set. Notice the APPLY button becomes a deeper blue when sliding the knob.
Conclusion
For some environments, the default cooling days may not be optimal and should be properly configured to meet your application’s requirements. As demonstrated, changing the default cooling period of the applicable policies is quite simple and can provide you with optimal performance and high performant storage usage while reducing your TCO. Changing the cooling period could recover substantial performance tier capacity with minimal changes and no risk.
Try out Cloud Tiering service yourself today and find your optimal cooling period, sign up for a free trial here
