Episode 412 – Disaggregated ONTAP (aka AFX) – Why Is The Internet Broken?

Justin Parisi: I’m here in the basement of my house and with me today I have some special guests to talk about disaggregated ONTAP. And if you haven’t heard of that, you’ll hear about it here. With us today, we have a Arindam Banjeree, or Ben er Banerjee. Banerjee Banerjee. Banerjee. Man, I suck at this. So Arindam, what do you do here at NetApp and how do I reach you?

Arindam Banerjee: Hey, I’m the VP and technical fellow I drive the product, architecture and vision. I’m the chief architect of ONTAP and behind all of the AI technology vision at NetApp. And the best way to reach me is through you, Justin.

Justin Parisi: Through me. I’m your point of contact. Yes. So, Arindam, we can blame you for anything that goes wrong here today since you’re the chief architect, it all flows uphill.

Jeff Baxter: I thought I was here to get blamed if anything goes wrong with this.

Yeah, so Jeff Baxter VP of Product Marketing here at NetApp. You can always find me on LinkedIn and my role is exactly what it says on the title, right?

I run product marketing for the company and been here a couple decades, much like the other folks on the podcast, and had a variety of roles before that.

Justin Parisi: I think the kids call us old heads. Is that the term they use today? Old heads OGs.

Jeff Baxter: My kids are both teenagers so they use much worse terms than that for me.

Yeah, that’s true. But yeah,

Arindam Banerjee: same. Same here. My kids are teenagers, so

Justin Parisi: Yeah. Yeah. My kid’s almost a teenager, so Yeah, we’re old. So like I said, we’re here to talk about disaggregated ONTAP and this is basically just a way to introduce people to the concept. And as I’ve been digging into it, ’cause I am the disaggregated ONTAP TME.

I’ve kind of realized it’s not a whole lot different than what we’ve been doing, but it is different in a lot of ways. Maybe not ways that are gonna matter to customers outside of management capabilities, but the architecture itself is changing and it’s using the ONTAP you love and know, and it’s just making a few adjustments to future proof it for workloads such as AI/ML that sort of thing.

So Arindam, give me a little bit of the backstory of how this came to be.

Arindam Banerjee: The tech landscape is changing, right? So if you look at the network speeds, they’re doubling almost every year. If you look at the flash speeds today, you could do 12.8 gigs per second with PCI Gen5 NVMe flash, right?

As the CPU clock speeds that have plateaued in a post Moore’ era. So if I have to get maximum performance out of my storage system, I cannot be bottlenecked on the CPU. So we had to now disaggregate the compute from the storage so that I could now aggregate more CPU driving more power to the storage and consolidating more applications on the same storage. In the modern world, this is the only way to get cost effective performance scaling.

Justin Parisi: You mentioned disaggregating compute and storage and it’s not just about adding more compute. It’s the ability to add compute without having to add storage as well. Yes. Right. Or add storage without adding compute. And that’s really, I think, the key beneficiary here because rather than adding an HA pair every time you need compute, now you can just add compute nodes and throw that at the problem versus spending all that money on the extra stuff you may not need.

Arindam Banerjee: But let me ground that with the real customer problem with AI, since we mentioned AI, right? In AI, people need asymmetric scaling of compute and capacity. For example, if you just replace your A100s with the new black fill, right? You need more performance at that time. You add more compute.

However, if the modality of your data sets change, you go to video and audio from text, you need more capacity to store that data. So at that time, you need to scale capacity. The workloads today, especially AI, and also we are seeing with EDA and M&E, they do require asymmetric scaling of the underlying infrastructure. This gives flexibility for the IT admins and the storage admins to really manage it like that.

Justin Parisi: Dr. Baxter, do you concur?

Jeff Baxter: Oh, I do. I mean, I would be like the scrub nurse, I guess. I don’t think I’m worthy of a doctor title, especially with Arindam on, yeah, I think it’s entirely about taking ONTAP in this new and exciting direction.

It’s still ONTAP, and I know Arindam will go into that in more details, right. So the cool part is it’s got all the value we’ve built over the last several decades, but it’s got this new and increased flexibility, and that’s been one of the hallmarks of NetApp, is constantly being able to take the core of what makes it in my opinion, and I think you could say this objectively, the best storage operating system, the best data management operating system out there, and just keep making it flex, right?

Like we added over a decade ago, the ability to start to scale out in the HA pair storage stack based scale out that we have today and now the vision that we’ve put forward is being able to do this full sort of disaggregation and flexibility.

Arindam Banerjee: Justin, can I go back and say disaggregated existed since we introduced NFS. That disaggregated the application from the storage.

Now we are disaggregating storage capacity and storage compute. So we have taught the world NFS. It is all about building the flexibility in the infrastructure, yet carrying forward, as Jeff just said, all the ONTAP systems that we had, all of the SnapMirror derivatives, all of our security features, all of our QOS, all of our data management, multi-tenancy along with it, and giving it the same API surface so that all our customers who have coded around those APIs or have automated around those APIs can still leverage their ONTAP, but with more performance, better density, and better rack efficiency.

Justin Parisi: So the performance comes from the extra compute for for one. Mm-hmm. But it also comes from some ways we do things within the software stack.

So could you give me an idea of where those performance gains take place?

Arindam Banerjee: So let me talk about the writes, for example. We had aggregates in the past and that siloed our storage. Now we have disaggregated. What that means is we now have one big capacity pool, one big storage pool.

So it allows us to get the maximum contiguous free blocks when we are writing. What that does is it reduces write amplification at the backend. It also elongates the lifespan of a disk or the SSDs. But let’s talk about performance first. It gives us better write performance because the write amp that the backend reduces.

And then we have all of the RDMA capabilities and the additional caching capabilities that disaggregated gives us with inode caching across multiple nodes. So our reads definitely improve in this new world as well. And the good thing is because we have built it on a very scalable extent based file system underneath it is very, very linear. We have seen performance increase linearly as you add more and more nodes.

Justin Parisi: So when talking about performance, there’s really a few things you have to consider. There’s latency, there’s operations per second, and there’s throughput. Mm-hmm. So when you say performance is better, what does that exactly mean?

Does it mean lower latency? Does it mean higher throughput? Does it mean more operations or all the above?

Arindam Banerjee: I would say definitely more operations and more throughput. That’s what the world of AI requires. You need absolutely more throughput. In terms of latency, we have not added any latency because of disaggregation, because of the RDMA frameworks or the RDMA technology we are using over high bandwidth ethernet, a data block on the storage enclosure is about 10 microseconds from the controllers. It’s a wash when you are looking at application latencies, so the applications would not see any bump in latency because we have disaggregated. On the other hand, you would see because of the additional compute, the queue depth on some of the hosts reduce and they might actually benefit from it in terms of latency as well.

Justin Parisi: Okay, so I know that in current ONTAP we have some limitations with slot tables and the ability to throw a certain number of operations over a single TCP connection. Does disaggregated ONTAP with extra compute nodes address any of that, or is that still kind of something you have to address from the client side?

Arindam Banerjee: Well, from the client side we have nconnect. We can take connections and aggregate them together so you get the full client bandwidth. We also are now actively promoting PNFS with this new architecture that even a single file can be accessed from the clients through multiple nodes.

So you scale a single file performance as well. This is some of the challenges we have had in the past, but we are past that because of the single file performance increase with PNFS and today with this architecture, you can now have our multi-part capability that we introduced with FlexGroup.

We can take that combined with nconnect, publish file segments accessible through different nodes and scale single file performance.

Justin Parisi: That’s really the key beneficiary for AI workloads because when you’re doing a training model, your file performance is really gonna be the key.

EDA workloads too, in some cases. I think was it backend workloads where you have generally larger files as opposed to high metadata? Mm-hmm. So those workloads really benefit from this as well. What other possibilities can you see with workloads being opened up here?

Arindam Banerjee: We could definitely see more metadata sensitive workloads gaining.

What we have also introduced with disaggregated ONTAP is the addition of an out of band metadata engine. What that enables us to do is take all of your file system walks that you do for data discovery out of band from the protocol path. So the protocol path now is decongested for in-band IO operations only. Take for example, an AI workload. You would have a lot of ingests from time to time. That would create files. That would create directories. These are metadata operations. Just because I remove those directory walks for data discovery out of band. These in-band operations now get the benefit of that.

Several of our customers have told us that 30 to 35% of their ops are actually this complex ls and find operations that come to us through the NFS protocol path. All of that is now out of band. So metadata sensitive operations in AI, EDA, and M&E would see benefits.

Justin Parisi: So I guess this is as good a time as any to kind of go over, we forgot to do this disclaimer at the start.

Jeff Baxter: Oh yeah, yeah, exactly.

Justin Parisi: ’cause that particular thing is disclaimer-ized, right? ’cause I don’t think it’s gonna be in the initial launch of this, but Jeff, please…

Jeff Baxter: So the interesting thing for me is that Arindam always talks in the present tense about this because he lives in the future, right?

This is the cool part about being a technical fellow and being the Chief Architect of ONTAP. And I think the one thing we can say, and Arindam you can back me up on this, is, this is not vaporware. This is actually working in the lab, right? This is working code that you guys have today. He’s nodding for those of you on the audio broadcast only. So it’s not vapor, it is working. What we’ve said publicly is we announced our vision for this at NetApp Insight last year in September. We’ve said by the end of this calendar year we wanna have this in customer’s data centers. And I think we’re very well on track to do that.

And the legal team won’t give me an amateur lawyer badge. I keep asking, but they keep saying I need like a law degree or something, which I think is discriminatory. But law law degree. I mean, I’ve watched so many episodes of Law and Order. I think I should be able to test in, but I will say from that sort of disclaimer, right, things are subject to change. It doesn’t ship until it actually ships. And all of that sort of jazz. But we’ve been very, I think, open about what this vision is. And Arindam is being very open about some of the technical details here, because this is not vaporware, this is not anything like that.

This is very much the direction that NetApp is going with working code today, and Arindam and his team are hard at work on making sure it’s worthy of the quality of ONTAP of being shipped. And that’s always the fun part, right? So,

Justin Parisi: Yeah. And I don’t want Arindam to stop telling us good things.

I just wanna make sure. No, no, no. Everybody knows. Yeah, yeah, yeah. Everybody knows.

Jeff Baxter: No, now he’s covered. So my entire job here on this podcast is to be the one who gets fired. Because that we can survive as a company. We need Arindam. And that’s right. And smart people doing stuff right.

Justin Parisi: Exactly.

So, Arindam, intelligent data is the current ONTAP or NetApp theme, and I guess really what that means it’s an intelligent data architecture.

Arindam Banerjee: It is an intelligent data architecture. And you could do a lot more things you could not do before. For example, things like vol move within a cluster for people who have used ONTAP for years, you have used vol move to do capacity management.

Now, vol move doesn’t have to move any data because all of the data is shared. Vol move is just a volume ownership move. It’s a pointer change for us, so it’s instantaneous.

Justin Parisi: That’s not even a capacity play anymore, right? Capacity is all handled at a pool. Yes. Now vol move is more of a performance play.

For instance, if I have a storage failover and I have an HA pair that now owns all the volumes for that previous node, I don’t need to keep ’em there. Yes, I can move them and distribute them across the cluster. In fact, I believe ONTAP does that for you, right?

Arindam Banerjee: ONTAP does that for you. The volume ownership is now going to be distributed even on a node failure.

We will load balance the volume because it’s just a pointer move for us. We will load balance the volumes across the surviving nodes in the cluster, so you get auto load balancing as well with this architecture.

Justin Parisi: Absolutely. I like to call it a zero gravity volume move.

Arindam Banerjee: I love that. I love that, term.

That is why we have you and Jeff, you can bring up terms I can’t even think of

Justin Parisi: No, Jeff’s a no over there.

Jeff Baxter: I just, I can’t believe you branded something without extensive review and millions of dollars spent on a branding agency. This is, this is unprecedented.

Justin Parisi: I am low cost, low effort branding.

Jeff Baxter: There you go.

I like it. I like it. Disaggregated branding,

Justin Parisi: Guerilla branding is what they call it. So this volume move is able to do that across multiple nodes. However, I did mention the term HA pair, which is still a thing for now. So. Tell me about the HA pair architecture and how that storage failover is handled for now, but don’t get too far into the future because Jeff’s getting kind of cringey over there.

Jeff Baxter: You even did that for now. Like too much. Justin, pull it back. It’s too much. Pull it back for now. There you go. Yeah.

Arindam Banerjee: For now we will still have increments of HA pairs when we add performance. And when a node fails, we will take it as a two step operation. The first step is the node fails over all of its contents or all of its volumes to the HA partner for a split few seconds because our NV log is there.

But very soon we realize if that failed node hasn’t come up, we will now redistribute all the volumes across all the surviving nodes in the cluster. So it’s a two step process for now. Won’t be like this for too long. Okay. Because we have the ability to do this automatic load balancing. So when you are sizing our systems with this current architecture, you can size it much more aggressively because we always will do this load balancing whenever something fails.

Justin Parisi: It really takes away that whole 50% rule that we used to have, right? So, HA pairs, we’d say, don’t do more than 50% per node because you might have a failover. And really, that’s a big cost for a maybe, right? In this case, you don’t have to worry about that anymore. You can now saturate your nodes the way you want to, the way you should, because they are now able to distribute across multiple nodes in the cluster.

Arindam Banerjee: And this allows you to consolidate more workloads, more performance on the same cluster than previously.

Jeff Baxter: So one thing I like about this is this just kind of emphasizes being able to use all the goodness of ONTAP and being able to do things in a stage wise manner, right?

So any sort of failover sounds easy, right? But we know especially the more scaled out and the more disaggregated your cluster gets, the more dangerous rolling failures or some sort of complete cluster failure get, and so being able to leverage these decades proven technologies? We always joke five years is the minimum for storage OS to at least have the rough edges sanded off, right? Because some of this sort of stuff are literal black swan events that you only run into if you’ve actually been running x number of hours in the real world.

And so all of these rough edges keep getting sanded off of basic mechanics like HA failover. And so now, because it’s a two step process, that first step is a gold standard of being able to make sure that the workloads even come up and to be able to handle failure conditions there. And then from there you can take the next step of optimizing the performance and moving things non-disruptively.

And again, I’m gonna have to change my terminology ’cause it’s not even moving things in terms of moving the data. Right. Just reassigning the volume ownership across the cluster, which is a deterministically much shorter period of time to do, as opposed to actually having to move terabytes or petabytes of data. I love the way engineering is stepwised into this to be able to assure the quality as we move into the new era.

Justin Parisi: Yeah, I liken it more towards if you think about NFS and the operating systems and Linux, you run a CP command that’s gonna copy data. If you run an mv command in the same file system, that’s just gonna redirect pointers.

Essentially that’s what we’re doing with the volume moves is running an mv command in the same file system. Yes. So one area, I know that ONTAP 9 or classic ONTAP, whatever you wanna call it would struggle is with deletions. So does disaggregated do anything for that with the deletions of data?

Arindam Banerjee: You’re talking of deletions of files?

Justin Parisi: Deletions of files, or large directories. Like EDA workflows usually have a scenario where they have to delete a ton of things at once, which is why we came up with a large directory delete feature. What does disaggregated do for that, if anything?

Arindam Banerjee: So remember I talked about the metadata capability that we have added. Mm-hmm. Without going too much into the future.

Justin Parisi: For now..

Arindam Banerjee: For now, but think of this. If you are operating in a multi-tenant environment, somebody is deleting, somebody is browsing the files, figuring out what I need to delete, and all of them are happening in parallel.

Justin Parisi: Mm-hmm.

Arindam Banerjee: Think of the fact that I have taken that browsing out of band. So the deletions that are happening in band go much faster with this disaggregated architecture.

Justin Parisi: I know a lot of other storage vendors out there that have a similar concept to this.

Some of them might even go as far to say that we’re not true disaggregated. How do you combat that sort of stance, because I mean, everybody does that. I’ve seen it for years with storage industries. Like, oh, well that’s not really performance, or, oh, that’s not really HCI. Right? So what do you say to that sort of messaging?

Arindam Banerjee: Well, I would let Jeff talk about that first because he would talk it about it in a much more fluent way than I do because he knows how to do that.

Justin Parisi: He knows how to spin it. He’s a lawyer. Oh, man. Spin it for us, Jeff.

Jeff Baxter: All that I’ll say about that is the refuge of not having a good answer is throwing stones. So, if your answer to the number one storage operating system in the world being able to move into the world of disaggregated is to say things like, well, it’s not real disaggregated. That tells me you don’t have an answer, first of all, right? Like that’s just vendors throwing fud because they’re scared to death because, lemme put it this way. At every introduction of a new technology layer, there are new startups and new people that come out who assume that that new technology or that new concept is a license to create an entirely new architecture, entirely new stack, and an entirely new set of vendors. 10 years ago, something like that.

I got a call from a recruiter saying, we want you to come join this company. They’re gonna be the biggest storage in the world because they’re using this brand new technology called NVME over fabrics. I’m sitting there going, we’re gonna release that in like a month or so. Like that’s not a reason to exist and sure enough you got all this FUD being thrown around there.

So it’s the same sort of thing with disaggregated. I’ll let Arindam talk about the architecture, but fundamentally, if you’ve achieved the ability to scale compute and storage independently, if you’ve achieved the ability to rebalance workloads you know, with zero gravity moves to use someone’s term there, good, good.

Right? If you’ve achieved all that, the ability to, at a fundamental level. Just buy additional storage shelves and add them in and have them addressable by entire cluster, it’s disaggregated, right? If you’ve achieved the ability to have metadata operations out of demand, it’s disaggregated, right?

But what they’re all so panicked and afraid of is we haven’t lost all of the cool data management features and having to do that, which is the reason that they’re already starting to throw stones and it’s gonna turn to a hailstorm of stones at some point, ’cause people are desperately afraid of us being able to do this.

Justin Parisi: Yeah, I mean you really have to think about it in terms of results. Customers don’t care about the terminology. In most cases. They don’t care if they’ve got a disaggregated architecture or an HCI architecture because they just want it to work. They want it to be good. You know, and I’ve seen this with other vendors, they perform better in some cases than us because they put things next to each other in the stack, and that’s naturally gonna perform better than going over a network.

And that’s okay. That doesn’t mean it’s not real. It’s real to the customers. So if your results are real, the product is real.

Arindam Banerjee: And if I can add to what Jeff said, ever since we announced disaggregation at Insight last year, how many of our competitors have used the word disaggregation in several of their forthcoming releases?

Right. That’s been the word they have latched on to. So, hey, we have got the technology. We have got the flexibility right now. We’ve got the features, we have got multi-tenancy. And ever since we have talked about this to a lot of our customers, especially the service providers, they love it.

You know, a lot of our file customers saying, I will run everything on it, right? Because it’s just so flexible, just so scalable for us.

Jeff Baxter: Can I mention one thing, Justin, because you said something interesting a minute or two ago where you talked about the classic ONTAP or whatever.

And so there’s something interesting ’cause we keep talking about disaggregated ONTAP almost as though it’s like a brand term or whatever. So I’ll tell people upfront, there’s not gonna be a separate name for this, because it is ONTAP. Right. I’ll touch the third rail here.

15 years ago, whatever it was, we came out with cluster mode and we had ONTAP 7-Mode, we had ONTAP cluster mode. Underneath the covers, they were essentially different OSes. And I think we can admit that at this point. And so there were changes in APIs, there were changes in how you operated.

There were changes in just basic stuff like the commands. That is not what’s happening here. The way ONTAP operates today is different depending upon its deployment modality. So the way ONTAP operates as one of our newer ASA systems, which has a single shared aggregate between the HA pair versus the way ONTAP operates when it’s in a FAS system versus the way ONTAP operates when it’s an AFF system, ONTAP adapts to the environment in which it’s placed, but it’s all fundamentally the same underlying code.

And that’s the cool thing about disaggregated ONTAP is it’s not some new version number of ONTAP. It’s not some new brand name of ONTAP. It’s not gonna be called disaggregated ONTAP as a brand name. People are asking me, what’s it gonna be called, Jeff? ONTAP. That’s what it’s gonna be called. And then you will be able to deploy ONTAP in a disaggregated fashion. And so that to me is the coolest part, is that we’re not gonna have this big transition. We’re not gonna have people having to make hard choices. Just because we’ll have ONTAP at disaggregated mode doesn’t mean that the classical HA pair architecture goes away.

And in fact, for places where customers are just running a two node architecture, adding disaggregation stack, adding networking, adding all that sort of stuff to do it is just inefficient, right? So being able to deploy ONTAP so that it literally operates in the cloud, it operates as software defined. It operates on a simple two node ASA system or being able to be at this massive scale that Disaggregated ONTAP allows us to do is the flexibility of ONTAP.

Arindam Banerjee: And let me add it, is interoperable with all existing ONTAP deployments in terms of SnapMirror capabilities, in terms of SVM migrate capabilities, all of that works right from the get go.

Justin Parisi: Yeah, there’s no more of this you’re gonna have to copy all your files over an NFS network, right?

You wanna move your ONTAP system to disaggregated, then you SnapMirror it. You SVM migrate it. There isn’t this giant albatross that’s hanging over your head and really I think that’s important to mention here. ’cause there is still that contingency of people where they remember that transition from 7-Mode to CDOT.

And I guarantee you there will be storage vendors that bring that up because they’re gonna be like, oh, well remember that? It’s a lift and shift. It’s not. You can’t upgrade in place, of course, but you can migrate your data with the standard ONTAP tools and we’re not gonna force you to do this.

Like, I remember 7-Mode to CDOT. I was like, you have to do this. Like we can’t. And, and, and when we did it, and I’ll be frank, it was a Frankenstein system, right? We took Spinnaker code and we kind of combined it with ONTAP code for a while there, and then we rewrote it for ONTAP nine to make it much better.

But for a while there things were rough and people remember that, but this is not that particular situation.

Jeff Baxter: Yep. Yeah. That’s why I said let’s just rip off the bandaid. I mean, that was 10, 15 years ago. Right? So, it’s been a long time. But I think you’re right. For those of us who have gray beards or would have them, memories are long and people will use that as FUD, but this is decidedly a different situation. This is ONTAP, and some of the magic that Arindam and team have been able to do is really take that dblade layer, take the way that the storage, building blocks that the fundamentals operate in terms of spreading it across all of the shelves, but keep all the magic because they’re not having to recode. This isn’t a fork in the sense of having to write entirely different stacks for each API call. You don’t have to replicate the wheel if we come out with some new Snap flex gadget in the future, it doesn’t have to be coded three or four different times. It just has to be coded once, ’cause it’s still ONTAP and then it runs on-prem and disaggregated, non disaggregated runs in the cloud. That’s the cool value prop and it’s completely unchanged here and in fact, it’s enhanced by the introduction of disaggregated ONTAP.

Arindam Banerjee: Absolutely.

Justin Parisi: I think a more accurate comparison than the 7-Mode to CDOT is when we released the AFF, because what we did there was, rather than writing an entire new storage OS, we said, wait a minute, ONTAP and WAFL, that’s what we use. It just turns out that ONTAP and WAFL do really well when you put it into a flash system. And I think that’s more of a comparison that you look at when you talk about ONTAP versus disaggregated ONTAP.

Arindam Banerjee: It is still ONTAP, it is still WAFL by the way.

Justin Parisi: Still WAFL. No changes to WAFL. It’s all the same. Like I’ve been trying to find these differences and they’re really hard to find.

The biggest difference, as we’ve mentioned, is the de aggregation. Yes. The removal of the data silos. And that’s one of those welcome removals because. Those were a hindrance to doing true scale out in the storage environment. And now that we’ve removed those, we can start to be more creative with how we handle these disaggregated architectures.

Arindam Banerjee: Absolutely.

Justin Parisi: So I guess there was an A1K system that got announced last spring. Can you kind of talk about how that ties in to the disaggregated piece here? Why that platform might be important?

Arindam Banerjee: That is one of our high-end modular platforms and disaggregation will work with modular platforms. That gives us the performance for ai. And that gives us the scaling we need for AI specifically as we have to look at model training, inferencing, and RAG workloads.

Jeff Baxter: Yeah, I would add to that. Every time we do a new generation of hardware, we always have the internal modular versus integrated debates. It’s the time old religious argument because every time we swing too far to the modular side, because it does allow flexibility and you don’t have drives within the controller, so it’s easier to refresh the controller, all those sort of things.

Then people push back and they say yes, but integrated is so easy. It’s just one unit, especially for smaller customers. There’s no additional networking, there’s no anything like that. So you swing that way. What we did with this last launch that I love is we have best of breed for both modular and integrated.

And then obviously if you’re going into a disaggregated architecture, you don’t wanna strand capacity within the controllers, you want to have it out on the networked storage shelf layer. So that’s why things like the A1K will be the blueprint for the hardware that we release this on. I don’t want to give people the impression that if they buy an AFF A1K today, they can do an inplace upgrade. I know you already mentioned that before, Justin, but we always try to be really honest with our customers, right? So we don’t want to put that idea in folks’ head.

Justin Parisi: So there’s also some improvements with how we handle workloads with these systems. So Arindam, talk to me about how these newer platforms are better at, say, single file processing or, threading out things better across CPU affinities.

Arindam Banerjee: Well, this comes with a lot of CPU. That allows us to scale not only up as well as out.

This also comes with what we call a QAT offload engine that allows us to preserve efficiency with performance. So efficiency is always on, and the additional compute horsepower in this controllers have allowed us to even evolve our scheduler where we can now dynamically leverage based on the workload, the number of compute cores we have to throw at a particular problem.

So you’ll see a lot more flexibility how we scale up to workloads with this controllers, and now with the flexibility of the disaggregated scale out architecture.

Justin Parisi: So we’ve mentioned a lot about data and movement. We haven’t really touched on protocols here, and I think it’s important to point out that the disaggregated ONTAP that we’re talking about is NAS and Object only, right? No block there. So talk to me about the differences between what we’re doing with the Block platform versus this NAS platform.

Arindam Banerjee: Well, we launched ASA some time back, and the block platform also runs some of the existing ONTAP code that you will see in this aggregated ONTAP as well.

Some of the work we have done to dis-aggregate or eliminate the aggregate is also visible on our new ASA platform. So you do not have to manage storage silos. if you are a block customer, you just create a LUN and you are done.

Justin Parisi: LUN and you’re done. Or an NVA namespace, it doesn’t rhyme as well.

Arindam Banerjee: Yes. Yeah. NVMe doesn’t rhyme as well. Yes, I’ve thought about that, but I said I lose the LUN, because it’s…

Justin Parisi: I do like LUN and done, we’re getting into March Madness season, where you got the one and done NCAA tournament stuff. So “LUN and done” works great. NVMe namespace and done. Not so great.

Jeff Baxter: Not, not so much.

No. But it does work great over Carrier pigeon.

Justin Parisi: It does, does, yeah.

Jeff Baxter: For April Fools, I keep wanting to put out a press release about NVME over carrier pigeon, but legal and PR don’t really like that. I would say I think we have sort of a best of both worlds environment where we acknowledge that we have the best unified OS today in the game and the best storage hardware to do that, which is AFF and FAS, where you get unified block/file/objects. So that exists today. You can scale that out today, and have been able to for decades. And now for really targeted block optimized workloads, we have the ASA, that is, as Arindam says share some of the same DNA.

In fact, if you did the evolutionary tree, it’s somewhere on the evolutionary tree with disaggregated ONTAP, because it disaggregates the single aggregate makes it available to both nodes. All that value is in there for block optimized. And then the reality is the workloads that are most likely to benefit from disaggregation, the benefits that are gonna be at this large scale that are gonna take advantage of more than two nodes worth of compute performance more than the scale of a single node in terms of the backend scaling, those are unstructured workloads, right? They just are. And so the reality is you’re gonna look at your AI workloads predominantly, and then things like EDA, M&E and others like that, and they’re, by definition unstructured workloads.

They’re by definition, accessed over file-based protocols. So it’s not so much a limitation as adapting to what workloads are gonna make sense. If all you’re doing is shoveling LUNs out the front end to run an extremely high performance Oracle database. Then, you wanna be on ASA, you don’t need the added layers of disaggregation, all the other sort of stuff because, at the fundamental layer, you’re just gonna be going to a single controller anyways, right? And so that’s where I kind of place it.

Arindam Banerjee: Yeah. And one important feature as we do disaggregation is duality. You talked about file and object, Justin. Especially in the AI workloads, if you’re fitting into the AI data pipelines, there are applications who are ingesting as files, and then at a later part in the pipeline, you are reading them as objects.

So duality is one of the key features that we have, and that carries forward with disaggregated ONTAP, as with everything.

Justin Parisi: Yeah. Let me drill down that a little more, when you say duality, now I’m no longer having to move data for volume moves. I’m no longer having to move data for exposing to object. I don’t have to do anything other than just set out a share and and I’m done. Or a bucket for S3 and I’m done. And that’s the benefit here. I can have a single platform that not only performs at a high level, but they can also do everything I need it to do without needing to make changes to my APIs, without changes to my applications. And then when you start to factor in the metadata engines, the ability to handle RAG workloads a bit better, it really becomes a full overall solution.

Arindam Banerjee: Absolutely.

Jeff Baxter: It really is the zero gravity as you said, or the zero data movement and it carries through the stack. Zero data movement when you have some sort of disaster and you need to do some sort of failover operation. Zero data movement if you want to access data via S3 or NFS.

You don’t have to refactor your data, you don’t have to do anything like that. I know in this podcast we’re focused primarily on the disaggregated ONTAP level, and there’ll be follow on podcasts to talk more about what we’re doing with AI, and putting some of those data engines in.

But, you can see some of that vision we already talked about at Insight. And a large part of that vision is stopping data from having to be moved around seven different times to achieve an AI workload. So this notion of the data remaining in place because it has gravity in being able to be accessed in multiple different ways, being able to be reformulated in multiple different ways without having to move it. Because when we start talking about petascale and exascale, no matter how fast bandwidth is getting, it’s not keeping pace with being able to move and you cannot wait two days for your data set to move somewhere. It’s not gonna scale properly and you can’t wait three or four days to have a vector database updated or move it around seven different times or anything like that. All of the awesome stuff, if I’m gushing over this, I’m really impressed by what Arindam and team have put together and are gonna be releasing here because it’s gonna really change the game in terms of data gravity.

Justin Parisi: For a while, people were trying to solve the gravity problem by defeating gravity. Really the answer is just use gravity to its advantages, right? The data’s not gonna move easily. Why don’t we move where we’re pointing the data to?

Jeff Baxter: Is this where you cut define gravity in as a theme song, or do we get sued for doing that?

Justin Parisi: I, we can, you know, honestly, I think we should call this ONTAP zero.

Jeff Baxter: Call it Coke Zero. Okay. Thats it. You’re getting No, we’re cutting you off. Fired. Am I fired? We’re cutting you off on the branding machine right now. Justin ONTAP, you’ve gone a step too far. Zero calorie ONTAP! Somewhere A lawyer in Atlanta is waking up and going.

I sense a disturbance in the force. Yeah, exactly right. So, okay.

Justin Parisi: Okay. We’ll we’ll kill the ONTAP zero idea. We won’t use that anywhere. That’s fine. It’s stricken from the record here. Thanks for stopping by and talking to us about disaggregated ONTAP. If you wanna reach Arindam or Jeff reach out to me, I’m kind of like their gatekeeper. So just email me my last [email protected], if you wanna reach out and we’ll answer whatever questions we’re allowed to answer.

Naturally. We can’t answer everything. There are lots of cool things that are coming with disaggregated that we haven’t talked about here that we will talk about in the future. But for now, this is what you’re getting. You get what you get. You don’t throw a fit. So, yeah thanks again.

Like, and subscribe, leave comments. Be sure to check out our other channels like NetApp ONAIR. Nick Howell does a great job with that. So yeah, thanks again Arindam and Jeff.