NetApp AFF and Advanced Drive Partition V2, part 4

In the final instalment of this series, I’ll have a look at AFF setups that have about the same usable capacity, but are built out of different set of SSD drives. Both are using ADPv2 to maximize usable capacity.

This is also the point where things get little bit hairy.

In previous posts I was comparing apples to apples in hardware terms, the only difference was version of ADP used, solutions under comparison were equal in terms of total cost and performance.  Since ADPv2 is more efficient, you can lower $/GB without altering total cost or performance, making AFF more cost effiecient, you get more bang for your buck.

This time I am comparing apples to oranges in hardware terms. Using different hardware components makes comparison more complex, it is not just about usable capacity, different hardware has also different performance characteristics and total cost. I am not going to touch performance aspect too much as it would overcomplicate the comparison.

To gain full understanding of ADPv2 capacity benefits with larger SSD drives, one has to take into count different pricing models. While I am not at liberty to publish any exact pricing information with dollar figures, I’ll try explain it in rough terms.

1. Cost of AFF capacity is divided into two parts, cost of HW and capacity based software license cost
2. Software license cost is calculated based on raw marketing capacity of SSD drives
3. Software capacity licenses are lower per GB for larger SSD drives (3,8 TB & 15,3 TB) than with smaller SSD drives (400GB,800GB,1600GB)

One could achieve roughly the same usable capacity compared to 12×3,8TB SSD setup by using more smaller drives, in this case 24×1,6TB SSD drives.

Example 1: 12×3,8TB SSD

Usable capacity for 12×3,8TB SSD is about 29,85 TB or 65,46% usable capacity out of marketing raw capacity.

Example 2: 24×1,6TB SSD

Usable capacity for 24×1,6TB SSD is about 29,14 TB or 75,90% usable capacity out of marketing raw capacity.

Without fully understanding how the capacity pricing model works, one would probably go with 24×1,6 TB setup, as it has few advantages:

• Quite often bottleneck in All Flash solutions is the controller, not the disks. However number of SSDs plays some part in performance, like with disks more SSDs is faster than less SSDs until you max out your storage controller
• It is more efficient, you get more usable capacity from raw capacity (75,90%  vs 65,46%), meaning that for roughly the same usable capacity there is less raw capacity and less software license units to buy

As side node: Nobody really should care about raw capacity, the only thing related to capacity that matters to end-customers is the cost of usable capacity. However this is the way NetApp has decided to price software licenses for AFF. One reason for this decision probably was , that it is easier to make calculations consistently with raw capacity as usable vs raw capacity can vary depending on the way system is setup.

But there was that third “rule” in pricing, lower $/GB software license cost for large drives

• Is software cost per GB for larger drives so much lower that it will offset less efficient 12×3,8TB setup ( 45,6 TB raw)?
• Or is the difference be so small that more efficient 24×1,6TB setup (38,4TB raw) will be cheaper?

Now what about the total cost of solution then?

• In this case the HW cost of 12×3,8TB and 24×1,6TB shelves + other hw is about the same, logically newer and more dense 3,8TB drives are cheaper per raw TB

• With 3.8TB drives software cost per raw TB is lower, in fact so much lower that even though 12×3,8TB has higher raw capacity, the total software cost is lower than with 24×1,6TB drives, making the total solution with 12×3,8TB drives cheaper than 24×1,6TB solution

Would you then automatically choose the cheaper alternative (12×3,8TB)?

• Maybe not, the answer is typical pre-sales answer, “it depends”
• This is the point where you have to consider performance as well
• If you are looking for the lowest net price for AFF setup, then go with smallest controller AFF8040 and use the cheapest SSD combination, in this case 12×3,8TB SSD drives
• Depending on workload characteristics, you can max out the AFF8040 controllers already with 12×3,8TB drives, so using more costly 24×1,6TB drives with AFF8040 would not give any extra advantage
• If your workload is such that you can get required performance with AFF8040, I would go with 12×3,6TB drives
• But
• With faster controllers like AFF8060 or AFF8080EX and 12×3,8TB SSD drives, the bottleneck might be the SSD disks. So it might be necessary to use 24×1,6TB drives instead to squeeze all available performance out of more powerful controllers, this all depends on workload.
• It also depends on the metric you using for comparison, are you just comparing usable capacity cost ($/GB) or are you comparing performance cost ($/IOPS) or a combination of those?
• Typically with AFF cases performance plays a major role, if that is the case, this is the point where Pre-Sales and performance sizing comes in.

In conclusion, back to the original topic, why is ADPv2 important? Like shown in part 2, With ADPv1 and 12×3,8TB SSD drives one would get so much less capacity with symmetric configuration (19,9TB vs 29,85 TB). While the solution with 12×3,8TB drives is cheaper than solution with 24×1,6TB drives, the price difference is offset by lower usable capacity, making the solution more costly per usable TB with 12×3.8TB drives than 24×1,6 TB drives. APDv2 enables using 12×3,8TB SSD setup, while providing about the same usable capacity as 24×1,6 TB SSD setup and having lower total cost for the solution.

Disclaimer 1: There are no guarantees that pricing will behave like this with different setups or in the future. There are just too many variables. But if you are considering buying AFF setups with 24 SSD drives, it might be a good idea to get a quote with 12xSSD drives which are larger, you might be happily surprised.

Disclaimer 2: Quite often it is not enough to size AFF solutions based solely on capacity, typically AFF solutions are sold for workloads that require constant sub-millisecond latency. In order to hit that goal, a performance sizing is highly recommended. Without even most basic performance sizing, most likely there will be some problems. Either the solution is oversized and you are paying for performance that is never going to be used or the solution is undersized and you will have performance issues and cannot achieve your business goals. Another topic for a future post, pitfalls of performance and performance sizing.

Disclaimer 3: ADPv1/v2 is NOT supported with AFF MetroCluster setups and you will have to use dedicated disks for root aggregates, spares and parity drives. This makes overheads related to root aggregates, spares and parity drives larger when using larger drives. With AFF MetroClusters it might be better idea to build your system with larger number of smaller disks than smaller number of larger disks, maybe a topic for a future blog entry… This problem might be solved partly in the future with shelves with mixed SSDs , where there are some smaller SSD drives for root aggregates and some larger SSD drives for data aggregates.

Thanks for reading 🙂