#Rant: A, C, FAS constraints

1 messages · Page 1 of 1 (latest)

dire totem
#

I get that someone put a lot of effort into making NetApp "products" easier to size and buy and that there are some actual advantages to having heads and software targeted use single disk types, but this feels like the old "R" and "F" days.
For medium-sized customers that have a more evolutionary path with FAS systems, the split in the SLC/QLC vs. controller compatibility is frustrating. Fork-lift upgrades are not economical and while I'd gladly dump FSAS for QLC, I want to keep using the millions invested in SLC disks.
The beauty of NetApp always used to be (with the exception of the R series) that disks and controllers could have relatively separate life cycles and that gave everyone flexibility to scale the one or the other along the way. Generally, the constraints on QLC compatibility are most annoying, but the hard A vs. C split is there too, and I don't yet know what the new FAS systems will support, but I'm a bit frustrated by the choices I currently have.
</end_rant>

pliant cape
#

While I agree you can still manage all A-Series, C-Series and FAS nodes in one big cluster. (ASA excluded)

dire totem
#

I haven't dug into the controller constraints for MCC yet, they used to be "same controllers per site", but this adds to the complexity perhaps as well

proud belfry
#

You understand that in the A/C series, ONTAP essentially bypasses thousands of lines of code for spinning disk? SSD can attach to fas. You can certainly have a mixed fas with SSD and the SSD can be an aggregate or part of a hybrid aggregate. They are just slower.

I have not heard they in’s and out’s of exactly why the split for A/C series but it likely along the same line as code optimization. When the unit boots it dictates what it is and ONTAP sees that and uses optimized code paths based on what the unit is programmed to be

dire totem
#

I believe I touched on that in my original post. But if I can (and do) have SLC SSD and HDD+Flash-Cache on FAS now (even as sub-optimal as that may be), why exclude QLC? Why can't A-series take both QLC and SLC? Why isn't there a "B-Series"?

hard jewel
dire totem
#

if it was for the same price as one cluster pair with QLC and SLC, that might be an argument

#

and in this case, it has to be MCC

dire totem
north imp
#

When the unit boots it dictates what it is and ONTAP sees that and uses optimized code paths based on what the unit is programmed to be

it wouldn't be that hard to dynamically check on boot what types of devices are attached, and reconfigure the system accordingly. If QLC are attached -> boot in C-Series personality, if TLC are attached, boot in A-Series personality, and in all other configs boot in FAS personality.
I'm pretty sure the reason it was done with a bootarg, and with a non-changeable one, is purely marketing reasons...

pliant cape
# dire totem I believe I touched on that in my original post. But if I can (and do) have SLC ...

They didn't exclude QLC from FAS they excluded all NVMe-based SSD storage from FAS. While you can attached TLC-based SAS-shelves you can't attach any NVMe-shelves (either TLC or QLC).

For your second question: I guess it was for the same reason why NetApp initially named their first QLC-SSD storage system FAS 500f and not AFF. Because they feared allowing "inferior" SSDs into the almighty fast AFF-brand might cause confusion (that's what I heard at least). Some customers might say "I bought an AFF and it so slow, I get no sub-ms latency" while not understanding they bought QLC-SSDs. Separating it into A- and C-Series was the better move imo.
But yes, marketing most definitely had a say in this decision.

hard jewel
hard jewel
fast crater
#

QLC and SLC have different performance profiles. That's why you don't see them mixed.

#

It's not noticeable in most cases, but on edge cases it is.

#

That might be why, but I don't want to have that be the official stance, just my personal observation. I see I'm the only employee responding and I don't feel qualified to answer this.

pliant cape
proud belfry
proud belfry
dire totem
#

i simply want to move from large capacity FSAS to large capacity SSD while not losing the SLC SSD's I have, and if HDD and SSD works well enough on FAS, then I'll be happy to take the hit with mixing TLC/QLC and SLC drives on one controller (and, of course, never in a single aggregate, but I think the available sizes make this mostly a non-starter anyway)

#

it would seem that the code should at some point be optimized for the base disk on each aggregate and not one optimization "personality" per controller, even if that is a lot of refacturing.

#

i'm not trying to take anyting away from anyone else who needs top end, ASA functionality or anything. There's just a gaping hole here that I'd love to see filled.

north imp
proud belfry
#

But that is a specific supported scenario. You cannot just take a field deployed FAS unit and convert it.

empty pagoda
#

Very valuable discussion, I learned quite a few things👍

fast crater
#

Talk to the account team and see what they can offer. Maybe you could get a fPVR.

dire totem
mint fog
#

I've submitted a Future Enhancement PVR for support for QLC on future FAS systems. Current ones do not support the NS224 NVMe shelves.

cyan mantle
#

This is a very complicated discussion as it becomes one of product management, sales reporting requirements, and not one of only technical capability unfortunately.