Tech ONTAP Blogs
Tech ONTAP Blogs
Whenever you deploy a new Amazon FSx for NetApp ONTAP (FSx for ONTAP) instance, one of the key parameters that needs to be sized is your SSD tier capacity. Accurate sizing is the key to optimizing costs.
How can you determine how much SSD tier capacity you need to deploy? There are multiple elements that play a role in defining your FSx for ONTAP SSD tier capacity. In this post I’ll give you the full picture so you can make informed sizing decisions.
Read on as we cover:
Before you can start sizing, you’ll need some information about your current environment and to make a few estimates about how some other elements will influence SSD tier capacity. These details include:
A note on measurements: SSD capacity is expressed in GiB. That’s not quite the same thing as a GB. Remember that while 1 GB equals 1,000,000,000 bytes, 1 GiB equals 1,073,741,824 bytes, meaning 1 GB equals 0.93 GiB. That’s a considerable difference, so the two measurements aren’t interchangeable.
In this section we will go through all the elements needed to calculate the total SSD tier capacity and the formulas used to make the calculations.
Note: If you plan to decrease your provisioned SSD capacity (an option that is available only for FSx for ONTAP Generation-2), you can follow these steps to determine the new, decreased capacity size before starting the decrease operation.
Start with the initial elements explained above:
|
ID |
Element |
Value |
Unit |
|
1 |
Nominal capacity required |
Enter amount |
GiB |
|
2 |
Capacity pool % |
(nominal capacity * capacity pool %) / 100 |
GiB |
|
3 |
Storage efficiency % |
Enter expected saving % |
% |
|
4 |
Average file size |
Enter average file size |
KiB |
If you’re not sure about the values of points 2 and 3, assume that they are 0% for now.
For point 4 there are 3 possible ranges to specify:
If you’re not sure, go with the defaults. Once you have all the data, you can proceed.
Here we will calculate the SSD tier capacity after subtracting the data that will be hosted on the capacity pool, and we will calculate the amount of data required for the capacity pool metadata.
|
ID |
Element |
Calculated Value |
Unit |
|
5 |
SSD tier capacity after capacity pool |
ID 1 value - ID 2 value |
GiB |
|
6 |
Capacity pool metadata |
5% of ID 2 value |
GiB |
Here we will calculate the SSD tier capacity after subtracting the data capacity that will be saved by storage efficiencies.
|
ID |
Element |
Calculated Value |
Unit |
|
7 |
SSD tier after storage efficiencies |
(ID 5 value * (100 - ID 3 value)) / 100 |
GiB |
Here we will calculate the amount of data required by file metadata:
|
ID |
Element |
Calculated Value |
Unit |
|
8 |
File metadata |
If file size is -
|
GiB |
Here we will make an initial calculation of the total SSD tier capacity. This will be used to factor the last two elements:
|
ID |
Element |
Calculated Value |
Unit |
|
9 |
SSD capacity total |
ID 7 value + ID 6 value + ID 8 value |
GiB |
In this step we will factor two best practices:
|
ID |
Element |
Calculated Value |
Unit |
|
10 |
SSD tier after 80% max capacity |
ID 9 value / 0.8 |
GiB |
|
11 |
SSD tier after ONTAP metadata and snapshot |
|
GiB |
The last value, Element ID 11, is the final sizing value we were looking for. It represents the total SSD tier capacity that you need to use when deploying your FSx for ONTAP.
Below you can find an example sizing where the parameters are as follows:
|
ID |
Element |
Value |
Calculated Value |
|
1 |
Nominal capacity required (GiB) |
4096 |
|
|
2 |
Capacity pool % |
10% |
4096 * 10 / 100 = 409.6 GiB |
|
3 |
Storage efficiencies % |
10% |
|
|
4 |
Average file size |
1-8 KiB |
Here we’ll factor the capacity pool and its metadata:
|
ID |
Element |
Calculated Value |
Unit |
|
5 |
SSD tier after capacity pool |
4096 - 409.6 = 3686.4 |
GiB |
|
6 |
Capacity pool metadata |
409.6 * 5/ 100 = 20.48 |
GiB |
Now the storage efficiencies savings:
|
ID |
Element |
Calculated Value |
Unit |
|
7 |
SSD tier after storage efficiencies |
3686.4 * 90 / 100 = 3317.76 |
GiB |
Here is the file metadata factor:
|
ID |
Element |
Calculated Value |
Unit |
|
8 |
File metadata |
3317.76 * 0.07 = 232.24 |
GiB |
SSD Tier total capacity calculation:
|
ID |
Element |
Calculated Value |
Unit |
|
9 |
SSD capacity total |
3317.76 + 20.48 + 232.24 = 3570 |
GiB |
Factor best practices and total SSD to deploy:
|
ID |
Element |
Calculated Value |
Unit |
|
10 |
SSD tier after 80% max used capacity |
3570 / 0.8 = 4462.5 |
GiB |
|
11 |
SSD tier after ONTAP metadata and snapshot |
4462.5 / 0.84 = 5312.5 |
GiB |
And so, in this example, 5,313 GiB is the amount of SSD capacity we should use when deploying FSx for ONTAP.
In the screenshot below, you can see how to enter that size when using the AWS console:
If you’ve ever wondered what ONTAP metadata is made of, the AWS documentation page has the breakdown:
Hence, we assume that our FSx for ONTAP file system will need 16% of the SSD capacity tier for metadata.
How is this visible? To show you, I deployed a new FSx for ONTAP instance with 4,096 GiB set as SSD storage capacity. Once the deployment was completed, I ran some tests. Then, using Amazon CloudWatch to monitor the FSx for ONTAP file system, I could see the capacity that is available for my applications.
If you add the available storage (2,911,456,654,950 bytes) and used storage (789,948,516,762 bytes) you get 3,701,405,171,712 bytes, which is ~3,447 GiB. This is the actual total SSD tier capacity that is available to end users.
If you divide 3,447 GiB by the 0.84 (which is the 16% we assumed for ONTAP metadata), you’ll get 4,103 GiB, which is close to the 4,096 GiB we deployed.
This is the impact of ONTAP metadata that cannot be disregarded in your SSD tier capacity sizing.
For more insight into sizing your FSx for ONTAP SSD capacity, visit the AWS documentation for managing storage capacity.