Unpacking Storage In VMware Cloud Foundation 9.0

Howdy. My name's John Nicholson. I work at Broadcom here, do technical marketing for vsan and work within the storage area, and as it pertains to the VMware Cloud Foundation stack.

So today we're gonna talk a little bit about, um, what's new on the storage side within VMware Cloud Foundation. Nine. So going over some of the areas.

Um, I want to go over some of the operation tooling, start at kind of the strategic capabilities that we've brought out within nine, as well as help you understand some of the tactical tooling. We have to answer the digital question of why is this slow? We'll talk about some of the key capabilities within VSAN nine, um, and other capabilities that are brought out.

So going over kind of at a high level, there's four major themes of improvement. Um, we've got improving the, the cost of operations. This is gonna be driven primarily by the new global deduplication.

We also are adding additional disaster recovery capabilities vs a n to vs a n replication and integrations with live recovery. And then we also have, um, new performance capabilities and general security improvements across the platform. And this last area that we'll actually start with a demo on is going over some of these new operational consoles and abilities to understand what's going on across your estate.

And now I'm gonna transition over to the, uh, demo. So looking at these multi-site operations, if you've got one cluster, it's great that you're gonna work with NV Center normally, but in a larger environment, we're gonna use operations and we have these new capabilities. We can see all the alerts in the environment, we can see all the clusters I have here.

I can also see their configuration. I can see the health scores that are rolling up. So if there were environments that were having performance problems or other capabilities that would get surfaced, I can see what kind of vsan cluster they are, whether they're the new express storage architecture.

I can also see compute clusters, which are clusters that are just consuming VAN storage. And then on the right here, I can also see those cluster performance capabilities. And I can see not only how many iops and being delivering an environment, but also what that latency looks like.

Um, across this environment, we have this new diagnostics capability. So I can actually go look into clusters and troubleshoot and see what's going on. And I can pick a time window and try to understand, you know, is there's something wrong in this environment and this cluster, initial cluster I have, if I go look at this and run this troubleshooting, um, I may discover, you know, across a specific time I don't have issues.

'cause my cluster obviously has no great performance issues, but if I did, I might see other capabilities. Now, if I wanna look deeper into what's going on with the workload, we have a capability native to the vCenter server called IO Insight. This is actually gonna run something called a Zy Trace.

It's going to like a DVR for the entire, uh, storage io path of that virtual machine. Now we're gonna select which virtual machines we wanna run this for. So if you're trying to understand a workload and maybe you're migrating a workload, um, into a new environment, and you wanna get a better picture of what's going on, this is gonna help give us a lot of visibility into what the actual IO path is doing on a virtual machine.

Traditional monitoring often works on a random sampling or polling basis. Um, this is kind of nifty in that this is actually gonna capture all of the io, um, that's going on in that environment and actually trace through what the actual performance, um, demands are that we're running during that period. And if I have it also within an environment, I'm able to capture these and create these, um, instances and go through.

Now, if we go look at the actual performance that's been captured on these workloads, we can see the amount of iops that have been, um, that are being from a top talkers perspective. So we can see the, the top VMs in my cluster in terms of what, uh, performance demands are being made in the environment. And since I've had these, uh, these captures running, I can now go view them.

So I've got a logs appliance I'm gonna go look at, and this is gonna break down on a per VMDK basis. I can see exactly what the, um, performance, the throughput, but if I scroll down here, I can actually see the distribution on the block size and the latency distribution. So rather than get a simple average, which may hide some outliers, um, in this case, I can see on my high side I'm one to five milliseconds.

But on my low side, I'm in the microseconds. Um, on my block size, I see that I've got a couple very large blocks, but most of this is 4K. One of the challenges a lot of times is if you look at a lot of just general performance capability gathering, it'll often average this out.

But with this we can get the exact requirements of what, uh, it's running on. Now this other tool I'm using here is called Trip Analyzer, and this is gonna show the end-to-end io path of that, uh, virtual machine and the discs and where they're located. Now, if I was having performance problems in an environment, this will actually surface in red the individual component, but I can also drill quickly in.

And so if I'm trying to trace down where Latency's coming from, this is gonna help me map it end to end. So I can see I'm looking at the individual devices, I'm looking at actually the raw firmware latency coming off that device. So if there that drive was either overloaded or had a problem, I can also look into the network hops.

Now, historically as a storage admin, if I wanted to do end-to-end troubleshooting of an IO path, I might have to log into my fabric switches. I might have to log into my hosts and go look at ESX top. I might have to go log into a array themselves.

I'd have potentially to look at multiple places to understand that IO path end to end. But here we're able to capture what the, what the actual performance impact of every single hop is because we are both, so to speak, the client and the storage platform. We are both sides of this.

And I noticed that this is using an a, um, ESA, uh, architecture for the storage. Is this also available with the OSA, the original storage architecture? Um, the IO Tripp analyzer.

So the, um, these bits, um, IO Tripp analyzer's been out for a while. So yeah, I believe that us, it was, um, uh, available with OSA, the, uh, the VCO Z trace capabilities. Those are, those have also been available, um, in regards to that.

Okay. And Second question on that is, what's the overhead, like if we are putting these, these 'cause these traces on, is this a, you use it briefly while you are troubleshooting an issue or planning for a performance upgrade? Or is this a more general purpose monitoring tool that we might use more widely?

So The last time I talked engineering on this, I think it adds about 1% CPU load to a host. Um, it's not something that we generally run 24 7, but you can, uh, schedule those to run and people do, if there's a specific virtual machine, um, on the overhead is relatively low, but it is there, it's not, that's why it's not on, uh, 24 7, uh, currently. That said, the general performance service is running 24 7, um, and it is capturing that data, that performance service, by the way, has been improved where the current pole, uh, pole interval is now 30 seconds.

However, if you really want to go nuts, um, if you go into the cluster settings, you can actually turn on what's called network diagnostic mode. And for 24 hours, we will run a one second poll interval specific on the network stack, which if you're trying to, um, identify microburst related performance issues or maybe things like you are concerned on switch buffers or on a leaf spine link are being oversaturated. Um, that one second granularity is really nice.

Hey, hey, John, I noticed in the demo that you started out, uh, in the ops console, but then a lot of it, it looked like it was in the vSphere console unless I was Yes, wrong. So do you expect the storage admin to spend more time in the, in one console versus the other? Or is some of that functionality, the new functionality showed within vSphere has make its way into ops to give it that single pane of glass?

To use a cliche feature, It's, it's always about pain or at least trying to avoid it again. Um, so some of those things that actual storage diagnostic that actually was originally a V center only feature. Um, and we've moved it to ops and a couple things have happened there actually under the hood, one that previously required a, a cloud connection to run.

Um, and we've removed the need to go use the cloud, the ops is your cloud, so to speak, for that functionality. Also, it used to be limited only to diagnosing HCI bench performance benchmarking runs now. It just works for general troubleshooting.

So that's an example of something that started in vCenter and we moved over. The other thing though, from a general where I expect a, an admin to be is I expect if I'm looking holistically across my fleet, if I want, if I've got multiple clusters sprawling out, you know, tens, hundreds of these things, or I'm looking at general capacity trends, I'm gonna probably spend my time in ops. If I have a specific virtual machine that a specific someone is asking me about, and I'm trying to drill into the tactical why that's slow, I'm probably gonna wander back into my vCenter server.

However, obviously there's links between UIs to hop between them. Um, that said, the general trend is trying to move as much end to end to hops as possible. Yeah, from that standpoint, I remember back in the day, it's been a while since I've been a BS A N admin be having to hop through the vCenter console various places.

If I lost something in, in my vsan cluster, uh, an entire host, a single drive, whatever, and I wanna view resync status, affected objects, stuff like that, I knew where to find that. Is that gonna make its way into ops at some point? Is it still gonna be, is uh, you know, you have to know the right place to click within vCenter?

What's that gonna look like? So what's driving a lot of that from a UI simplicity is actually when you click on health alerts and things like that, um, it, it tries to drive you into that. And some of that stuff I showed you there, like with the IO trip analyzer is there's all these different performance dashboards and they're scattered across all the hosts and the VMs.

But if you're using that view and it identifies a red area, it'll let you drive straight to it. So kind of our, our designing goal here is to try to make it to where you don't have to memorize the 14 clicks, uh, to go understand things. And if you have a health check or an alarm that's going off in ops, it should take you straight to where that is.

Um, and some of that's you'll, you've seen previously with the vsan Health to where if there's an issue, you can click the troubleshoot button or you can click the, okay, what's the relevant KB for this? Uh, we try to make sure all those health alarms and rollups that go into OPS and the vsan Health Service have those capabilities. Uh, looking at historical data, how far can I go back in time?

So operations can hold data for years, I believe. Um, the vsan performance, uh, service tends to hold about 90 days on its own, but that data is gonna get rolled up into ops. So for your longer term retention, you're still looking at ops.

Um, it is worth noting that the vsan Health Service, I believe has at least 90 days. And you can also, uh, there isn't actually an option within the UI to say, show me what previous alerts have gone off. And I can see the historical track for those, those alerts.

So the other thing that we're, we're bringing kind of back in a way to vsan is deduplication. So we had deduplication with the original storage architecture, but it had a lot of limitations. Um, and we've brought, now with vsan, NESA, when it initially launched, we just had compression.

We wanted to make sure we refactor deduplication really got it right. And so we have this capability today, um, and we're calling this cluster wide global deduplication. Uh, this is launching with limited availability, um, with nine, um, there's gonna be a request for technical approval.

Basically, you fill out a form and you can get access to it. Um, some things that have, that are definitely improved. With this, we are using a 4K fixed block granularity.

I see quite a few, uh, storage people on this call. So I know that may mean some things to you, which is generally pretty, uh, granular in terms of that. We also are going to ddo across the entire cluster domain.

Previously with original storage architecture, it was on a per disc group basis. And so if you had three disc groups and a host and you had five hosts, you could have 15 DDO domains. Um, we are going to run this asynchronously.

This is not sitting in the right IO path, so it will not impact right performance and it's gonna adaptively, throttle and run based on, uh, there being available performance resources in the cluster for it to run on. Um, this does integrate with some of our other capabilities, snapshots, compression and so forth. Um, and we're looking to expand this out, um, from a under the hood, kind of how this works is we're doing a post-process.

We're gonna go through, we use a secure cryptographic hash that's Shaw 2 56, so we're not really worried about collisions, um, in regards to that. And we will create d meta metadata objects, um, that as we find that we single instance that data out and grovel that, um, if we obviously find no no matching, um, we are going to do some sharding across the cluster for scalability and performance and make sure this gets balanced, um, and try to keep large reads contiguous and, and not cause excessive fragmentation across the environment. So I I'm sure like every customer's gonna know, okay, how much can I save with ddu?

And that's an impossible question to answer. I love that question. Yeah, But I, I guess my, my follow up is like if I enable it, how do I know if I'm seeing the full effects of it yet?

Or if that async process is not yet done running and I should hold my horses to look at my own stats to see how well it's working for me, What we expect is most people are gonna set it up for initial cluster setup, um, in regards to that and just set it across the array. So as you copy data in, you will get more benefit. Now, one challenge with dup as you say, uh, you know, how much, how much data will I get?

DUP is the great question of life. You know, how many roads must man walk down? The answer must be 42 I guess.

But, um, trying to do that one, one thing to keep in mind is two things will unpack this. So one, the more data you put in, obviously the fuller, the more data you put in, this will scale it. The other thing also is you can keep growing that deduplication domain.

And so, you know, as you grow that cluster, the more opport and you add more data, the more opportunity for duplicate data. Um, some people have tried to create various, you know, workflows over the years and say, oh, let's have a Grover agent, or let's pre-scan data, or let's do things. Uh, there's, there's kind of madness in that.

I, I would, you know, anecdotally expect maybe a forex, you know, between compression and ddu. But again, if you're doing full colon VDI, that DDU ratio can go to the moon. If you have encrypted video data, obviously that doesn't ddu well 'cause it's high entropy.

One of the things to think about though is you're from a vsan density. Um, you know, from the scale of this, if you've got one U pizza box servers with 20 NVME drive slots and you're putting 16 terabyte drives in those, and you've got maybe six of those hosts, that's gonna be about the same capacity as the median third party array out there. But you can keep expanding that vsan cluster out.

And these things can grow quite large. I mean, you can have many, many petabytes of raw vsan within a cluster. So these DUP domains we expect to get rather large in capability.

Um, and from a perspective of, you know, sizing that should be able to produce some pretty good deduplication as opposed to the older architecture we have with original storage architecture where that DUP was limited not just even to per host, but per disc group, um, or a per array based dup. And again, comparing that per ESA, if you looked at that, we had those relatively small, um, the original storage architecture also ran inline. It was during the cache D staging and that could be a bottlenecks.

The sustained rights, it was performance negatively impacting. Um, and in regards also with resynchronization, um, if you worked with the old V-C-N-E-S-A, if you had a drive fail, it would fail that entire disk group. So now you could potentially have multiple drives that needed to re-sync with V-C-N-E-S-A OneDrive failure is just OneDrive failure, so that that data just needs to be resynced elsewhere across the cluster in many, many actions.

So we are seeing significantly faster resync operations with this architecture. Um, and the compression by the way does still happen before first, right? And so that actually is partly to help us with network usage efficiency we can press before we hit the network.

Um, so from a activity on this, this is, this feature is coming out with patch one. We are doing some initial, uh, limitations on this request for product qualification. Um, we're gonna require, we want people to have phone home on, and we're also limiting cluster sizes to 16 nodes initially.

We're also wanting to see 25 gig networking at a minimum, which you really should be at in the year 2025. Um, and then we've got some other limitations on features. We're doing additional QA testing.

Any questions on ddu there? I see a high and higher request for encrypted, uh, destroyed. And in that case, deduplication dots doesn't make, uh, much sense.

So it's there. Compliance is requiring encryption storage. Uh, you are correct.

If people encrypt at the application level, then that effectively does break deduplication. That's, um, an inherent limitation of it. However, we do offer data at REST encryption and we do also data in transit encryption.

So vsan, um, ESA by default actually encrypts before it hits the wire, but we will actually apply an additional rotating cipher, much like vMotion encryption, so we can meet the highest of compliance requirements by doing encryption on our side. Again, if you're doing app level encryption, that obviously is gonna have impacts. Um, but we can meet a lot of those compliance requirements using our encryption where possible and hopefully keep that data to where we can still run compression in ddo, but compliance will differ.

Um, some other things to keep in mind is, um, VCF in general, it's support of how we do vsan, um, and broader support of capabilities. Uh, we are now supporting, um, multiple different vsan n deployment types. So we can do single site cluster, we can do what are called disaggregated or storage clusters.

This is the artist formerly known as VSAN Max. So we can have these, um, clusters that basically act as a storage array. And we can also import clusters that are stretch node and import to node cluster.

So historically, VCF, um, it's been a great platform. We've had it for a very long time, but adoption historically was low because we had a very, you know, it was greenfield only. You had to deploy it a very specific way, your existing workloads, you would have to, you know, basically repay vMotion everything in and repave that stuff over.

We now have pretty broad support to import your clusters as they are and meet customers where they are on those capabilities and bring them into the VCF um, lifecycle workflow. And so we have these ability to do these converge and import these clusters and capabilities. Hey John, quick question on the previous slide is probably a little detailed that means nothing, but I noticed that we've got a workload domain that has a stretch cluster in it in here, but the management domain does not appear stretched.

I thought those were, you know, codependent on each other in the past, and maybe it was just a detail that wasn't left in the slide, that you must have a stretched management cluster, uh, to support stretched workload domains. Unless that has changed with VCF nine. You know, I'll have to defer to my VCF team on that, but I believe you can actually import a stretch cluster that is independent of the management being stretched.

I believe that was the case, but, um, I'll have to refer you to docs, so sure. But you're right, that's the kind of like weird rigidity that we've had historically and, and in general is a directional. We're trying to move away from that.

We obviously have strong opinions on architecture and things like that, but we also understand that waiting for someone to depreciate servers for seven years and recycle them in order to adopt BCF, that's gonna take too long. We've gotta meet people where they are. So speaking of storage clusters, um, when I go talk to customers historically, you know, we pitch vsan and say, Hey look, we've got hyperconverge architecture, um, this is great.

And then they'd say, well, you know, I, I have this asynchronous storage workload, or I want to disaggregate, I want to have very small client clusters, maybe for a workload for licensing or other reasons, something like Oracle. Um, and so we came out with a system to be where we can have these storage clusters and segment these. Um, one of the limitations we've had in the past is that all of usan would hear panel traffic through a single VM kernel port.

We now have the ability to disaggregate this. We can, we can just run separate networking. And so you can go build this vsan storage cluster, hopefully using modern 25 or really at this point a hundred gig topex, which is, but then you can have a separate VM kernel port that talks out to the existing, um, hosts over their existing networking.

And what, what you can do here is listen, you've got a legacy environment, it's got 10 gig, you could have one connection that goes into that network, and then you could have a separate backend network used for the VSAN N network and spread this out. And what this looks like in the ui, um, is we have an additional VM kernel port now for that storage cluster, uh, traffic that backend traffic. Um, and as you can see here, if you've followed VMware for a while where I've, we've actually added quite a lot of VME kernel ports over the years.

These things are kinda like Pokemon. We've gotta collect 'em all here. Um, at some point I probably do deserve, uh, for everyone to have a blog that way we create that just explains, again, reminds everyone of what all these things do.

Um, but we also have the vs a n witness also is another one that you can split out. Um, and when you do your cluster setup and you're setting up a storage cluster, you'll want to, um, you'll need to set this up. Uh, so you use the split networking, it's just a single slider that will then prompt you, uh, if you've already assigned those zoom kernel ports.

Um, do you know if there's other settings here like RDMA support and that rest encryption you'd set up at the same time? So from an architecture, what this looks like, um, these storage clusters, we've got the traditional HTI, this is great, but people may not want to do this for many regions. Sometimes it may just be personal beliefs.

They really like having separate storage. We have data source sharing, um, that we released back with, I think it was seven update two to where you can basically borrow capacity between clusters if you have some stranded computer storage. And then we also have fully disaggregated storage.

And this allows you to have discreet compute clusters and build out those storage clusters. And some people may want to go really big with this. I see people create multi petabyte storage clusters.

Sometimes they just wanna have an eight node cluster and they just wanna run three nodes here, five nodes here, or six nodes here for compute. They split that out. Um, it really is up to the customer in terms of their needs, their applications, their workloads.

Um, it is worth noting that with VCF, the customers are entitled to one, uh, tib byte raw, uh, per VCF entitlement. So, you know, if a customer has a thousand cores, they have one petabyte of VS A ns. So there's, for a customer who maybe is transitioning this new licensing, they may suddenly discover they have a lot of vsan.

This is an opportunity maybe where they just go build out a storage cluster and take care of that storage, um, refresh need that they currently have while their existing compute clusters. Maybe they're blades, maybe they're still depreciating them, maybe they just have enough compute, um, they can go run that as they see fit. I did wanna talk a little bit about data protection.

Um, so we have a new, um, VNA vs a n replication capability. This is something that's been asked about for a while. We initially launched a vs a n data protection capability in the eight train.

And this was a built-in snapshot and snapshot retention engine. Um, but as everyone has always said about backups since the beginning of time, um, it's great that you have a copy of that data, but unless that copy is copied somewhere else, a snapshot it by itself is not a backup. Um, it's definitely been a hill that many people, um, wanna stick to.

So going through these capabilities, we've extended the vs a n data protection, um, which is included in the base vsan. That's definitely there. You can create those, uh, GFS schedules, you can create those snapshot retentions, you can set immutability on those.

But we now have the ability to combine this with the VMware live recovery add-on and VMware live recovery for those following along at home is, um, it incorporates, incorporates the product formally known as site recovery manager. We can now replicate those VMs. And so we can set that replication interval.

We can get a, uh, a one minute, uh, recovery point objective. And we can keep not only, you know, a set of, um, you know, GFS on the source side. We can also keep an an X number of snapshots on the target side and that capability.

And we can also set protection groups. Um, and so we can auto automatically create these groups based on things like VM names. So I can have everything with prod and the title, get a specific policy or everything with finance or hr, get a specific policy.

Um, but this allows us to, to do replication, um, and do disaster recovery. And then using the other capabilities of live recovery, the orchestration capabilities, the, the runtime, the testing capabilities, um, we can bring this up. And so this also is helping give us some additional protection, not only from traditional disasters, but also things like ransomwares.

Remember that additional cluster you're replicating to that can be in a separate SSO domain, separate authentication environment and and so forth. To help simplify this deployment, the OVA that's used for vs a n data protection that's used for VS four replication. And that is used for, uh, VMware live recovery.

That's actually all one appliance. Now. We've, we've de-duped the appliance, so to speak, to where you now have one appliance that is serving those multiple functions.

Okay, so you answered a question I had John, which was, would this replace the V four replication appliance that V-L-R-S-R-M customers know and love in the past when they needed to replicate data between vs n data stores? And the answers kind of 'cause it's not the same applies, but it's different functionality. Is that right?

Yeah, it's a different functionality. So in order to, uh, have those scheduled snaps retained on the other side and using the vsan, we are gonna require that license and that capability. But for just basic replication that it's still the same OVA, um, and when you log into it, uh, and, you know, 54 80, you'll actually, or the admin portal, you'll see basically the, it, it does call out that those three services are basically set up there.

Um, but the goal also is if you are going and creating a workflow, um, you can go through and apologize, I don't have a demo for this. I was just getting this up in my lab last week. Um, but when you're creating the, you're setting up this workflow and you create the, the snapshots and then you say, oh, by the way, also replicated and keep this number of replicas, it can also go ahead and pre-populate that into that live recovery console.

Um, so that way it's ready for your run books and those capabilities are there. And I, I will say, again, apologies not having a a UI demo here. The UI is really well thought on this and it, it shows that there's, there's really trying to simplify these workflows and make it easy to protect things and those capabilities.

And what I expect some customers to do is combine some things here, um, potentially using the vsan, um, uh, storage clusters and maybe create like a giant, you know, just storage, um, uh, disaster recovery target in a central location and then maybe fan and, uh, um, replicates from multiple environments in. We're also just improving, uh, some of the capabilities across this. Um, in terms of, we now have, within VCF there is stretch cluster support, uh, for running stretch clusters on top of VCN stretch clusters.

Uh, we also have a new capability to do site-based maintenance mode. So you can basically put an entire site into maintenance mode. This has come up, um, I get this a lot from European customers just 'cause there's so much stretch cluster activity.

They may have a site that they wanted to extend and maintenance and proactively handle that. Um, a third improvement that's come up is, well, we have stretch clusters and those automatically fail over 'cause the witness site manages that quorum. Uh, we have some customers who are concerned about a, a kind of a, a an outer scenario where the witness site fails and then one of the site fails.

Historically, we would, uh, demote the surviving site because split brain protection kicks in. Um, people want to be able to do a forced recovery takeover. And that is something we actually are now going to extend in.

So again, uh, stretch cluster capabilities. This is a true synchronous active active, those virtual machines run on both sides. Uh, they're being replicated, um, in terms of those workflows and in terms of those capabilities, um, those virtual machines.

And you can select a subset of VMs to replicate and do kind of an asynchronous if you wish. Um, but we, we are now giving you the ability to basically put one of these sites completely into maintenance mode and initiate that. Um, and so from we've got these fault uh, domains, we can, uh, select one of these that we want to put into maintenance that will initiate a proactive evacuation.

So DRS will initiate, uh, the motions off of that and then all of those hosts can go into maintenance. There's different reasons. A lot of this is physical maintenance.

People are maybe doing power or other infrastructure maintenance or maybe they're mi migrating one of those two sites or things like that. Um, we do have a lot of pre-checks that, so we will, we'll basically tell you anytime you're putting hosts into maintenance mode or you're putting assigned to maintenance mode will tell you what the impact will be, how much data, uh, potentially has to move. If there were, um, if that that action's happening, and this is available also by API, so that can be, uh, fired off.

I, if a customer wants to use that as a way of testing their DR plan, is that an acceptable use case for that or would you recommend a different kind of workflow? So that is that, that will, because you know, that will basically limit you to running everything from one side and that make sure there's a healthy copy of data on the other side. Um, I mean a true DR plan, at the end of the day, some people really are just gonna want to, you know, throw the breaker to the PDU on one side.

Um, and I respect that some people will just wanna say, okay, we don't actually wanna product 'cause that will trigger that triggers an HA event. Um, yeah, this is, this is definitely a way to do that is do that proactive evacuation and of emotional work and then you'll test your applications and that'll give you awareness. If there's something wrong with networking, maybe someone forgot a vlan or BGP is not pure on the other side or things like that.

And that's the nice thing about a true active active, you know, you can, you can do that. You're not having to initiate a failover. Those data, that data store's globally available on all sites.

Um, the other thing also is this exception case where you have a site failure with a witness fills and then a site failures. Um, we basically have the ability to go initiate that, that takeover, um, and it, it will run pre-checks, it will update the metadata object hierarchy and, and basically crowbar the quorum system to do that. That is a manual intervention.

Um, just because again, we don't want a scenario we're, you know, because of perceived outages from network inconsistently. Um, we don't want to challenge CAP theorem to a dual and end up with both sides active, active. Um, but this is something that we, um, support and what customers have asked for this.

Um, generally this is a pretty extreme scenario. Um, and this isn't something I normally see happen, but it's one of those tabletop exercises we wanna make sure people feel covered in. Um, VCF does have the ability.

Now also, as I said earlier, we have the ability now to support not only vsan um, stretch clusters for storage clusters, but also be able to present those out. And so we can have these, uh, stretch clusters that are providing act, basically acting as a stretch storage platform that then can provide that to stretch compute clusters. And we will have full ha working and site aware and we will optimally, um, route that data so we don't end up doing a lua pathing on the inner site link between the sites.

Um, uh, this is something that has always been a real benefit of vsan. N is, uh, stretch clustering and metros type capabilities has always been really complicated. Um, and, and, and not to throw shade, you know, it's just, it is complicated historically, but vsan N'S made it really easy to configure and it's just baked into the licensing.

There's not additional licensing. Uh, you don't have to use things like FCIP gateways. Um, you, you also get to, you know, you from a quorum device, you've just got a single witness VM that you, you can stand up that's really easy to deploy and it scale down and up.

You can build a two node stretch cluster, um, you know, you can also build a giant stretch cluster. So it's, it's a system that's really scalable and it's, it's interesting, um, just how much adoption on stretch cluster we have. It's, it's very broadly deployed.

Um, very cost effective, easy to do. And remember you can do rate and by default you will, you'll do raid within a site. So you can do that raid five, raid six protection within a site, and then mirror between from a data protection standpoint.

So I wanted to level set. So we've talked about the capabilities, but I also just wanna talk a little bit about where we are at in the year 2025 on storage and the ecosystem and what vsan looks like. So the drives that we're certifying today are TLC and VME drives, and we do support the reed intensive drives.

So these are drives with one drive right per day. Um, the street price I'm seeing on these drives is about 18 cents. If you're buying from a server, OE EMM who has some margin and markup, I'm generally seeing in the low twenties, and this is again before deduplication and compression and unap and thin provisioning and things like that.

Um, so NVME, you know, I know some customers were, were kind of confused when we made V-E-S-A-N-V-M-E only the drives actually don't really cost more than SaaS drives. And when you remove the need for a RAID controller or an HBA, um, NVME effectively is, you know, the same price or cheaper in many cases at this point from a density basis. I'd also encourage you to go look at some of these new hardware form factors.

Um, we're seeing one new pizza boxes with 20 drives supported. Um, there's even some out there are now starting to come out with more drive slots. So if you start looking at 16 terabyte drives and you start putting 20 of these in a host, you know, you're 256 terabytes raw before do and compression stack 30 hosts in a cluster, you know, that's seven point something petabytes raw before data reduction.

Uh, the amount of scale that we can get into a host is incredible. Um, and I'll remind everyone to go look at form factors. 5 inch drives for the past 10 years and they wanna keep buying those.

Uh, we do have these new form factors, um, that are fun and they are supported, and this is how you get 20 of these drives in a one U pizza box. Um, and the density on these drives is, is pretty incredible in terms of capability. So, you know, I've had customers say that HDI, well, it doesn't scale to my needs.

If you can put, you know, again before data reduction over seven petabytes in Iraq, you can, that's, that's quite a lot of storage. In fact, some people are starting to become uncomfortable with just the density, you know, from a blast zone, uh, of, of where all this does, but from a cost basis. Um, you know, if costs, if the, if customer already has VCF and you view it as a sunk cost, your effective cost, you're getting, you know, very, very low.

Um, this isn't something that I, um, I I view as, you know, a, a, a weak area or a concern, um, in regards to that. I think we're gonna be really for, for existing VMware customers who invest in the ecosystem, we're gonna be really one of the lowest cost storage options. And that's just what the drive choices today.

So just want to end on the note here, reminding everybody that vsan is the built-in storage option that comes with VMware Cloud Foundation. And really we're expecting to see a lot of adoption. We're excited about where this is going, and encourage you to check out all the other videos as part of the VCF nine series.

Thank you.