There and Back Again – NVMe to Cloud and Everywhere in Between with Hammerspace

Uh, my name is, Chad Smith. I'm the Field CTO of Alliances here at HammerSpace. Mm.

And today, I'm gonna give you a demonstration of Hammer Space running both on-prem and crowd, kind of a hybrid solution. Um, I decided on doing demos instead of slides today because, a lot of you have a lot of experience in hearing about Hammer Space, talking about it, but not actually seeing it in action. Mm-hmm.

So I went ahead and recorded a couple demos I'd like to share with you guys today. So today, I'm gonna present you guys with four demos. Um, they're covering, various topics such as assimilation, global file systems, Tier Zero, as well as our, our S3 interface and metadata.

So let's jump into w- the first demo. So the first demo is really all about data in-place assimilation. We're gonna walk through the process to setting up storage assimilation, shares, storage systems, volumes, and mounts.

We're gonna spend a little bit of time discussing Hammer Space sh- snapshot efficiencies tied to third-party storage and APIs. Uh, we're gonna briefly discuss, multi-protocol access via SMB to an assimilated NFS server. And then finally, we'll conclude our first demo with what it takes to set up a global file system across sites.

So let's jump into it. I'm gonna start this video, and I'm gonna pause it frequently to discuss some aspects of the solution. So out of the gate, what you're looking at right now is the Hammer Space UI.

It actually runs on the Anvil server itself. So as long as you point your browser to the Anvil's IP address, you're gonna get to the Hammer Space interface. This is a relatively fresh cluster, installed on an on-premise environment, and the only thing I'm gonna show you guys that I took the liberty of installing is I just attached it to Active Directory.

And the reason why I did that is 'cause we'll be using, SMB, access throughout this demo. Wanted to make sure that cross-site, SMB access is, is set up correctly. So to start the actual, data in-place assimilation process, what I'm gonna do is I'm gonna create an empty share called Collections.

So within our UI, just gonna type in the name of it. Then I'm gonna go ahead and set a snapshot schedule on this as well. The reason why I'm doing this is 'cause we're gonna talk a little bit more about snapshots later on in this demo.

Once the, share is created, I'm gonna go ahead and, and add a storage system. I'm gonna call it Images, and we're just gonna add a simple description of what it is. I'm gonna pause it real fast and talk about our eight- API interoperability, to third-party storage solutions.

Really the ... What makes it really efficient is that a Hammer Space file can live on multiple third-party storage platforms. But when it does live on a particular platform, we wanna take advantage of its, snapshotting and clone efficiencies, for its copy-on-write.

Uh, so what we have is deep API integrations into that storage to allow us to gain that storage efficiency- R- ... regardless of where it lives. Chad, Jack Pauller with, Paradigm Technica.

So a couple questions on that. You're talking about, when you say copy-on-write and third-party storage, are you talking about ... And you talked about a Hammer Space file.

First, define what you mean by Hammer Space file versus the native files. Sure. Uh.

So Hammer Space writes its files out in what's called a clone structured file system. Mm. Okay?

That file system itself is basically our structure that we understand, but the third-party storage system may not necessarily understand. Even though it may reside, let's say, on a, a PowerScale- Mm-hmm ... it is our clone structured file system on it.

Now, what we wanna do is we wanna get the efficiencies out of that third-party storage. Right. Right?

We wanna use its, sta- space efficiencies and copy-on-write. Okay. So when you're talking about the, the, the copy-on-write snapshots, clone efficiencies, you're talking about leveraging the third-party- Yes ...

storage system's native capability. That's right. Okay.

Yes. But you gotta understand, our files can live on multiple storage systems. Right.

Each one will use its third-party integration to manage these, the storage efficiencies beneath the file system itself. Right. And then when you're talking about Hammer Space files- Mm-hmm ...

that means that, if I understand you correctly, when a user is interfacing through the u- the, the Hammer Space's global namespace- Yes ... that user can see the existing files, but if they say they're going to create a new file, right, it's going to be a Hammer Space file that's then stored in some underlying storage that may be a third party. Yes.

Right? But it may ... That, that new file isn't necessarily native to the or- the ...

It wouldn't reside, let's say, on your PowerScale as a file native as, uh- Yes ... side by side with the existing. Correct.

Right? Yes. That's correct.

Yeah. So, that's what we refer to as data placement simulation. Mm-hmm.

Then we'll change the, the file structure to a Hammer space specific structure. You still go through our virtual file system to access the file- Right ... 'cause we're tracking all those changes.

Mm-hmm. You would never go back through your Isilon once you assimilate it. That's what I was going to go to next.

Yes. So, so once you start using Hammer space, you essentially lose the access to, through the native interface- Yes ... to that file.

Yes. Yes. Okay.

Uh, we do have a process called de-assimilation, which puts everything back. Gotcha. Mm.

Thank you. Mm-hmm. All right.

Let's continue with the, demonstration here. So I've just shown all the various products that we support. In this particular demonstration, though, I'm using a Manila, NFS server.

Just adding the IP address of it. Uh, we're scanning all the available volumes on our system. To us, a volume is a mount, right?

So that's an interchangeable term with Hammer space. But we do see a volume on the server called, images that resides in the mount images directory on that server. Continue the presentation here.

I'm just gonna select that volume. Hit next steps. Now, it's important I'm sl- I'm selecting the assimilate button.

I ha- I went through that pretty fast. Let me go ahead and pause that again. But the assimilate, the assimilate button, allows us to use the existing storage.

We're not gonna re-silver that share and use it for s- new, net new storage. We're gonna use the existing storage that resides under all the files, their directories, and we're gonna data in place assimilate that. That's why checking that box allows you to do that.

And what would happen if you didn't check that box? Yeah. It would re-silver it.

It would, it would clean it out, and it would just use it as a storage bucket, in essence. And delete all the data. It would delete all the data.

Okay. Yeah. You're not assimilating, you're just using that space to put more files into it.

I see. Can I, can I jump in with that? That's, uh...

Maybe, maybe you're gonna cover it later, but- Mm-hmm ... how does it work with... By the way, Brett Walmorant.

Yeah, this is also to Jack's question I think you answered. Maybe I misunderstood it, but is it a bit... Some of these flows almost seem like one-way flows.

No, they're bi-directional, for sure. Okay. Uh, and what I mean is, o- one-way streets in a sense.

Like, if you assimilate to Hammer space, you then need to tell everyone to stop writing directly- Yes ... over there. Is that, am I- Yeah, yeah.

And we... Because basically, what, what we're gonna do is you're gonna do a one-time remapping of your data. Happens once.

So you're going to your previous, PowerScale storage. Now you're basically gonna tell your, your users or you're gonna remap to a, a, another drive, and then you're gonna continue on. Uh, and that's, that's your, that, that is your, your outage window in theory is that one-time mapping over.

Everything else, as data migrates and moves between multiple systems, I mean, a lot of people use Hammer space as a migration tool, right? I'm gonna go off a NetApp and I'm gonna go to an Isilon. Yeah.

Well, I can now do this assimilation- Ah, I see ... and everything seamlessly moving behind the scenes, and the users don't know from one day to the next, is my data actually residing on NetApp, or is it residing on an Isilon? All happens kind of behind the scenes.

So it- Once you've added that virtualization layer- Mm-hmm ... of the namespace, that all just is part of the solution. So rather than it being an extended long outage- Yes ...

for the migration, what we're essentially saying is, is you're gonna have a 30-second remap to a new drive, and then from then on, the migration's just happening transparently and- Exactly, yes. Okay. Interesting.

What about availability in those cases then? What kind of solutions do you have for that? Uh, we'll get to that.

Okay. But you're using the, durability and availability that's already existing in the Isilon- Yeah, sure ... or the, the NetApp.

Yeah, that's on the back end. Like- Yeah ... you can show the front end where you're presenting namespaces, right?

So- Yeah. So our, our namespace is all virtualized. Okay.

And it really depends on, the devil's in the detail. It really depends on what protocol you're using. 2, that's all built into the metadata layer that's being presented by the Anvil servers.

And we have this notion called a flex file, and a flex file hands out a layout, and that's the directions to where the file's at. And it really kinda gets into the minutiae or the, the details of the solution. But any other protocol that you're using, NFS V3, SMB, CSI driver, and S3, that goes directly to our DSX server, and then that handles any legacy, protocols, what we call legacy protocols, and then that's distributed across multiple DSXs with their own virtual IP for each one.

So that is how you maintain your high durability across legacy protocols as well. Okay. So I'm just walking through the rest of the add volumes installation wizard here.

Okay. And in a moment we will see it show up. There it is.

Now, what we're gonna do is we're gonna go back to that empty directory that we had previously created, and now what's happening behind the scenes is this data in place assimilation process. It's running in the background right now. It's walking the file system.

It's collecting all the metadata itself. It's not moving the data. It's just collecting the metadata.

It does take a couple minutes to happen. This is running on a couple instances in the cloud, so it's not the fastest thing. But as you can see, we're already discovering directories, right?

Right? So there's all my files. Uh, it's updating right now, and as you can see, just finished with 14th, 14k files it just discovered on this system, right?

What we're gonna do real fast is we're gonna go ahead and check it. Can I have access to that? And the interesting thing to note too, this is an NFS server accessing through SMB.

So there's your bi-modal multi-protocol access out of the box, NFS server connecting via SMB, right? And that's what we're gonna verify and check, can we have access to these files? So I'm quickly going into the directory.

I'm looking at one of the directories, and there's a file. That's a permissions issue from a, an earlier lab. But now I can go into this one, click on the file and there it is.

I can see the image. So now I can access this assimilated storage, from an SMB share. Now, the next thing I'm gonna do- I have a question- Yes ...

regarding permissions- Yeah ... at Bell advance. Uh, so I probably have permissions defined on the file system that exists- Yeah ...

on target storage. Yes. How is, how are those permissions assimilated by Hammerspace?

They are assimilated. Okay. Yes, that's the- That's my big- That, that, that, that's yes, the answer ...

mess with those permissions. Yeah, no. All, everything gets, everything gets migrated over.

You know, all your, all your, your, your file permissions gets carried over. Um, we have an RC 2307 mapping that happens, that will map SMB permissions to NFS permissions, and it just ... I can't really go into too much details about it right now, but it just, rest assured that it does get migrated over.

Going forward, as I start using Hammerspace- Mm-hmm ... to manage that portion of my file system, do the permissions get written back to that storage device? So if, if someone- No ...

wanted to make an end run around- Yes ... Hammerspace to that Isilon- Yes ... would the- Well, they wouldn't even see the files because we're also laying our cone structured file system across the files.

Every file becomes a UUID- Mm ... and within that UUID becomes the payload of file that's in a chunked format. Okay.

So even if they did directly- Yes ... to the storage device and tried to enumerate files- Yes ... they wouldn't have permission- They would have a, a very difficult time trying to figure it out.

Okay. So really- Yes ... at that point, the only way to get to the files is through- Yes ...

the Hammerspace interface, and that's what is- Yes, yeah ... enforcing permissions and access control. That's correct, yes.

Awesome. All right. Thank you.

But to be clear, that rewriting of the file into the new cone file system, that only happens when the file's changed. Modified or written or changed, yeah. Well, because that's data in place assimilation.

Now, you can set, you could set a, a read-only policy where you, keep your file in place, read, and then set an objective, which we haven't really talked about, but those are the rules for data movement, to put it in another location, in another volume. So our professional services team generally will make an as- a, a assimilated share read-only, and then with, on that same storage system, make a new mount where all the new data gets dropped into. I see.

Okay. So there's different ways that you can address this. It really depends on the customer's use cases and situation.

Okay. So the next thing I'm going to do r- right now is I'm going to prepare this on-prem cluster for the cloud, and this is the beginning process of setting up the global file system between two sites. The way that we do that is we use a bucket in the middle, or an object storage in the middle to facilitate that transfer of the data.

So in this next demo is just me walking through, adding a s- another storage system, but this time we're gonna be connecting to, some S3 object storage in US West One in this example. This is a little bit of a laborious prod- process. I, I do apologize.

It, it does take a little bit of time, but just basically drop it in your access key and security key. Uh, we'll give you, you'll give you visibility to all the available buckets, and then what we'll do is we'll pick a particular bucket to use as our, as our target. Sorry to interrupt you again.

Uh-huh. Um- Go ahead. That screen gives me the willies.

Is there any other o- option besides an access key, like a role? Uh, yes, I believe there is, yes. Okay.

Um- Access key's no good. Yep. Yeah, yeah.

One of- You- I think we have, like, access tokens and stuff, I, I believe. Okay. For this demonstration, you're walking us through the user interface.

Yes. Makes sense. Can this all be done programmatically- Yes ...

as well? It can. Yeah, yeah.

Okay. So we have, uh ... Let me pause this real fast.

We have, the HSCLI, and then we have the HSTK, which one is a command line utility, then the other one is a toolkit, a, and it can be a Python toolkit. Uh, and then ultimately, if you're really good, we have a rest, a rest interface as well. Okay.

How about a Terraform provider? Right. Oh, we have all that.

Yeah, so we, we'll get to cloud in a second. Okay. But we support every, every, every template imaginable.

Okay. So just continuing on here. Oops.

I hope I, didn't mess anything up here. Uh, so that actually concludes our first demo. So what did we do?

We assimilated some, some third-party storage. And then we, made sure that it's accessible by SMB. And then we set up, an S3 bucket that can be an archive and DR disaster recovery bucket if you wish, but we're also using it as a means to replicate between sites.

Okay, so the second demo is we're gonna go ahead and deploy in cloud, and then we're gonna finish setting up the global file system. We're gonna quickly discuss, the Hammer space deployment options. Um, and then we're going to, enable and finish the global file system between sites.

Uh, and then we're gonna understand the behavior of a default, global file system, system, excuse me, where on, out of the box it's a pool on demand, but we want to apply objectives to proactively keep files local at each site. Okay, so let's jump into the second demo. All right, so what I'm showing right now is I'm showing, AWS, and that is a Terraform...

not Terraform, the CloudFormation tool that's built into Marketplace. Um, so of the, of the major clouds we support or we have marketplace listings, and they're generally a BYOL or a metered offering. So you really have your choice of how you wanna consume Hammer space in the cloud.

Now, I won't bore you with all the details of the fields that you have to fill out in a, in a CFT, but what I will do is I'll assume that we're familiar with that and cut directly to it running. So here we are right now. This is, this is a deployment running in AWS.

It just stood up. I just... all I'm doing is taking the IP address of the Anvil server, throwing it into our browser and logging onto the system.

See, we have the same dashboard. Uh, you could see that the site's slightly different right here. So you can see the location is now in, is in San Francisco Bay Area, while the other one was in, Ohio, for example.

Uh, so shows you it's a different cluster. And then all we're gonna do at this point is we're just gonna go configure that bucket. And it's the same bucket that we had configured in the on-premise cluster.

So you're accessing the same bucket. This is what facilitates our global file system between the two sites. Does take a little bit of time.

Does anybody have any questions while we're- I just have a- Uh-huh ... pretty, pretty basic, just a fundamental question. I suppose, the, the UI, is pretty nice, of course.

Um, I suppose you have a, a, at least one API to drive this. Yeah. Oh, yeah.

Sorry. Yeah, yeah. This is all API driven.

Um- So- I'll... We have- If I right click Inspect, I'll just see the- Yeah ... API calls or do you have a spec that can be downloaded and- Yeah, we have a spec.

We have, we actually have, a HSTK, API toolkit that can be downloaded. Then of course we have the HSCLI, which is, you know, scriptable, command line language too. Oh, that's...

Yeah. Now we're getting to the whole agents using CLIs or- Yeah ... MCP service debate.

Okay. Thank you. Yeah, yeah.

There will be some announcements, in the next week about that, that very topic. Another, another question. Shala here.

Um, you mentioned earlier, you know, what we were looking at was, I believe maybe 14,000 files. So I was just kind of curious, what about if it's like a really large- Yes ... dataset?

Like, what's that timeline look like? Well, it's a formula, and it really is based on the amount of resources that are in the Anvil. Uh, the Anvil that we use in this demonstration is an Amazon EC2 instance that I'm running in a lab.

I think it's an M2, 2xl large, right? So it's not a representation of what a production environment would be. Yeah.

Now, our professional services team, when you're looking at a, what we call a T-shirt size large Anvil server, we understand what that ingestion cadence will be, or have a, a good understanding of that is, and it's, you know, it's more like, you know, a million files per hour or something like that. What- what- whatever that, that is because that's the, our production environment. Right.

So it's gonna be far different than what I'm showing you in this demonstration. Okay. And then what about...

So, does the system like perform a full file system crawl or can you ingest metadata, you know, lazily as files are accessed? It does. It, it...

Well, it's really interesting, and that's a great point that you brought that up. Um, I didn't really go into the details of it, but if you can imagine a file system with a billion files in it, right? And it's a live file system, as you're scanning it, you have users accessing it.

Mm-hmm. " So you can go to a very specific sub-directory within your file system and it will scan on demand and assimilate that and bring it in because a user is requesting access- Yeah ... to that specific section within a file system.

So we can, we can, we'll, we'll scan, the directory, you know, parent, child, and sub-directory on down, or we can do it on demand. Okay. Yeah, yeah, I was just thinking in my head because I deal a lot with data migration- Sure ...

so our goal post is forever moving- ... as you're trying to get them migrated, so. Yes.

Yes. Yeah, and like again, a lot of people, find, the intrinsic benefit of Hammer space is just for storage migrations, right? It's an added benefit.

That's something they get for free is this ability to make this seamless. Nice. Okay.

Oh, so let you guys know what's going on here. Um, so we created the bucket at the remote site, and now I'm gonna go log into my original on-premise cluster. It is the owner of the collections share, and I'm going to give the remote site permissions to participate in a global file system.

So that's what I'm doing real fast, log back into the on-premise cluster. I'm gonna go to the collections share. I'm gonna go in the Edit tab, and now this time I'm going to the File Systems tab and I'm adding a participant.

Now let me pause this real fast and tell you what's happening in the background. When we share a bucket as a replication target, there's a reservations file that gets created, and inside that reservations file, any participating site will add its login credentials. It will add the name of the cluster and the IP address for it to connect to.

So when you have another cluster connecting, it's gonna have a list of all the participants already pre-populated. So all you have to do is select it because it's all in that file itself. It's an encrypted file, but imagine having up to 16 sites participating at the same share at the same time.

You wanna have that list pre-populated for you. That's exactly what we're showing right now, in the GUI. So typing in the, the, the username and password of the remote cluster, testing the connection, then adding it to the global file system.

So now the collections share is a global resource between sites. It's that simple. So what we're gonna do now is we're gonna go back to the, the Anvil in the cloud, and we're gonna go look at the collections share, and we can actually see all the files available at the remote site.

Just like that, they're all available. So now you can actually see them. You can see all the metadata associated with it.

Quick- Quick. Quick... Oh, sorry.

No, go ahead. It may be a silly question, but I'm going to ask it anyway. Sure.

I love doing it. Um- It would be kinda cool possibly for the audience to clarify, we keep hearing the term Anvil, like maybe- Oh, okay. S- I do apologize.

So Anvil is our metadata server, and then what we have is a DSX server, a data- data services node. Um, and at a real high level, the Anvil server, it just, is just there to, collect and maintain the metadata about the server. 2.

Uh, the DSX servers has several roles and functionalities. 2 it serves on the DSX. It also is the data mover, so when you set an objective to move data, it is the engine that move, physically moves the data from one storage platform to another behind the scenes and makes it all seamless.

It also, another role that it has, is responsible for, moving files to object storage. We call that the, the cloud mover. Okay.

Its job is to take files, chunk it, encrypt it, move it up to an ob- an, an object storage, and then on the other side, bring it back down, un-encrypt it, and then we typically will apply encryption, compression on it, so it's also de- decompressing the file and making it available on the DSX as well. So those are the major roles of a DSX. 2.

Uh, does that answer your question? Yes. Thank you.

Okay. Thanks. Okay.

So just to kinda get yourselves back up to speed here, boy, I'm really running out of time. Um, I'm going to, try to connect, to SMB in a remote site. Oops, sorry.

And just got to map to it. It's really important that we have active directory integration on both sites right now, so we, they understand the SIDs and the layouts between sites. dom.

Uh, if you didn't, you wouldn't, you would instantly get permissions issues, right? So we're gonna log in real fast. We're gonna verify that it's working.

And quickly what I'm going to do is I'm going to pause this again and talk about why it's taking a while to load this file. Because all we did between the two sites right now is we just replicated the metadata, right? So what this file is actually doing right now is it's going across all the way to the assimilated storage.

It's grabbing that file. It's doing this on demand because we've set no policy on how to cache the data and where to cache the data. So yes, it's gonna take a while to do because we're going across the wire each time to pull this file.

Now, what we do behind the scenes is we'll cache this a-a-on the, in the RAM on the DSX for five minutes. If the file isn't touched or not modified after a five-minute period, we'll, we'll evict that cache, and we'll move it back. Then if you touch it again ten minutes later, you gotta go through the whole process again.

But we do have this concept called objectives, what we'll talk about later on, that removes that need to have the wait for the file to be pulled across each time. All righty, so there's the file, and I believe that pretty much concludes the second demonstration. Okay, so I'm gonna pause real fast, and I'm gonna start the second part of the, the demonstration now.

Hello, everybody. My name is, Chad Smith. I'm a cloud CTO at...

Geez. Uh, hey, Chad Smith. I'm a field CTO at Hammer Space.

I'm responsible for alliances. It's been a long day already. Um, I previously, showed two demos of Hammer Space, on-prem, assimilating some third-party storage, and then, setting up a global file system to transfer files to a second site that lives in the cloud.

Now we're gonna continue that conversation and add on this new concept we like to talk about, which is called Tier Zero. So let me bring my... bring it back up here.

Make sure I just re-share my screen. I don't know what happened. I do apologize.

Hopefully, I can make this work. All right. All right, and I'll put this in presentation mode.

Uh, go jump to this slide. That work? No, it did not work.

I apologize, guys. I don't know why this is... Share.

All right, third time's a charm. All right, let me get to the next one here. Okay, so this is where it gets exciting, right?

Um, so what I like to describe Tier Zero as local performance with the utility of a file system. So we're gonna discuss Tier Zero installation dependencies on GPU nodes, how the NVMEs are mapped to the NFS mounts versus mounted shares on the client. Uh, we're gonna set up Hammer Space storage, volumes, and this concept called volume groups and how high availability zones, ensure data protection in this model.

We're gonna review, data placement policies that affect the creation, modification of files when a durability or availability objective is applied. 2 client-side mirroring works. Okay, so before I jump into the demo, let's talk about what it takes to prepare the, the Tier Zero nodes, or this would be your AI nodes, your GPU nodes.

This would be the, the use case. There is a little bit of installation that needs to be done on these nodes, but it's not like you're, you're a kernel-level driver you have to compile for. It is really simple stuff.

Uh, it can get complicated depending on the environment 'cause you got, you got NUMA zones, and you got all kinds of comp-com-complexities on, on larger environments. But in this demo, we're just gonna, we're gonna keep it really simple. And really when I mean simple, it's simple.

Basically, you're creating a directory which is gonna be a mount point. You're gonna drop an, an NVMe in it, and then you're gonna mount that NVMe to a share, and then you're going to re... then map your NV-- your Tier Zero client to that mount that we had created earlier called Collections on the Hammer Space system.

So what does that look like? We're gonna tie each NVMe to a mount, and then we're going to, tie it all together by mounting my client to the Hammer Space. And a little switcher...

Oh, and then I also wanted to discuss too this notion of availability zones. So by definition, an availability zone is a fault-tolerant, is a fault domain. And what we consider a fault domain in this use case is the instance itself and its underlying storage associated with it.

And what we do is when we write out files using our client-side mirroring, which is a synchronous write across multiple zones, we want to ensure that we're not writing two mirrored copies to the same node. By, by dictating what an AZ is, our product ensures that it's not being written to the same, the same node twice, right? Defeats the purpose of client-side mirroring if you're writing to the, the, the same drives on the same nodes, right?

So that's what an AZ, avoids. And of course, to make this all work, it's a place-on. It's another objective that I'll get into in a little bit, and we're gonna assign it to the collections share.

It'll be much clearer in a second. All right, so another demo here. Just like before, when we assimilated that third-party storage, we basically walked through the same process.

We're gonna take a storage system, and this time the storage system is an individual GPU node. Um, and then what we're going to do is we're going to, assimilate it with, NFS other again, and we're just gonna type in its IP address. Same step as the previous one.

Uh, we have lots of scripts that can automate this. Imagine having a hundred GPU nodes. You don't wanna do this individually, so we have ways of streamlining this process.

But we just discovered two volumes on this system, and what we're gonna do is we're gonna append the name with the availability zone that I mentioned earlier, right? By just appending AZ one to it, we're telling Hammer space that this is an availability zone, and these two volumes are, in that availability zone. I'm just changing the notification thresholds about the usable space and capacity.

Um, you really don't have to worry about that too much with tier zero. And then I'm just gonna skip to performance test for part of this, demonstration. I know they were not gonna get to it.

So I just repeated the process for all five nodes. And then you can see that all ten volumes are available as well. So the next thing I'm gonna do is I'm gonna create a volume group.

And this volume group is gonna be all AZs and a simple description. Not so simple, actually. Let me sec, fast-forward this thing a little bit here.

All right. So I finished that. I created the volume group.

Now what I'm gonna do is I'm going to associate all volumes I've created with this volume group. What we are doing is we're creating a distribution map to map all the available volumes to this group. And then all we do to make this thing work is just assign this newly created volume group to the share itself.

So I go into the objectives. I'm gonna add an objective. We're gonna use one called a place on, and I'm going to place on this AZ and apply.

And then what's gonna happen is you're gonna see a flurry of activity. 'Cause what we're doing right now is we're moving all the data that was sitting on that assimilated storage all the way across to the, all of these, tier zero nodes now. So yes, go ahead.

Um, are you moving or copying or freezing and moving or? We are copying- Okay ... the, the data over.

Okay. Uh, but the concept of Hammer space, we don't ever like to use the word copies because from a physical standpoint, it's a copy, but from a metadata standpoint, it's a single instance of it. We call that instantiation.

Okay. So it ever only is a single metadata copy, but it can physically live at multiple spots. Okay.

Thank you. So yes, we are copying the data over.