IT and coffee are well connected… at least from my perspective. If you celebrate the coffee making process you might come to a point where you use a scale to precisely weigh the amount of (excellent) coffee beans you want to grind for your cup(s) of coffee. As we do not want to have an extensive post about coffee we come to the point that at the end you usually have two ingredients: water and coffee beans. And the right quality and quantity of each makes the perfect coffee… *slurp*
Taking this analogy to the Storage World: You usually have two metrics you consider when planning or operating your storage for your workload:
Capacity + Performance
So, just configure this appropriately and enjoy your coffee… unfortunately, that sounds easier as it sometimes is since we might face situations where we have to consider scaling.
There are multiple situations where you might want to change the configuration that you have done:
- Planned change (migration, upgrade, …)
- Unforeseen change (repair, consistency check, …)
- Uncertain requirements
- Volatile environment
- Something went wrong ¯\_(ツ)_/¯
After that, the next question to answer is the “How?” and that is the trickier one. First and foremost, you must fulfill the capacity & performance needs (remember the two ingredients *slurp*). But overall, you probably have other requirements that influence your decision about the “How?”:
- (Minimize) Downtime
Gladly we are focusing on Azure NetApp Files, a native Azure storage service that enables you to use the cloud as it is intended to be: Flexible! Let’s have a look at ANF’s various options to scale:
- The Capacity Pool determines the reserved capacity and performance. (This is what you pay for.)
- The Volume inside the Capacity Pool is assigned a part (or all) of the pool’s capacity (and performance) for a single SMB share and/or NFS export.
Shaping the Volume
Depending on the QoS model of the capacity pool the volume has either one parameter (Quota) or two parameters (Quota + Throughput) to determine the available capacity and performance. These volume parameters can be changed at any time, in any direction, nearly instantaneous, and without downtime to accommodate the requirements. If scaling up you have to ensure that the hosting pool has enough capacity (and performance) or resize that as well.
- Capacity of the Volume can scale up and down
- Performance of the Volume scales linearly with the Volume’s Quota with the pool’s Service Level determined throughout.
- Azure NetApp Files documentation – Resize a capacity pool or a volume
- Capacity of the Volume can scale up and down
- Performance of the Volume can scale up and down as well (independently of the Volume’s Quota)
- Azure NetApp Files documentation – Manage a manual QoS capacity pool
- anfcommunity.com – Shape your storage performance with manual QoS capacity pools
The perfect use cases for this kind of scaling are short term requirement changes, e.g. boost SAP HANA start-up time by doubling or tripling the performance of the volume and afterwards scale-down to the real requirements.
Change a Volume’s pool
Another option is to move the Volume nearly instantaneous and without downtime into another pool. Besides pool balancing (if that is required) the main goal for that move is to influence the performance of a Volume. For more details on how to do it see Azure NetApp Files docs – Dynamically change the service level of a volume. Taking Auto and Manual QoS into considerations there are multiple scenarios to consider:
Auto QoS to Auto QoS
- In case the Service Levels of the pool’s differ, a Volume’s Service Level and performance is changed according to the Service Level’s throughput factors while maintaining the Volume’s Quota.
- There is a cool-down period of 7 days to move a volume to a lower Service Level in case it has been moved to a higher Service Level. There is no cool-down if you just move a volume down a Service Level without prior change. For more details see Azure NetApp Files docs – Dynamically change the service level of a volume
- This is typically used for long-term changes, e.g. workload requirements changed, Pilot-Light DR scenarios.
Auto QoS to Manual QoS
- If you have a volume that needs the performance to be more granularly specified then you can move it to a Manual QoS pool to gain the second, throughout parameter.
- Be aware that this move can only be done in one direction. Changing the volume back to Auto QoS is not possible.
Azure NetApp Files is an extremely flexible storage service in Azure. Scaling up and down to accommodate workload requirements and optimize cloud spendings are key elements of the service. That makes me definitely enjoy my coffee more… *slurp*.