 All right. Awesome. Thanks for the overview. That was excellent, Josh. I always learn new stuff even when I'm seeing the, like, refreshers and things. What I'm going to go over today is some tools that will help you design new CEP clusters. So it's tools that we developed at OS Nexus to help customers and our partners and our solution engineering team come up with new designs for customers. And so the big challenge that we had for so long was we were burning a lot of time building solution proposals for customers and then just a small change like changing the hard drive from a 16 terabyte to an 18 terabyte size would completely change the whole design in the cluster because now you need to maybe reduce the number of nodes or adjust the RAM or all kinds of different things can change with just small adjustments to a cluster design. And so we came up with this design tool back in 2018 and then have been just steadily adding various improvements to it and a lot of hardware to it. And so today I'm going to go show you how to use the design tool, where to go find it online, and then just do some general Q&A on it. It's an evolving utility. We're going to do a blog article with CEPIO to get it out there onto the main site here soon. But if you have any input, my email address is on the last slide, please feel free to send me some suggestions or if there's some additional hardware that you'd like incorporated, just send me an email. We can get that added as well. So the initial part of coming up with a new cluster design is you've got to decide what are you going to design it for, you know, because if you're going to design it for block storage with triple replica and all flash, you're going to design it in a completely different way if you're using it versus using it for like a large object storage archive. So once you have your use case and the usable capacity that you need to design for, you can go right to the design utility and get started. And so I'm going to go through like a design process of making a six petabyte object storage cluster, you know, with around 20% compression expected and using the design tool. So that's actually all the slides. I'm just going to now cut over to the design utility and we'll kind of do the rest from there. So and this is accessible again through just that that address at the beginning. I'll bring that up at the end, but we've got a little link that'll take you to the site, which is link.osnexus.com slash CEP, but we'll work on getting it on the main CEP IO site. I'm going to zoom in a little bit so it's a little easier to see. And basically everything that you change in the design goes into this URL up at the top. So as you go and change the design, if you need to send the design to somebody, all you have to do is take the URL at the top, copy and paste that in your email, and then you can suggest the design. They can make changes and then send a URL back to you. So there's nothing that you have to say, just grab the URL and exchange that with your friends or your internal team to go and narrow down on a design. So I'm going to go through the six petabyte example and start by putting in the six petabytes at the top. That's the target capacity. So that's what the design tool, everything that we adjust from here out is going to make sure that there's six petabytes of usable capacity. So if we change the drive size and make it smaller, it's going to add more nodes potentially. And all those kinds of things are just going to auto adjust for you. All the summary of the design is over here on the right-hand side. So you can see the usable capacity, the amount of raw capacity, the whole server specification, and the device specification. So this makes it really easy to go from a concept to a build of materials that you can work with your VAR or your distributor to go and get exactly that hardware and not have to spend a lot of time, you know, narrowing down the details. You can say, this is roughly what we need. So let's now like pick another server here. All of the various systems that we've certified at OS Nexus are in here. If you've got some other ones that you'd like to add, just let us know. But here I'll just cycle through some of them. There's some Cisco in here. There's some Dell systems, HP, Supermicro. The Seagate systems are in here. I don't know if you know, but Seagate also makes a server system that through some blades, these server blades that plug into their JBODs these days. And let's go to like a Supermicro high density chassis. So if I go and bring up like a 60 bay, that's a good one for a high density object storage cluster. So we just go down here, Supermicro 60 bay, and then we can choose a hard drive like a 20 terabyte. We've also put in some hard drives in here that are a little bit higher capacity that aren't quite out yet. Oh, yeah. Thank you. Yeah. Zoom in here. That will better. There we go. Thanks. So there's some 22 terabyte drives, and we're adding more more selections here as manufacturers come out with larger capacity drives. So once we've chosen a drive, you can see that it's using up 56 drive slots per node. And then this is the number of slots being used for the right log and the pool metadata. So there's a bunch of checks that we've added into the tool. So let's say that we definitely want one SSD for the metadata offload. But let's say that we went too low and said we want zero right log and metadata database devices. It's going to start popping up some warnings at the bottom saying that it's out of balance for this cluster. And that's based off of this 2% metadata slider. So you can tell it based off of how much metadata space you can expect to require for a given cluster. We started at 2%, which is pretty conservative. But if you, for some reason, need to design the cluster without adding any SSDs for metadata offload, just set this to zero. Otherwise, you're going to see this red text at the bottom, you know, because it's trying to make sure that you get the best design. At OS Nexus, we kind of have some rules on how we deploy these clusters. And one of the things that we always do is we always have a pool metadata device for object storage config so that the cluster can rapidly rebalance the bucket index pool. We also mirror the right log. And we do all this stuff in the Quantyser software. But you can, you know, design this in different ways depending on what your design goals are. So these sliders here are per node. So when I set it to one and four, that's the number of devices per node. And then this RAM device ratio, we're automatically adjusting the amount of RAM based off of, I think it's four gigabytes of RAM per OSD if it's platter and six gigabytes of RAM per OSD if it's SSD. So you'll see the whole server specification dynamically adjust as you change your design around to incorporate the right amount of RAM. If you feel like it's a little low, just adjust this, just take the slider and move it up and it will add more RAM. You can see that right now it's set to 384 gigs of RAM. If we needed more RAM on this design, we just increase that to 1.5 or something like that. And then this metadata data ratio, as I mentioned, this is just being able to set how much metadata you expect the cluster will need out of the full metadata device and the right log device. So as I mentioned, we generally set that to two or 3% to begin with. And once you've gone through all that, you can choose a storage layout. So on a cluster like this, we're shooting for six petabytes, you can see it's got eight nodes. And we've chosen four plus two erasure coding. If we were to change this to a replica based design right here, you're going to see that it increases the hardware a bunch. Now we've got 16 nodes. So it automatically adjusts all that stuff for you. There's some fun stuff in here too. We give it a rough estimate of how much power is going to be required based off of some averages that we see for servers. And it also adjusts the power requirements based off of known average values for hard drives and SSDs. This is also a fun thing that was just added recently, which is the estimated write performance and read performance. This is in our studies of our own cluster tests with partners, we've seen roughly around 60 megabytes per second per additional hard drive that you go and add to the cluster, and around 300 megabytes per second throughput for every SSD that you add. Now that varies quite a bit, depending on the media type, and the manufacturer and all that. So take that with a grain somewhat of a grain salt, but that's pretty accurate from what we get. And so it just automatically estimates the performance by doing that map for you and giving you a rough number. So in this case, the six petabyte cluster should see around 26 gigabytes per second in total write throughput aggregate. This is another fun thing in here is the minimum networking and recommended networking. When you set up like a replica three, you got write amplification. For every one megabyte, you write into the cluster, you're going to get three megabytes spread across all the nodes, across all the OSDs. And so if you were to set up a networking, so you've got a separate front end and back end network, so you've got dual 25 gig on the front and dual 25 gig on the back, what you'll find is that your front end network is not going to saturate, but your back end network will saturate and kind of have things out of balance. So what we've been recommending for a long time is to bond those networks together so that you can have this 25% of the available bandwidth go to the front and that 75% to the back end and have the LACP bond and network sort of just share the available bandwidth so that you get a nice even bandwidth or even distribution of the available bandwidth between all of your network ports. In some cases, of course, you can't do that. There's maybe security reasons why you might want to have two separate physical network bonds for your cluster, but this basically goes and estimates exactly how much network bandwidth you're going to need for the cluster design. And if you shrink the cluster down and it's like 2U12 base, you'll see that it'll adjust it down to 25, dual 25 or dual 10. If you go up to an all flash config, it'll automatically estimate all that stuff for you. So it's doing a fair bit of algebra behind the scenes to go figure out what the optimal networking is. So we'll go back to like maybe a six plus two because we've got eight nodes and so that can be the most efficient. We don't have all the erasure coding levels in here. We intentionally left out like single parity. We just are a single coding block. We don't recommend anybody ever deploy a CF cluster with a single coding block. Start with at a minimum two coding blocks and four plus two, six plus two, eight plus two, whatever you need. But just for overall long term health and maintenance of the cluster, it's a good recommendation to not have a single coding block. And so we've kind of put some guards up in the tool to make sure that you get a great design. We'll probably add some sliders later on so you can just move the K slider and M slider to control that stuff. And then the last bit is this section on the storage configuration. Let's say you expect to be able to get a lot of compression. You can move this slider around and it will automatically you can see these numbers over here change and you'll see that it needs a lot fewer disk drives as I increase the compression rate. If I bring it down to zero, it will require more and maybe even add an additional node. And then one of the other key things in a CF cluster is making sure that you've got enough space for backfill. That's your virtual hot spare space effectively. When drives fail OSDs get kicked out of the cluster. It's got to find space in the remaining OSDs to go and rebalance the data across. And essentially that's your backfill, you know, reserve space. So the slider is by default set to 10% and you can just slide it to the left or right. We recommend don't ever, you know, generally set the backfill less than 5%, but 10% is a good starting point. And then the reserve drive slots is just a way where you can reserve slots in the chassis to kind of force it to deploy more more chassis and things like that. So if you want to reserve 50% of the slots for a future expansion, you can do that. But that's that's basically the whole design tool. And then, you know, again, that when you're done with the design, just take the URL and send it to whoever you're working with on the design. And they'll be able to see it and adjust it and work with you on it. All the hardware device specifications here, all the server specification stuff is in there. We also adjust the processors as well. So everything's kind of really dynamic in the server specification. We're going to get a bit fancier with that in some future updates, especially some of the research that Mark Nelson did was really interesting around how to get the most IOPS out of your CEP cluster. And we need to incorporate some of that into the tools so that you can have a slider saying, hey, I really need a lot more cores because I'm focusing on an IOPS configuration versus a throughput configuration. But that's it. That's everything I want to go with. General, anybody with questions? Yeah, it's link.osnexus.com slash sap. And let me bring that. I'll bring that slide back up right there. Yeah, we have some some partner. If you go to if you go to the super micro website, you'll also find the tool embedded there. And we've got some some version for it as well with Seagate. So some some of the different hardware manufacturers that we work with really trying to promote stuff out there with those manufacturers make it easier for them to go design stuff clusters. And then our software platform just really makes it easy for those manufacturers to really put stuff into into production. They'll roll that out on their hardware with with Quantistor. Quantistor, you can get access to through our website. If you go to osnexus.com, there's a downloads and a try now and there's a community edition of the product as well. So yeah, yeah, go ahead. Yeah, yeah, let me bring it back up. That's a really good point. You know, I, we highly recommend using nearline SaaS whenever you can, because it's just not much in terms of price difference versus enterprise data. And you'll get a faster dual ported drive with some other benefits. So we intentionally left out NVMe versus SaaS media in there, mainly because that we didn't want to pin it to something that wasn't preferable for one manufacturer versus another. Maybe somebody's trying to do a SATA based design. And if we put the SaaS in there, then they would be like, well, it's all just about right, but the design tool is off. So we've just kind of left out the interconnect information. But certainly with SSDs nowadays, everything should be NVMe. You're especially important for things like the right log, because you need about 60 megabytes per second, roughly for every hard drive. So if you put in, if you're building like a 60 bay unit like this, you can 60 times 60 or 3600 means you need 3600 megabytes per second of throughput. You could do that with two mirror pairs of NVMe drives, but you need a whole lot more if you're using SaaS or SATA. So we just really highly recommend using NVMe for the right log and metadata offload and everything. And it's the nice thing, too, is that we're finding that the NVMe drives are lower costs, although Seagate and some other manufacturers have some that are pretty close to price parity with the NVMe. But definitely great seeing the latest generation of PCI-4, PCI-5, CLX type SSD NVMe devices coming out, because now you're going to be able to do a right log with a heck of a lot less storage devices, storage media. All right. Thanks for questioning. Yeah. All set? I think we have two stars in the next one. All right. Awesome. Thank you, everybody.