00:01
All right. Good afternoon. How are you guys doing? Freezing, I know. Did you stop by a swag booth? All right, you should be getting something by the end of the event,
00:19
so yeah. Yeah, there's some really cool swag. I stopped by and I was like, oh, you're, you're a, um, what do you call a staff over here. You're not should be getting it. They pushed me out. Nobody gets it, at least no one from Pure.
00:40
I was like literally pushing myself too much and I was like, get away from here. All right. Uh Let's see people's uh walking in. Thank you very much. So let's get started. Good afternoon, everybody. How many of you actually, um, were there at the Kinos this morning?
01:03
Oh, almost everybody. So you must have heard about the SEA thing. Must be wondering What exactly this is what we're going to talk about. So, before I get into the details about what XA is, um, flash plate XA, I would say, a marketing guy would kill me if I just say XA.
01:22
So he's not here today, by the way, he was my co-presenter. Um. So How many of you are already working on AI right now? Just one? Any more? Nothing? 02. All right. So What you have noticed um in your design
01:44
so far in AI is storage or infrastructure, one of your bottlenecks that you're seeing, the kind of workloads you're running in the AI. Are you basically training or supervised fine tuning? What exactly are you doing? HBC. I searched for. Healthcare. Oh, great.
02:03
Healthcare is one of the regions that are really growing rapidly, and AI is literally augmenting the workload big time. How about you? For a reason, uh, OK, yes, I work mostly with, uh. Oh, fantastic. Those are two verticals that I see a lot of the AI focus happening,
02:25
and this is great. So normally what happen, what do you do in the AI space? Like what kind of architecture are you dealing with that. Mhm. Very. OK. So you probably would be using some form of LLMs, correct?
02:44
For, for your workflows, I guess. And um Checkpointing is OK with you in your existing infrastructure? Are you planning to grow the sizes, particularly in financial and genomics, but is it genomics or is it medical research? OK. All right. So what do you see today and specifically as
03:04
you see in the title. It is all about design to extreme performance. So you start from a concept. If you look at the customer's journey. Specifically in the AI space. There's always a high volume of data, either through a pre-processing stage or during the
03:22
training, testing, and deployment phase. There will be a lot of machine data that you'll be evaluating. Processing, cleaning it up, curating. Before you feed it into a training pipeline. So when you actually set this up, what happens is there will be a diverse pipeline,
03:41
and I say diverse, that means it could be reading a stream of data, it could be doing a high concurrent IO, it could be doing a lot of uh bandwidth, uh sorry, throughput, to a single file or multiple files, large files, which is typical HPC, um, or you'd be doing small images, small files, you could be doing a ton of metadata operation.
04:03
It's a combination of all of these, right? So, there are a set of storage vendors in the market who actually are very successfully are doing a lot of these AI workloads, but they are running into a lot of challenges. Talk about that. So Where exactly, where, how is AI evolving?
04:25
You guys, you know, last year. Everybody was all dancing around rag. Regenerative, augmented generation, right? Augmented generation. Today, a year later. Everybody is going towards MCP context protocol.
04:44
So this is evolving. Now, what is constant is data. This data is being either you already have it in an existing data warehouse, or you're generating more and more. Every time you actually optimize your pipeline, either you go from a data parallelism to a pipeline parallelism,
05:05
depending on how big of your um GPU form is, how many GPUs are throwing at it. It all depends upon the kind of scale that you're actually working in your environment. So First of all, how do you keep your GPUs fed all the time? Because that is the most, that's the, um, I would say the ROI and um DCO works at the same time when you have GPUs are not properly fed.
05:32
And in the long scheme of things, you'll find that there, you're not getting the return of investments for these GPUs that you're actually having, yet, you're paying an upfront cost to get your GPUs in your data center. Right? So that's a big challenge, scalability, um, metadata bottlenecks. That's another thing because when we look into
05:53
a diverse workload, which has got smaller files along with large file, like, for example, traditional and high performance computing. Always dealt with large files, you have multiple writers with a single file or a few large files, and that has been the um DNA of a traditional HPC but traditional HPC is slowly transitioning into an AI augmented workload.
06:15
So, obviously, like you have your CODA libraries, but CUDA libraries can actually start to integrate with the MPIO libraries which were traditionally your HBC libraries, right? So those kind of things always have been happening and more and more workloads and applications are slowly moving in that direction. And then complex management, that's the key
06:35
thing because you have got data scientists working day in day out to develop application, train certain models and try to deploy models to make sure that you have a uh right kind of uh insight for the data that you're having. But if your infrastructure is not stable, it's complicated to manage. Where is the overhead going to eventually land?
06:58
Is it the SRE who is setting it up or eventually the end user like a data scientist actually working on? So they care about data. If the infrastructure itself is not stable enough and it is still complex to manage, that exactly makes makes a big over uh um overhead right there. And the total cost of ownership, that was what I was talking a moment ago,
07:19
the TCO and the ROI they go hand in hand. So you invest a lot of dollars upfront to buy these great GPU servers, now the GB 200s, right? The Nvidia GB 200s, the grace hoppers. Then, If you're not feeding your GPUs in the right way, obviously, you're not getting the ROI that you, for the investment that you have.
07:40
So then, what are the architectures have been traditionally available? If you look into this, you have a lot of storage vendors out there who have been in the HPC space for a long time, Infinipen, Cosics, and all of great stuff, right? And they did solve a part of the problem for HPC that is high bandwidth.
08:02
That is absolutely needed under low latency. RDMA. Those are the factors of the parameters that you normally see in a traditional HBC and this definitely help to solve a particular problem, but just doing right performance, those are the things that you are looking into. But one of the challenges because the AI workforce is now slowly redefining the kind of
08:24
data set that you're going to be having. Which is not just large files, but you also have very small files when you're actually doing multimodal. You're having text space that could be, there would be small files too, but when you're going with multi-modal, which is more and more relevant nowadays, with small images and videos and text files
08:41
altogether. Then you do have a challenge with metadata and there's always going to be a solution from some of the traditional vendors, but they're not easy. They have got a lot of tunables, some lot of management overhead. So those kind of adds more bottlenecks and road roadblocks in your overall manageability,
09:00
right? And then. Have you ever configured a, a storage vendor software on a client? Because that is how they actually communicate because their storage is a bunch of disks, they're not smart enough. So for doing all of that, they actually have an application or a software running on the client
09:22
which actually determines the entire layout of your data that is going to be stored on your data on your storage, uh storage tier. So there is always complexity. What happens there is a new version of that available and you go to patch it. So, you can't do that in your production environment right away.
09:40
You got to test it out somewhere before you roll it out. So those kind of complexity and the overhead actually is a huge challenge, considering the scale in which AI is growing. Then, fast forward, we do have current architectures today. They also solve a part of the problem, like you've got standard protocols,
10:01
like they use Ninipan, they use NFS as a standard protocol, they do. But what are the challenges? Variable performance. They cannot give a predictability of your performance. They cannot be able to give you that, OK, what is my MTTB MTTR the meantime between failures,
10:19
the meantime between data data loss. Is it low? It's high, because if you have a lot of failures in your data in your storage media, you got to be swapping those out. And there is complexity because you do have different layers in that architecture. You need a lot of cabling, which needs to be a lot of maintenance and all of that.
10:37
So that itself is a big overhead there, right there. And then slow performance. So what happens is they give you a very high-speed ride cash. You fill up the cache and what happens to the subsequent rights because you don't have any more space, so you're going to slowly move some of the data out from the cash to give space or
10:58
make space in order to write the, the complete the new rights. So when you start to move data out from your high-speed cash, that is going to slow down your operation. That means you're queuing up your data. So a lot of these challenges are all existing in the current architectures of the storage vendors we're having. So what we decided is to say,
11:20
if you look at this, we wanted to do a scale which is disaggregate. What do you mean by that? When you say disaggregate, it means you have got a metadata, you have got your um um what you call storage notes or the data nodes. So why would you actually create a, a bottleneck in one area?
11:40
Why not just scale. Independently in each of these layers so that you have more granular control over the kind of workload that you're having and the amount of scale that you probably need for the environment. Uh, for example, in our conversation with customers they come back and say, OK, I need the amount of small files and high metadata
11:59
operations, but I don't need that much amount of capacity. So why do you need so much amount of capacity? Because a lot of these traditional storage vendor says, in order to get you this much amount of performance, you need this much amount of capacity. Why would that be? Why don't you have a little more democracy
12:15
towards where you want to have the scale landing? Is it the metadata or you have the data? And then there's a 3rd point. What happens when you have too many GPU servers? Do you need the amount of server performance, or do you need that much amount of capacity for
12:30
that? That is a 3rd tunable that you have. Because if the compute nodes that you have, which are more of a GPU servers, a combination of GPU and CPU, and you have got X and Y number of CPU and GPUs, and you want a certain amount of performance for your read and write operations. We can probably size you in a way where you can actually have a certain amount of data nodes
12:52
and the metadata that is needed for your application, but you can still scale as you still because no hardware cannot say that OK, this is the one particular uh S500 or the flash player that you see on the picture over there is enough for me, but your workload is keeping on growing at a scale of 2 X and 3X every other 6 months. Every hardware has its limits, so we do have to scale out,
13:16
but the scaling out has to be independently done, not to have any dependencies to any other layers that you have in your in in the infrastructure. So we introduced Flashdor. So in the flash X, what we have taken into consideration some design principle. So the design principle I was explaining to have metadata and data scale out independently
13:41
and also have no dependencies on the number of GPU servers that you have in your GPU cloud or in the GPU cluster, right? So that is a 3 tunable that you probably have in there. So what we're trying to say here is, if you have to start small, you can, there is a minimum number of nodes you can probably have in the configuration, you can start small and you can keep on scaling.
14:04
So there is always every hardware has its limits. Keep in mind this this question comes up, you can't say limitless scaling, but the definition of limitless scaling is to add how many number of notes you can to get the performance you live um you, you need, or this, there is a limit to the hardware or there is no limit to the scale that you're looking at.
14:24
So that's the reason why. We call it as a limitless scale because you can actually add as many number of data nodes based on the particular workload that you're looking for, the performance that you're looking for, right? So the elasticity is in two different levels, the metadata and data.
14:40
And then the other thing which I mentioned earlier is predictability. So you would constantly like to feed the GPUs and we should not be having any level of slack time or idle time on the GPUs where they are not at least utilize 100%. So we need to constantly do that. And as I was mentioning, the workloads are changing and evolving rapidly.
15:03
So what happens in that case is you do not know whether it's going to be a uh uh a concurrent read or write operation to a single file or multiple files or small reads and writes with small files with 4K images. So you never know what kind of data you'll be processing during your training model. Yes. Is there a ratio of um Storage notes can be
15:27
managed by notes. Great question. Um, yes, we do have a sizing and I can tell you, um, in a bag of napkin number, um, what we have done is we got about a 1.5 to One ratio, that means the amount of uh initiators of clients to have some amount of data nodes. So we order 50% more in order to then considering the fact that we use the top of the
15:55
line. Um, notes with, uh, it all depends upon your configuration. Let me put it that way. It is a very, uh, a general statement, but I can give you that, yes, we do need more number of notes because we have got plenty of bandwidth we can actually handle on the data nodes.
16:10
But there is a math that we follow depending upon what kind of a node that you are having and the network setting because that part of this entire thing that you see there apart from this S500 of the flash spread that you see in the picture. The rest of the stuff is all OEM based that you can actually get it. Either you use it on your own that you already have in your data center,
16:30
and to repurpose that to use it as an extra config, or you can have new boxes. But it all depends upon the kind of box that you're getting. We have a recommended uh data node, config. But you can obviously use yours. So that is a flexibility we're providing to the customer doesn't have to be bound by what we are recommending.
16:47
But yes, there are some recommendations we have and guidelines for that. vary by the task types like KLP family, is that a certain way of sizing versus multimodal or just image in. Um, no. So that's the, that's the beauty that we do, we, we can't handle any kind of workload on that and it doesn't have to be only for LNM
17:11
versus a multimodal now. We can actually have it all because as I said, it's so evolving, we can be having two separate infrastructure for that. Everything has to be the same. So we want to keep it simple. I have the book right now a big, big re very small.
17:26
Yeah, yeah, exactly, yeah, absolutely. The small files, the metadata or workloads all been handled by the flash because that's the industry. It has been long, uh, we, we have been using the flash plate for high metadata operations for a very, very long time. Is industry tested.
17:42
We have got customers running it in production today, and we have got evidences that we can run and scale metadata operations at a very high level. So that's the reason why we chose to use our metadata engine with a flash plate, existing flash plate today. OK. So, what's the highlight that you see? What, what exactly we're trying to accomplish
18:05
by this architecture? So, these are some numbers that we're throwing up there, but again, those numbers vary depending on the kind of configuration you have on the data nodes, kind of workloads you're running. So the, so these are something our benchmark numbers that we have got as to how much you can
18:19
actually push from a, from an existing uh platform that you have 10 + terabytes per second. So imagine How many of you guys have actually read the meta LLM paper for Llama 3? Anybody? So they have actually given some specifications of how much amount of throughput they need for checkpointing.
18:40
Right, so they're really, really pushed like 5 terabyte to 7 terabyte. And these are mostly parallel checkpointing that they normally do asynchronous and maybe sometimes parallel universal car checkpointing. So there are various different checkpointing they have and they will be pushing about 5 to 7 terabyte of rights.
18:59
So, keeping that in mind when you have XA going to your position and keep in mind EA is not for everyone. Excise for somebody who's doing like AI factories, large volume of GPU clusters, so your GPU um cloud providers. So you got to understand where exactly Xe can actually make a huge difference from a
19:23
performance perspective. For those kind of workloads, which is extremely uh high performance like uh read and write operations, that's where Excel will play in big time. So, there is a read and write in a single name space and how much amount of performance is is per rack is uh 3.4 terabytes, which is I think the performance density is really,
19:44
really uh what do you call um compared to any of our storage vendors out there, I think we're the best at this time. Then greater than 2X files, that's the last number of files under management, highest number of files. So, which is whatever name spaces we're having. Again, I was talking about the flash plates, the metadata.
20:03
We start with a single chassis. And you keep on adding more chassis and go up to 10 of them in a single name space. And then finally, the reduction in stall time. That's the, that's a significant thing because all along this design principle, we've been focusing on one thing, which is very critical to us as a,
20:20
as a design principle at Pure and any of our platforms that we're offering simplicity. So if we want to keep the architecture simple, so that whenever anything that happens, either you grow or shrink a particular size of the architecture, it'd be a lot more easier to do that. So, what's the difference?
20:41
I think we touched upon a lot of this point, but I want to touch upon again. First of all, simplicity that is avoiding complexity, and second, highly concurrent. So this is a very important point because as I was saying, the traditional HPCs always saw a high bandwidth to a single file and there has been
20:59
the case for multiple for many, many years. But what we have recently seen with AI is that you are now going to be writing concurrently to multiple files in a very high file count environment. So concurrency is very, very important. I've been speaking to customers as well, we're trying to do it in DAS, but still I are not unable to scale.
21:18
Well, DAS is not something that you would have the scalability. You got to go to a shared storage where you can actually square scale with the number of GPUs or CPUs that you're running for your AI workloads. You can be using a DAS for it. You could be sitting there for your lab experiments, but you can't put that in your production.
21:36
You can't handle the performance that is needed. Second is improved scalability. I was telling you about the ability of scaling metadata and data nodes separately. That disaggregated, that is very, very important. And metadata capabilities, as was mentioning, S 500s have been an industry tested.
21:55
And we've been pretty confident about how it is going to be managing or handling the high metadata operations, and it's been successfully doing that. Performance bottlenecks. So, in any of these traditional customers of storage vendors who have been using um this multimodal, small and big files, what happens is they end up with the meta metadata bottleneck,
22:15
more, many more than once. So what happens is when they do that, when that happens, they go into a configuration, uh, reset, and a lot of these things which is very challenging, and it is very time consuming and there's a lot of overhead. They do hit those bottlenecks very quickly, the metadata bottlenecks.
22:33
And then finally, futureproofing, that's what I was talking about starts small because we have the ability to and flexible enough to grow and scale as you need. You don't have to have a humongous system sitting in your data center right from the beginning. You can, you don't know how much amount of data you would be needing for storage or even the performance that is required from your storage
22:55
infrastructure. You can always start small and as your workload is evolving, you keep on adding them. And that's the uh capability that we're offering is a flexibility uh not to futureproof it. So this is a graph that we have from our testing we did.
23:13
So we start off with one, data notes all the way to 100, and if you see the orange bars the read, you probably have seen this chart today in the key uh keynotes and uh this chart will give you a little bit of a linearity that you see there. So right from a single node, 25, 50, 75 to 100, you clearly see the read and write, which is completely linear.
23:41
And that's, that's the benefit for this one is that we definitely provide a linear scale. Now, when I get into the architectural details, I'll tell you why and how we are able to do that. But from a performance of the first wave face value if you see here, we literally, the rights are half of the reeds, and it is constantly.
24:01
Growing as you keep on adding the data nodes. So, We have got a very robust portfolio. Just from a scale out perspective, we have got a lot of different platforms, but just to give it a highlight of where exactly you're going to be using what platform, that's very important.
24:28
So if you see here. Obviously, the left part is mostly for repositories and um for raw data that could be for data processing and all of that stuff, supposing you have got a lot of um machine data that has been generated, you want to keep it um uh in a repository, you can possibly use that, but the big thing is the center part where we have our traditional
24:51
flashblate S platform and S500 is one of our flagships which actually provides you the best possible performance with all the enterprise features in it. That's very important because when you're actually setting up an enterprise AI environment, think S 500. That's the easiest one to do. If you're doing something like super supervised
25:14
fine tuning or rag or anything that you already have an existing data warehouse where you're trying to um make a domain specific model and you're training that or uh fine tuning it, then a flash plate should be adequate enough to do it. And then on the right-hand side is where you have the XA. Exercise where you are doing the extreme performance and you're going to be using mostly
25:41
in the AI factories where you have got a large GPU cluster and you definitely do a lot of real-time training at the back end. That is where Excel would be really giving you the benefit and the boost in the performance that you're looking for. So we're trying to cover end to end data requirement.
26:01
And that is the reason why we have got very specific storage platforms designed for each of these particular requirements. So the use cases and the kind of design that you are planning to do for your data center, we will be just trying to size it accordingly to the kind of platform we have. We have all of that available.
26:24
So, let's look into the architecture. This is the architecture diagram. So if you see here closely, I'm gonna touch upon this. So, you have on the left hand side the compute cluster, which is your clients that we're talking about, right? So then, the communication of the clients to this uh metadata servers that you see over here,
26:42
which are technically Flashlate S, which is S500. And today, also in the keynotes, you heard about our SR2, Rev 2. So this S 500 would be using the Rev2. Right? So we are going to be giving the best possible performance for the metadata perspective.
27:02
And then on the bottom side, you have all of these are data nodes and you keep, you keep on stacking them as I said, you can start small and you keep on adding those meta metadata nodes, uh sorry, data nodes as you start to scale the workload. So from a capacity perspective or from a performance perspective, you can actually scale. Like for example, in our scenario,
27:20
we were testing that was 16 SSDs in a single node, one new boxes. Right? You say we don't go over 16 notes to start at 10. For data node. Yeah. So it all depends upon what kind of sizing you would like to do. Because then we can tell you, OK, instead of using what we were supposed to then in 10 boxes,
27:39
you probably need 15 because you're only going with 10 in the SSD in it. So, there is a sizing mechanism that falls in place, give you certain guidance as to how you actually size this entire umXA platform based on the number of metadata as well as data nodes that you have in the cluster. So Um, The communication that happens with the client and the metadata servers is primarily of NFS version 41.
28:08
Now, here's the thing. Once the communication happens and it gives you the information about the data, data that is located the location data layout information to the client, then the clients on the left hand side goes, works uh accesses the data directly. So one thing that has been commonly we've been hearing about the traditional HBC vendors,
28:28
storage vendors, is that, oh, we are actually having infinite band because it is non-blocking. There's no blocking because the internet is always blocking. That's not true anymore. Because Ethernet switches right now, the Nvidia SM 5600s, they are non-blocking. And if you look at this architecture,
28:47
once you pass on this information, the layout information of the client where the data exists, and are you reading or writing. The data actually the clients directly go access the data to the data from the data node. The metadata part is not out of the path of the data path. So there is a direct data path that goes back and forth over RDMA,
29:05
NFS over RDMA. So, RDMA is obviously, you've been hearing that in HBC world is extremely low latency. Yes, we do support NFS over our DMA and is there are taxes. There's no blocking. So that's the beauty of how we are actually generating the power and the, and the boost in performance that you're looking for inXXA
29:29
compared to our standardized platform. Yes, the great question. Uh, not the time of year, but yes, we will be doing that in our future release. So the question was, does access support object store? So today, no, it's file based, but we are looking into the object base in the future.
29:55
Is there a use case that you're exploring with the object? Oh, they actually the competitive the past that really support that. Right, so I just, OK, yes, no, but, uh, apart from the competition, is there any particular workload that you're uh looking for for using object stores, uh, then I, I, OK, it does some.
30:24
OK. So your business is mostly for your service as a service provider you're looking. that has raised, so I just want that. No, uh, yes, the que the question was for objects, so we don't support it during GA run the first release, but we will be um in the future.
30:52
It with the alignant last week that's, that's the word, yeah. think a bit uh the be the best with it. Yeah, yeah. So, um, again, looking for this one, then we, what we see over here is, uh, the entire distribution of what exactly the, on the communication looks like.
31:14
Like if you see here, we are supporting layer 3 BGP. That's very important because in when you're in a uh spine configuration in spine and leaf configuration, you probably need an L3 or BGP communication for the network layer. We are supporting that today with that so. So there are certain the fundamental things we have actually learned uh through our journey of
31:40
exploring the AI HBC space and the workloads that people are actually using and the network configuration, the data store, the data path communication. We have derived as uh learned from those things and we have designed it accordingly. Now, there will be always new bells and whistles will be adding to it in our future versions, but at least for now, we have a out of the box which can handle a lot of this file
32:04
workloads and give you the performance that you need in a very flexible configuration. Right. So, just to look into the data node stack. What you have is a a bunch of Linux boxes. We are testing this as 1 to 2404. So there's a bunch of Linux boxes, which is obviously using your volume manager,
32:29
the rate, the file system and, all the entire stack that you normally have in Linux. So we are not putting anything extra, except you see on the. The orange box on the right hand side, there's a pure demon. That is only for the control plane just to figure out when you're adding data nodes or where do you actually um pass on the information to the metadata to for the layout
32:53
information, all of that stuff that has been communicated that that's all it does. It's mostly for control activities. Other than that, there is nothing on the performance there that is actually being done through that particular demon that is running. So it's like a heartbeat.
33:06
It's providing that information back to the metadata, so. Right? So. All of these optimizations you see there using Spectrum X. So that's something which we have used it. Now, again, we would recommend using a Spectrummax because Nvidia is all has got a lot of enhancements in
33:24
the Ethernet switches right now, the spectrum Spectrummax, but again, it could be Arista, it could be anything else that you could probably have in Cisco switches too. And then the performance tuning is all about the balance between performance and capacity. We do have switches so we can actually, OK, I don't need that performance,
33:40
but I need a lot of capacity. Yeah, we can do that, or vice versa because there will be obviously a hit or uh or, or, or a uh kind of um. Um, uh, they will, uh, the choice that you have to make in order to actually make whether your point of performance or with capacity.
34:03
So the metadata cop, this is what our flash plate has been doing over the years ever since it's conceptual. It can we start to ship this way back in 2017 and we've been extremely successful in the kind of metadata engine and we're extremely proud about it. There's nobody in the industry today actually does the way we handle metadatas,
34:23
specifically small files. Now, even if you look at the standalone flash plate, not DeXA, but the standalone flash plate. The standalone flash but can actually handle small and large files. It may not be doing it in extreme performance like what ICA has been designed to do.
34:38
But is still able to handle small files when I actually go and talk to the HPC customers which are who are actually using other competing uh HPC storages, and I explained them, we actually do small files and large files and you're saying that you don't need any patches, you don't need any other additional configurations set up for actually doing it. No, it's out of the box.
35:01
They are literally surprised to it because maybe I'm, we are, we are pure we're living in this environment for too long, but when we actually reach out to customers and talk to them, they're extremely satisfied with what they hear about what exactly we can do with the standard flashre S.XXA is a next level, it's an extreme performance, right?
35:20
But the very concept of what we've done in our traditional flash blade as. is an extension to that, and we are providing it as the metadata engine is a core engine that we have. And that is built in a chassis model like this, which is 10 blade, and each of these blades are having 4 DFMs, which are flash blade QLC based flash.
35:45
And then you got the front and the back and the back, we have got 8 boats. Um, So that is actively connected. And we're connecting to it, we are supporting 400 gig network connection. So your uplink is going to be a 400 g connection. Uh, to your core network?
36:05
So, we have all of these capabilities already on the plat flash plate platform, which is, which is the metadata core for XA. That And we can actually scale up to 10 chassis in a single name space. So, as you start to, and that's a lot of metadata you'll be processing. Keep in mind. So does it require the, the uh XFM?
36:34
Oh yes, yes. It'll be the similar configuration that you do on a standard flash plate, um, but it is going to be pushing a lot because that's right in this design, we are only doing metadata operations, we're not even doing any of the high throughput uh workloads here. That is very it's been offloading that to the
36:51
data nodes directly. So the IO for chassis4 was the internal. Ter would be, I think it used to be it was 10 gig last I checked the uh the 100 since 1008 and especially 2 budget 2 agreements. But. Yeah. So this is all the hardware announcements we've
37:14
been doing and the newer plates that we are actually shipping, which got announced today that will be giving all high speed of throughput. So actually, that's the, the ref2, um, R2 is what we are going to be shipping with XA. So the core exact, this is a layout, just to give you an idea, to see how these are all connected.
37:36
Um, you can actually have multiple chassis, you go to XFM that you're asking about. We're actually supporting a newer generation XFM 2.1 and then it is all upliing to 400GB. So you literally can actually push a lot of data. Um, through the, through this, and then we were using an SN 5600 for testing, which obviously was 400 gig connection to get the best throughput.
38:06
So, This is a customer model or an example that we would say, where they're talking about a 20 terabyte, uh, with 300 petabyte capacity. And uh we have got a file cell types 50/50, small and large. And you can see how many number of metadata nodes, this is a sizing effort that we have done. Um, a number of data notes that you probably
38:29
need for that. The commercial model I was talking about is you get the flash plate from us for the metadata configuration. And then all your initiators or your clients as well as the data nerves, that is completely under your control on how you would like to say, including the network. So, as I said in the beginning,
38:50
we would have recommendations, but it's completely up to you how you would like to configure this with certain ground rules, basically. You just can't go extremely low, otherwise it doesn't solve the purpose of XSA. Otherwise, an S flash by S could be adequate. But if you need a real throughput that you're looking for.
39:10
There are certain guidelines that we have and best practices that we need to uh follow. Otherwise, the rest of the stuff you can actually do it on your own. We will definitely have, we have a complete installation automation scripts available to configure all your data nodes, add them in the cluster. All of that is automated.
39:28
Um, so there will be a very less manual work that is needed. Um, only thing that you probably will know the need is to connect all your compute nodes, your GPU servers, what you have in your, uh, processing layer, uh, to be connected to the switch, which, which, uh, will be communicating to the flash blood extra. So that's the commercial model for us.
39:50
And later in the year maybe we probably would be introducing something the third line that you have from PO storage offering, which may not be an OEM, but we'll be still keeping the OEM and the PPO storage offering available for our customers. That's all I had. Any questions? I know there was some great questions in our
40:12
presentation, but anything else?
