Nutanix Weekly: Just-in-Time Cloud Storage for Nutanix Cloud Clusters

In the first iteration of Nutanix Cloud Clusters, your built-in NVMe storage was the only capacity you could tap into.  With Nutanix's recent announcement of Just-In-Time storage with AWS Elastic Block Storage (EBS) you can now customize the amount of storage you need in a cluster with expansion capabilities.  

In this episode, we talk about the news from a blog post on nutanix.com posted by Dewayne Lessner about EBS with Nutanix Cloud Clusters.

https://www.nutanix.com/blog/just-in-time-cloud-storage-for-nutanix-cloud-clusters

Host: Phil Sellers
Co-Host: Harvey Green
Co-Host: Jirah Cox
Co-Host: Ben Rogers

Transcript

\
Philip Sellers: Hello, everyone, and welcome to another edition of Nutanix Weekly. This is your host Phil Sellers, joined with a great panel of folks here? Another XenTegra podcast with what do we call it? With context.

2
00:00:21.730 --> 00:00:27.710
Philip Sellers: Joined today with Harvey Green, CEO of XenTegra-GOV. Harvey, how you doing?

3
00:00:28.180 --> 00:00:29.990
Harvey Green III: I am pretty good. How are you?

4
00:00:29.990 --> 00:00:35.330
Philip Sellers: Doing pretty well, also join with Jirah Cox, the man, the myth, the legend.

5
00:00:35.470 --> 00:00:36.470
Philip Sellers: Jirah, how are you?

6
00:00:36.738 --> 00:00:40.500
Jirah Cox: Hey, Phil, I'm I'm doing good. I don't feel too legendary, but I'm here.

7
00:00:40.907 --> 00:00:44.569
Philip Sellers: Well, I guess it's better than being infamous right.

8
00:00:45.050 --> 00:00:46.464
Jirah Cox: And it beats being mythical. So.

9
00:00:47.181 --> 00:00:54.890
Philip Sellers: And we we are joined by the mythical Ben Rogers. Then how are you, man?

10
00:00:55.410 --> 00:01:03.729
Ben Rogers: Good for those that are. Seeing this. I am safe. I am in a good location so so don't be worried that I look like I'm in a dungeon, so.

11
00:01:03.990 --> 00:01:04.690
Harvey Green III: We're all good.

12
00:01:06.530 --> 00:01:09.729
Harvey Green III: We were checking on him just a little bit ago, so.

13
00:01:10.020 --> 00:01:19.140
Philip Sellers: Yeah, trying to look for clues. Make sure that Ben's not been kidnapped or otherwise detained against his bill.

14
00:01:19.340 --> 00:01:27.670
Ben Rogers: Wouldn't it be so? Wouldn't it be so impressive to be so important that somebody wanted to kidnap me.

15
00:01:27.956 --> 00:01:33.390
Philip Sellers: Or like my kid told me the other day. You're not a kid. You can't be kidnapped so.

16
00:01:36.370 --> 00:01:40.649
Ben Rogers: Mine would go in 24 h they would want to give you back. They'd be paying.

17
00:01:40.650 --> 00:01:43.145
Philip Sellers: To take you back.

18
00:01:44.283 --> 00:02:00.009
Philip Sellers: Well, guys, thanks so much for joining us. So we're we're here to talk new tanics it. It's another week. Things haven't stopped things are continuing to to move forward new tanics is continuing to

19
00:02:00.030 --> 00:02:10.770
Philip Sellers: to make progress and release new things. And that's that's one of the things we've got today. So we've we've got a new blog post out fresh off the presses

20
00:02:10.780 --> 00:02:21.310
Philip Sellers: just in time. Cloud storage for new tanics. Cloud clusters written by Dwayne Lesner, shout out to Dwayne, thank you for giving us something to discuss.

21
00:02:21.550 --> 00:02:33.496
Philip Sellers: We appreciate all of the contributors and stuff from inside new tanics that are constantly investing in the community and and giving us good information, keeping us surprised. What's going on?

22
00:02:33.900 --> 00:02:37.359
Philip Sellers: so shout out to Dwayne today.

23
00:02:37.360 --> 00:02:45.520
Ben Rogers: Philip, can I interrupt you for something? Because I think I'm going to make the guest of this, podcast, the people that listen to this happy.

24
00:02:45.610 --> 00:03:14.749
Ben Rogers: I'm going to admit that this is a subject I do not know a lot about today, so I am coming here as a new Tannics employee, but as an new Tannics employee I'm looking a service that I really don't know a lot about. So at this point I kind of feel like I'm listening to the podcast, to learn. So for your listeners out there, we don't always come prepared. And we don't always know all the subjects. And this is definitely one that I am not up to speed on. So I'm very much looking forward to the podcast and learning about ebs, storage in in

25
00:03:14.750 --> 00:03:16.149
Ben Rogers: and C 2, cloud.

26
00:03:16.400 --> 00:03:41.329
Philip Sellers: Yeah, th, this is the exciting one. Right? I mean, you know that that's the thing, right? We're talking about things that are brand new there's not a lot of experts, I mean, especially outside of new tanics. This is brand new. This is hot off the presses. You know it. It's been in the wild. At least this blog post has for a whole 5 days. So you know. But none of this stuff

27
00:03:42.500 --> 00:03:57.929
Philip Sellers: magically happens right? I mean, this is part of a roadmap. This is part of a long term plan. You know that that you know, folks in new tanics have been executing on. And so that that's that's the cool part is now we're getting to benefit from

28
00:03:57.930 --> 00:04:12.820
Philip Sellers: from that long term roadmap. Yeah, I mean, as as we talk about cloud clusters and things like that. Let's let's take a quick minute before we jump into the the blog post and let's level set. What is what is the Newtonics? Cloud cluster, Harvey.

29
00:04:14.550 --> 00:04:32.229
Harvey Green III: That is the I won't call it the newest cause. It's not that new, but that is the extension of new tanics and the architecture and the platform to run within the public cloud. Specifically, Amazon aws and Microsoft azure.

30
00:04:32.950 --> 00:04:33.290
Philip Sellers: Yeah.

31
00:04:33.720 --> 00:04:40.539
Philip Sellers: yeah, what? What's different about new tanics, cloud clusters than any other new tanics. Installation, jyra.

32
00:04:42.240 --> 00:04:56.269
Jirah Cox: Actually, shockingly little right? So they run the exact same new text code, right for the hypervisor, the storage fabric, the management layers, the automation as any cluster you'd run on Prem as well. Right? So really, you're just

33
00:04:56.623 --> 00:05:00.870
Jirah Cox: rather than owning hardware in your data center. You're renting hardware in somebody else's.

34
00:05:00.870 --> 00:05:14.744
Philip Sellers: Yeah. So I mean that that's a great level set. And place to start is, yeah, this is the same new tanks we know and love from on. Prem. It's just now sitting in someone else's data center. In this case, aws and azure.

35
00:05:15.628 --> 00:05:17.659
Philip Sellers: So you know that

36
00:05:17.670 --> 00:05:33.593
Philip Sellers: that you know back to Ben's Point, you know. Start there, really. What are we talking about? Where are we talking about it? You know, for the purposes of this blog post. We're gonna be spending a lot of time talking about aws, because that's where the new innovations happening

37
00:05:34.030 --> 00:05:43.250
Philip Sellers: from this topic. So, Gyra, why don't you kick us off and tell us a little bit of what? What's the news here? What's the news in in C 2.

38
00:05:44.440 --> 00:05:48.880
Jirah Cox: Yeah, or maybe even Why.

39
00:05:49.040 --> 00:05:55.269
Jirah Cox: why is this so great to have right? And what's the cut? The circumstances where customers would want to use this right? So

40
00:05:55.470 --> 00:05:59.150
Jirah Cox: one more, one more. Compare and contrast right with

41
00:05:59.380 --> 00:06:14.319
Jirah Cox: with running clusters on Prem, when when you on the hardware was in your data center. Right? You can assign a human to go touch that hardware, change it any way you want to. Right? Specifically, like, you know, maybe increase the size of the storage. There, right pop in pop in some new Ssds. Or whatever to grow a cluster

42
00:06:14.330 --> 00:06:17.020
Jirah Cox: and expand that storage pool

43
00:06:17.040 --> 00:06:18.060
Jirah Cox: resource

44
00:06:18.280 --> 00:06:37.070
Jirah Cox: with, of course. A rented node in aws at the bare metal layer. There you have a few options of of flavors of bare metal node type, but it is still off of a menu. Right? You're gonna get this node or that node. It's gonna have certain dimensions, certain parameters storage being one of them. And there's really kind of no

45
00:06:37.310 --> 00:06:58.869
Jirah Cox: size of check. You can write no human, you can call to say, Hey, can you go? Add 2 more Ssds to these nodes in that data center for me, please. And thank you right like, that's gonna go nowhere. So the hardware configurations kind of locked. So then, how do the the scenario right for our customers is, how do we help giving help? Our customers enjoy the same kind of flexibility right to

46
00:06:59.332 --> 00:07:04.517
Jirah Cox: to create clusters that are tailored to their needs. CPU memory storage

47
00:07:05.280 --> 00:07:16.709
Jirah Cox: when they move to say from an on-prem data center or a colo into public cloud. And so that's where that's the the use case for this right? That where we we haven't had that before. If a customer wanted to say replicate

48
00:07:16.890 --> 00:07:37.680
Jirah Cox: workloads to Nc, 2, cause that's pretty fashionable these days, right? Using, you know, owned resources on Prem in a primary data center. But a lot of customers look at it and say, Hey, I don't wanna do a Dr. Data center anymore. Move my Dr to the cloud, right? I wanna rent that instead or use that as my first kind of cloud workload as my Dr. For my on prem vms.

49
00:07:37.820 --> 00:07:44.781
Jirah Cox: so if we come back to them with a customer, to the to the customer and say, Here's a design for you, you know you maybe you need

50
00:07:45.320 --> 00:07:51.870
Jirah Cox: 3 or 4 nodes worth of hardware to run your vms, but you might need 6 nodes or 8 nodes.

51
00:07:51.870 --> 00:07:52.490
Philip Sellers: With the.

52
00:07:52.490 --> 00:08:00.339
Jirah Cox: Storage based on this cookie cutter node size to store your Vm. Data. Well, now, the customer is paying quite a bit of money for those

53
00:08:00.440 --> 00:08:06.189
Jirah Cox: 4, 5, 6, 7, 8 nodes that are just there for data storage. And aren't there for the compute side need.

54
00:08:06.280 --> 00:08:15.519
Jirah Cox: or they're not needed for application they're only needed, maybe during an activation of the Dr. Environment, right? So then, paying for them all the time, is a bit prohibitive.

55
00:08:15.870 --> 00:08:23.999
Jirah Cox: So that's kind of the scenario of like helping customers out that that this feature now is kind of justified by and kind of born into right. That's the context.

56
00:08:24.430 --> 00:08:47.530
Philip Sellers: Yeah. And and you, you pointed out something. I think that's really important. This often comes up when we're talking to customers about Dr. Scenarios. So we're talking about rehosting an entire workload into Nc, 2, those generally make sense. You need the number of nodes you need based on computer based on storage. Th. Those use cases make a lot of sense because

57
00:08:47.530 --> 00:08:58.870
Philip Sellers: you're gonna need and consume all of that upfront. But with Dr. You just need a place to land that data. You're not necessarily always going to need the compute to go with it.

58
00:08:58.870 --> 00:09:04.759
Philip Sellers: And so there's this out of balanced thing that happens between

59
00:09:04.780 --> 00:09:10.269
Philip Sellers: your node, because generally they don't have enough storage for for that particular use case.

60
00:09:11.270 --> 00:09:12.110
Philip Sellers: You know.

61
00:09:12.460 --> 00:09:29.049
Philip Sellers: we're talking about aws today, but I know Harvey and I have worked on a couple of deals where we had an azure customer, and there's even more restrictions on the azure in C 2, because there's 2 node types as opposed to. I think we're up to 6 or 8

62
00:09:29.170 --> 00:09:32.570
Philip Sellers: in aws. Now, is it 6?

63
00:09:32.980 --> 00:09:33.429
Philip Sellers: Something that.

64
00:09:33.650 --> 00:09:34.310
Jirah Cox: For sure. Yeah.

65
00:09:34.521 --> 00:09:35.998
Philip Sellers: We we would have to actually go.

66
00:09:36.210 --> 00:09:37.000
Jirah Cox: Correctly accurate.

67
00:09:37.510 --> 00:09:38.020
Philip Sellers: Yeah.

68
00:09:38.020 --> 00:09:39.110
Harvey Green III: Yeah, we have to.

69
00:09:39.110 --> 00:09:40.329
Jirah Cox: I can look at it for you.

70
00:09:41.960 --> 00:09:48.200
Philip Sellers: But there's at least more variety to choose from. But again, in Dr. Use cases it doesn't

71
00:09:48.310 --> 00:09:53.803
Philip Sellers: quite fit. So I think that's that's a great way to set up the discussion.

72
00:09:54.840 --> 00:09:56.789
Philip Sellers: so I'm not gonna

73
00:09:57.120 --> 00:10:01.060
Philip Sellers: make us wait any longer. What are we announcing? Jyar.

74
00:10:01.740 --> 00:10:11.530
Jirah Cox: So so with this new feature here, right? With the ability to to connect ebs here, which is like the elastic block storage right additional block storage that exists

75
00:10:11.570 --> 00:10:15.670
Jirah Cox: outside the customer's nodes, but still within the parameters of Aws.

76
00:10:15.710 --> 00:10:25.749
Jirah Cox: You can now attach block storage to the Newtonics, nodes to create additional storage right to present more additional storage, basically

77
00:10:25.800 --> 00:10:37.619
Jirah Cox: very much akin to the scenario I talked about before, where you would just pop in additional Ssds into nodes that you own nodes you control same kind of outcome now available. Now for cloud clusters as well.

78
00:10:37.620 --> 00:10:56.799
Jirah Cox: This gives you a lot more flexibility. As you design this to say, I don't need a lot of compute for perhaps for Dr. Right. All I'm only gonna run is like 90 Cvms to Host Cloud Storage and be my replication target. And I just want all the storage I can talk to. Then to replicate as my as my actual data tier. There.

79
00:10:57.330 --> 00:10:57.740
Philip Sellers: Yeah.

80
00:10:58.700 --> 00:10:59.260
Philip Sellers: for those.

81
00:10:59.260 --> 00:11:02.720
Harvey Green III: I mean confetti and special effects.

82
00:11:03.100 --> 00:11:04.540
Harvey Green III: And there's what you're.

83
00:11:04.540 --> 00:11:05.987
Jirah Cox: Dressing, good day.

84
00:11:07.870 --> 00:11:12.461
Philip Sellers: Yeah, I mean, we, we we need a sound machine for this podcast.

85
00:11:16.570 --> 00:11:17.680
Jirah Cox: We'll we'll put that in.

86
00:11:17.680 --> 00:11:19.170
Harvey Green III: Not scared of where that would

87
00:11:21.025 --> 00:11:21.760
Harvey Green III: good.

88
00:11:21.760 --> 00:11:25.629
Jirah Cox: I'm sure, the podcast host can put that in in the edit, right? There is an edit phase right.

89
00:11:26.381 --> 00:11:31.128
Philip Sellers: Yeah, there, there's strictly no editing on this one, right?

90
00:11:33.880 --> 00:11:34.660
Harvey Green III: Hey! Man!

91
00:11:34.660 --> 00:11:35.169
Philip Sellers: But have you.

92
00:11:35.170 --> 00:11:37.981
Harvey Green III: We got one tape, just one.

93
00:11:38.450 --> 00:11:39.250
Philip Sellers: What, what's why.

94
00:11:39.250 --> 00:11:39.870
Harvey Green III: In.

95
00:11:41.217 --> 00:11:41.989
Philip Sellers: No, I mean.

96
00:11:41.990 --> 00:11:42.390
Harvey Green III: Come on!

97
00:11:43.030 --> 00:11:57.840
Philip Sellers: It's fantastic, I mean. Now, now you've got that extensibility right? So particularly for the Dr. Use case, you add the extra block storage you need takes some planning, some sizing on the front end. But now you can accommodate that in

98
00:11:58.587 --> 00:12:12.100
Philip Sellers: what we would call a pilot light cluster. You know. Is that a a term that's well known, I guess I mean Pilot light when we start talking about Dr. I mean, do you guys know what that refers to?

99
00:12:12.610 --> 00:12:13.769
Philip Sellers: Yeah, it's just a.

100
00:12:13.770 --> 00:12:14.120
Jirah Cox: Yeah.

101
00:12:14.120 --> 00:12:15.340
Harvey Green III: The frameworks.

102
00:12:15.380 --> 00:12:24.709
Harvey Green III: I I've actually heard more people referring to it that way outside of conversations that I've had before. And I was like, oh, there! I'm not the only one that says this alright cool.

103
00:12:24.710 --> 00:12:40.249
Philip Sellers: Yeah, and that that's kind of the point of reference, right? Like, it's sort of like a pilot light on your stove or on your gas logs or something. It's there running and waiting for you to turn the switch on and need to to turn it on.

104
00:12:40.270 --> 00:12:56.089
Philip Sellers: And that way you're ready to go when when you turn on the switch. And so it's a minimal cluster in terms of Newtonics. But that makes a minimal cluster now much more powerful, much more valuable to the customer. So

105
00:12:56.996 --> 00:13:00.193
Philip Sellers: this is cool stuff, I mean, where?

106
00:13:01.280 --> 00:13:04.119
Philip Sellers: where do you see? Additional

107
00:13:05.023 --> 00:13:09.259
Philip Sellers: capabilities? Kind of coming in. From your perspective, Harvey.

108
00:13:10.420 --> 00:13:13.730
Harvey Green III: I mean ultimately for me. This, this is

109
00:13:14.560 --> 00:13:18.900
Harvey Green III: this is protection against all the stuff you don't know is coming.

110
00:13:19.771 --> 00:13:35.329
Harvey Green III: Because you go and design this, and you can design it as accurately as you want to all day. But there will be things that you did not account for that somehow have to get taken care of. And this is this is your get out of jail free card.

111
00:13:36.880 --> 00:13:58.610
Philip Sellers: And Ben, I'll throw it to you. I mean, as you're working with customers. I know as I'm working with customers. Future proofing is a big part of what we do when we do sizing and create, you know, configs for them. Being able to slide it, I mean, like Jyra said. I mean being able to effectively slide in more capac. I mean, how how huge is that for cloud.

112
00:13:59.100 --> 00:14:13.199
Ben Rogers: Well, it's gonna be huge for us, particularly. I'm I'm speaking now on the sales end. You know. We've done a lot of deals where the nodes, the the clusters got heavy, compute, wise because we were trying to

113
00:14:13.210 --> 00:14:15.520
Ben Rogers: facilitate a storage problem.

114
00:14:15.590 --> 00:14:34.129
Ben Rogers: And so now, with our ability to add storage to these clusters. That's going to be great, because now we don't have to inflate the the compute costs anymore, we can really look at what are the services that the workloads needs and properly design them. So from from an it configuration perspective. This is going to be awesome.

115
00:14:34.130 --> 00:14:48.850
Ben Rogers: I do have a few questions about this. I see in the drawing here that we're adding this storage directly to the nodes. So essentially to Java's comment, this is like popping in some extra SSD or Nvme. To these these nodes

116
00:14:49.090 --> 00:15:12.800
Ben Rogers: gyra, do we have to add equivalent storage to each node? Or can you explode one node or kind of give us an idea of how does this peanut butter spread across the cluster? Is it, you know, done? Each each node's gonna get an additional ebs slice, or we could have one ebs on one node and the other nodes. I'm kind of confused there of how we would architect this.

117
00:15:13.890 --> 00:15:28.420
Jirah Cox: Yeah. So details, of course, do matter right? So the article calls out at at this point we're gonna look at adding the search to the nodes in the cluster with uniformity. Right? So what? That? Every node in the cluster also just one more point, which is not

118
00:15:28.570 --> 00:15:41.960
Jirah Cox: a huge consideration. But it's a minor consideration is that this is a cluster creation, time decision. Now, that's also pretty easy to deal with, right, because with this ability to have this hardware on demand.

119
00:15:42.010 --> 00:16:08.430
Jirah Cox: moving from cluster size to cluster size and moving those workloads within a cloud. Az actually is way easier, right? Because there's not that whole on prem data center experience of, like, I order a truckload of new nodes to live next my old nodes not to do something with the old nodes. No, we're just gonna for a few hours rent 2 different clusters move workloads over and move from, you know, profile A to profile. B, so it's not like quote like a hot, add exactly the end. The outcome is the same as adding those as a sees to a node.

120
00:16:08.430 --> 00:16:13.460
Jirah Cox: but the workflow to get there is a little bit different than just popping them in, because, of course, it is different.

121
00:16:15.580 --> 00:16:27.200
Philip Sellers: And that's a shout out to native data services, right? You can just use built in replication. And all of the great things we know from a Dr. Perspective to move from one cluster to another.

122
00:16:28.050 --> 00:16:46.019
Jirah Cox: Totally. It's a very it's a very much cloud. Principles fail. Forward. You know. Declarative infrastructure version of of the same outcome. Right of get more storage versus a sort of day. 2 pets operation of like find a way to do it, you know, while the airplanes in the sky.

123
00:16:46.020 --> 00:16:46.680
Philip Sellers: Yeah.

124
00:16:47.186 --> 00:16:52.213
Philip Sellers: sort of like, yeah, versus refueling in the sky. I like that.

125
00:16:54.324 --> 00:17:05.432
Philip Sellers: Yeah. So the ebs is attached. It. It looks like in different mount points. I mean I I know the listeners can't see it. The blog post has got a great

126
00:17:05.790 --> 00:17:17.409
Philip Sellers: visual here that been mentioned. That kind of shows the Ec 2 bare metal hosts, and you got your controllers, your Hv, your user vms, and then the storage controller with different

127
00:17:17.619 --> 00:17:23.899
Philip Sellers: are those mount points, one for Hv. One for the Cbm. Local storage and remote storage.

128
00:17:24.599 --> 00:17:27.689
Philip Sellers: Is that effectively how it happens under the covers.

129
00:17:28.770 --> 00:17:40.830
Jirah Cox: Yeah. The neat thing is that is what's really cool here, right? Is that ebs storage when it's presented to the nitro card in aws, basically just looks like a local block device, right? So we really haven't had to teach

130
00:17:40.860 --> 00:17:47.180
Jirah Cox: no disrespect to engineering. And all the work put into this feature and testing it and qualifying it for customers.

131
00:17:47.180 --> 00:18:12.450
Jirah Cox: But it's not like we had to go teach Zvm to go speak a whole new language here. Right? It's basically go find other local block storage within the node and make it part of a usable cluster which we've been doing since, literally day one of the company right? So anything calls out here. In kind of the way. The stargate, which is our main. I/O handler, handles the storage right is very similar to like a node that would have physically present local Nvme and physically present local SSD.

132
00:18:12.450 --> 00:18:34.460
Jirah Cox: Of course those are both fast, but one is a little bit faster. So that's where rights are gonna land, and then d stage down to the SSD tier, similar here. If there's local Nvme in the box and then ebs attached to it. All that all that Nvme locally is, of course, tab it faster, a lot more local. We'll use that first and then spill down over to the that ebs storage.

133
00:18:35.563 --> 00:18:47.740
Ben Rogers: Driver! What that's telling me is our data locality, and all the goodness that we have built inside the cluster still remains the cluster smart enough to figure out if the load needs to be on local storage or on this ebs storage.

134
00:18:49.412 --> 00:19:08.699
Jirah Cox: Right? Of course, I mean, that was the first real data handling data governance trick, right? Was understanding. What is the hottest part of data and keeping that as localized and as close to work. What is possible. Right? Remember how we started the company right was with nodes that might have, like, say, 100 gig SSD. And like 2 2 TB spinning disks.

135
00:19:08.700 --> 00:19:27.459
Jirah Cox: not a whole lot of of very hot storage there, right? So we had to be pretty darn sure. What was the hot tier storage? What needed to go there? And, by the way, that SSD. Would cost you like 10 grand for a hundred gig back in the day. That was the long pull in the tent of the hardware bomb. So even though, of course, as as

136
00:19:27.690 --> 00:19:40.869
Jirah Cox: data center. Hardware has evolved over time right and cost per gig has come down dramatically. Our data placement engine, right of profiling storage and knowing what needs to be placed. The closest to the workload, of course, still has value, and still is in place.

137
00:19:42.810 --> 00:19:54.070
Philip Sellers: So someone coming into the aws conversation, can you tell us a little bit more about that nitro card? W. What is that? Actually cause

138
00:19:54.110 --> 00:20:02.140
Philip Sellers: it it, you know. Like many things in in the Aws Arsenal, it has branded names, and that may not actually explain what it's doing here.

139
00:20:03.000 --> 00:20:21.590
Jirah Cox: Yeah. So great question. I'm I'm I'm almost as much of a lemon as probably everybody else in the call. But my view of the world. Right? Is that the nature card? It's it is the dpu right, the super fancy Nick, within the node right that makes that allows aws to do all of the awesome Aws stuff

140
00:20:21.590 --> 00:20:38.199
Jirah Cox: at the data center level for the hardware. Right? So that's where your networking gets handled. In this case also storage as well, so things that they can do like that present external storage as a local device. Of course, that's because the the nitro card itself is custom. Silicon. You really you only get nitro nix

141
00:20:38.260 --> 00:20:45.609
Jirah Cox: within aws, right? It's not not hardware. You can run in your own data center, but it's part of what helps them run, run their cloud at scale as hyperscaler.

142
00:20:46.260 --> 00:20:46.880
Philip Sellers: Yeah.

143
00:20:47.100 --> 00:20:52.919
Philip Sellers: so we can think of it as sort of like a cross between a out of band management

144
00:20:53.220 --> 00:20:55.193
Philip Sellers: interface and

145
00:20:56.920 --> 00:21:00.309
Philip Sellers: a physical Pci device because it sits on the Pci.

146
00:21:01.965 --> 00:21:02.360
Jirah Cox: Sure.

147
00:21:02.360 --> 00:21:03.130
Philip Sellers: Yeah, on the PC.

148
00:21:03.130 --> 00:21:04.310
Jirah Cox: Haven't been

149
00:21:04.400 --> 00:21:07.799
Jirah Cox: in band overlay underlay

150
00:21:08.030 --> 00:21:23.019
Jirah Cox: plus what if you squint? I guess it could play the role of an external storage. Hba, plus like sas expander like, it's sort of all of that rolled into one. Because ultimately all those things are just software definable functions, right?

151
00:21:23.410 --> 00:21:33.599
Jirah Cox: And of course, everyone at aws now is rolling their eyes at our, at our terrible analogies for their I'm sure awesome silicon that they're very proud of.

152
00:21:34.337 --> 00:21:39.469
Harvey Green III: You get the nitro button when you want something to be fast.

153
00:21:39.825 --> 00:21:40.180
Philip Sellers: Yeah.

154
00:21:40.480 --> 00:21:42.120
Philip Sellers: Yeah. It's a very quick.

155
00:21:42.120 --> 00:21:44.249
Jirah Cox: Your other technology, badly described.

156
00:21:47.410 --> 00:21:56.179
Philip Sellers: But it's the smarts, I mean, I I think this sum up what you just said. It's the smarts that makes this really a a composable

157
00:21:56.921 --> 00:22:04.150
Philip Sellers: just to throw out another buzz word in the infrastructure industry. But a composable type of hardware.

158
00:22:04.460 --> 00:22:08.190
Philip Sellers: So again, back to what you're saying about software defined.

159
00:22:08.310 --> 00:22:21.239
Philip Sellers: You can take this and and turn it into something more through the software. And that's what the power of the new tax platform on the spare metal is actually giving to us is that composability to make this into a

160
00:22:21.570 --> 00:22:27.020
Philip Sellers: much more useful form than its native components?

161
00:22:30.080 --> 00:22:31.080
Philip Sellers: you know.

162
00:22:31.350 --> 00:22:39.930
Philip Sellers: we talk a little bit more in this this blog about, you know, adding and tearing that we've already covered.

163
00:22:40.030 --> 00:22:44.879
Philip Sellers: Let's talk a little bit about the the on demand growing.

164
00:22:45.710 --> 00:22:53.570
Philip Sellers: you know, from a Dr. Use case, we've got that 3 node pilot light cluster. What happens when

165
00:22:53.680 --> 00:22:59.289
Philip Sellers: we want to do more or when we need to expand like, what does that look like.

166
00:23:00.170 --> 00:23:25.599
Jirah Cox: Yeah, a really cool outcome that this feature now gives us is that before we had really one way to grow a cluster, and that was to literally grow, grow the cluster pop in more nodes which we did add support for mixing node types in the cluster in the past that was really great to have. So you could have larger nodes to start with, and then maybe add more compute heavy nodes. Over time. Now we have 2 ways to grow a cluster right? That one stays. The first one stays on. The truck of you can always add more.

167
00:23:25.600 --> 00:23:26.290
Philip Sellers: One ghost.

168
00:23:26.290 --> 00:23:48.120
Jirah Cox: Cluster. But now, if you have a cluster that has this ebs feature attached to it, you can also scale up the ebs storage itself. So if you just needed more storage, then whole separate lever candidly, whole separate price point for scaling, there to say, just add more storage to a cluster without needing to to reach for the add more compute, add more nodes solution as well.

169
00:23:48.400 --> 00:23:50.569
Jirah Cox: So great ways to solve more problems.

170
00:23:50.890 --> 00:24:01.200
Jirah Cox: And what's cool now is the article calls out that you can actually attach, you know, really a dramatic amount of storage here. Right? So we we still use our kind of rule of thumb here of, we want to see about 20%

171
00:24:01.200 --> 00:24:23.779
Jirah Cox: of the cluster storage stay within the nodes. Right? We don't wanna run with a hundred percent fully ebs storage. But you can have up to 4 x as much attached to it, right? So you can have 20% locally in the box, 80% off on ebs. So that's really a, a very large amount of storage. And B very cost effective in terms of that, that tier that you're gonna use there for that storage as well.

172
00:24:24.650 --> 00:24:27.340
Ben Rogers: So, Jarra, I want to make sure. I understand. Here

173
00:24:27.380 --> 00:24:54.939
Ben Rogers: we have to make a decision to use ebs storage at the time of its of cluster creation. So I know I'm building a Dr. Cluster. I know I'm gonna want to use some ebs. I want to go ahead and establish that at the time of build. But you're also telling me that when I have to, and when I have to declare a disaster that I can grow these ebs storage loans dynamically. They can be. They can be increased on the fly as I'm bringing up my disaster, recovery, scenario.

174
00:24:56.190 --> 00:25:17.919
Jirah Cox: Yeah. So you definitely can scale up the Ebs storage at a later time. Let's call that here in the article. I would think what's probably more realistic. There, Ben is. You could add more nodes for a Dr. Disaster right? When you need more compute. You. But of course you can. You can scale up the ebs at any time, right? But that would be more, for like a data growth handling, and then and then light up more nodes. If I need more compute, then my pilot, like cluster, might be able to handle

175
00:25:18.430 --> 00:25:20.749
Jirah Cox: from the the CPU memory side of things.

176
00:25:21.770 --> 00:25:31.390
Ben Rogers: Awesome. I was worried. You were gonna say that we would have to do another, you know, new cluster with new new sizes and migrate over there. It's good to see that we can expand it on the fly, though.

177
00:25:32.230 --> 00:25:50.060
Jirah Cox: Yeah, yeah, that's just for the get to no ebs attached to have ebs attached shift. And of course, if you're listening to me like. If if you're thinking about this, I would say, this is probably gonna become a pretty instant. Best practice to say, attach a minimal amount of ebs to your cluster whether you think you're gonna need it or not, because over time you're probably gonna change your mind.

178
00:25:50.060 --> 00:25:50.500
Philip Sellers: Yeah.

179
00:25:50.500 --> 00:25:54.379
Jirah Cox: Do need it. So start with that attached. To begin with.

180
00:25:55.270 --> 00:25:55.850
Philip Sellers: I'm away so.

181
00:25:55.850 --> 00:25:57.850
Harvey Green III: Price is definitely Harvey approved

182
00:26:00.830 --> 00:26:01.930
Harvey Green III: of the day. It's.

183
00:26:01.930 --> 00:26:04.180
Philip Sellers: So, Kid tested. Harvey approved.

184
00:26:05.950 --> 00:26:23.841
Philip Sellers: Yeah, no, I mean, I think that's great advice. I mean, anyone looking at Nc to, you know, putting in a minimal amount of ebs just buys you flexibility. So you know you you do have the ability to grow it. That's that's huge. And honestly. The first time I read through this I missed that point. So

185
00:26:24.715 --> 00:26:26.350
Philip Sellers: that's another great

186
00:26:27.620 --> 00:26:28.630
Philip Sellers: great

187
00:26:28.700 --> 00:26:30.099
Philip Sellers: feather in the cap.

188
00:26:31.250 --> 00:26:36.139
Philip Sellers: you know one of the points here is that it can be orchestrated with prism. Central?

189
00:26:37.490 --> 00:26:40.199
Philip Sellers: and that's also a huge

190
00:26:40.220 --> 00:26:46.599
Philip Sellers: advantage. Because we're going to use calm. We're going to use automation during those Dr. Events hopefully.

191
00:26:47.035 --> 00:26:51.760
Philip Sellers: to orchestrate things. So you can create a playbook that that also gives you that

192
00:26:51.840 --> 00:26:53.410
Philip Sellers: ability to

193
00:26:53.740 --> 00:26:57.699
Philip Sellers: to increase capacity. So it's just another avenue

194
00:26:57.810 --> 00:26:59.777
Philip Sellers: to meet your need.

195
00:27:01.020 --> 00:27:08.399
Philip Sellers: The net outcome, though from a financial standpoint, is important, too. You mentioned it, but I don't want to make sure that

196
00:27:08.850 --> 00:27:14.030
Philip Sellers: you know it doesn't get explicitly called out again. I see Harvey shaking his head. Do you want to take this one? I mean.

197
00:27:14.490 --> 00:27:15.870
Harvey Green III: I think it's.

198
00:27:15.870 --> 00:27:18.270
Philip Sellers: It's a huge point to point out.

199
00:27:18.440 --> 00:27:22.770
Harvey Green III: Yeah, I'll I'll break it down to be very simple.

200
00:27:23.930 --> 00:27:29.593
Harvey Green III: More storage costs less than more nodes to get storage.

201
00:27:31.020 --> 00:27:32.260
Philip Sellers: Yeah, and especially.

202
00:27:32.260 --> 00:27:33.950
Ben Rogers: Pay attention to performance.

203
00:27:34.320 --> 00:27:35.140
Ben Rogers: Well, yes.

204
00:27:35.140 --> 00:27:45.449
Philip Sellers: Especially when we see these Dr. Scenarios on aws a lot of times the the licensing that goes along with it plus the node itself.

205
00:27:45.660 --> 00:27:50.920
Philip Sellers: it becomes a cost prohibitive kind of thing. Now, with a 3 node cluster.

206
00:27:50.980 --> 00:28:00.080
Philip Sellers: you've got everything you need for a Dr. Scenario, so it's really a great recipe for that elastic Dr. And that's

207
00:28:00.140 --> 00:28:13.469
Philip Sellers: there's another graphic here in in the the blog post that that shows the elastic Dr, you know, grow grow basically multiple different ways. You've got your base. You add more storage from ebs

208
00:28:13.560 --> 00:28:16.510
Philip Sellers: until you, Max, that out. And then you can add more nodes.

209
00:28:17.270 --> 00:28:25.270
Ben Rogers: Man. This is scream. I know we're talking a lot about Dr. And the articles geared towards Dr. But this is also screaming test dev staging.

210
00:28:25.310 --> 00:28:31.579
Ben Rogers: I mean, this opens up the door for development, getting development off site into cloud. I mean, this is

211
00:28:31.590 --> 00:28:34.180
Ben Rogers: this is going to be exciting for sure.

212
00:28:34.960 --> 00:29:01.450
Philip Sellers: That also opens. You know, for me, as I think about this other types of workloads, maybe imaging and packs where they're very storage heavy that weren't necessarily compatible with the the storage, the node types that we had inside of Aws. This may be a great way of doing some of that, and tearing it down to a less expensive tier of of storage, maybe not having to be all in in Vietnam.

213
00:29:01.610 --> 00:29:05.429
Ben Rogers: We were riding the Nus bus last week. So it sounds like we're getting back on it this week.

214
00:29:08.390 --> 00:29:20.980
Philip Sellers: Yeah, I mean again, I mean, there's so many good use cases. And now we're talking Dr. Here. Because that really taps into the flexibility of this announcement. But there's other use cases for sure.

215
00:29:22.030 --> 00:29:23.010
Harvey Green III: Absolutely.

216
00:29:25.740 --> 00:29:35.550
Philip Sellers: I'm drawing a blank at this point. So, Harvey, you wanna save me here. What else is? Goodness that we should we should talk about.

217
00:29:37.386 --> 00:29:39.009
Harvey Green III: I mean, this is.

218
00:29:39.240 --> 00:29:44.030
Harvey Green III: you know. Again we we talked about a little bit. This is overall, just another.

219
00:29:44.100 --> 00:29:48.119
Harvey Green III: a another play of flexibility. Another play at being able to

220
00:29:48.240 --> 00:29:59.460
Harvey Green III: go out and attach more storage to what you have node wise? Again. Just you know how I am. I I want flexibility always. I never wanted to

221
00:29:59.850 --> 00:30:08.449
Harvey Green III: into a corner this. This allows you definitely a way to get out. If you end up having to drag a bunch of data and

222
00:30:08.530 --> 00:30:19.599
Harvey Green III: don't have enough storage to do that with from how things were before. Now, you've got the ability to just add that as you need it, which makes a huge difference.

223
00:30:20.190 --> 00:30:29.330
Philip Sellers: Yeah, flexibility is the underscore. Just another way. I think you you summed that up nicely, gyra. You know you've got

224
00:30:29.340 --> 00:30:34.549
Philip Sellers: so many ways to grow. Now, this is just another great enhancement.

225
00:30:36.450 --> 00:30:37.950
Philip Sellers: final thoughts, guys.

226
00:30:39.880 --> 00:30:47.379
Ben Rogers: So barrier remover to me. To be real honest with you. This has been a barrier that we've had with customers trying to get them. Then C, 2.

227
00:30:47.380 --> 00:31:10.280
Ben Rogers: The second point I'll make. And we talked a little bit about this on the last podcast is that this is where new tanics. Really, this is, this is our home. Man is data management. And so this is just another example of how you know, we're looking at the zeros and ones. We're con, we're containing the zeros and ones we're managing the zeros and ones. And this is just adding to that story. So again falls right into Willhouse what we're good at doing.

228
00:31:10.280 --> 00:31:34.250
Ben Rogers: managing data, the zeros and ones and man gives us a, you know, more opportunity and flexibility in our cloud services. I can't wait to see something like this come to the azure side and and, man, I'm excited to see that happen in the next, you know, whenever that's supposed to come. But this is good stuff, man. I'm very excited to see this come to market, and will make my job much easier when I'm communicating solutions to our customers in Nc. 2.

229
00:31:35.100 --> 00:31:35.770
Philip Sellers: Yeah.

230
00:31:37.650 --> 00:31:40.910
Philip Sellers: yeah, nitro nitro powered in this case.

231
00:31:47.550 --> 00:31:50.949
Philip Sellers: gyra, anything else you'd want to add for

232
00:31:51.080 --> 00:31:52.770
Philip Sellers: for our topic today.

233
00:31:53.660 --> 00:32:10.929
Jirah Cox: I'd say, if this is compelling, I'd say, give it a try kick give it a test track. Kick the tires you can go from literally hearing my voice to having a cluster running in aws in about 2526 min, so faster than you really would expect so you could prove this out to yourself. Pretty darn fast.

234
00:32:11.830 --> 00:32:23.764
Philip Sellers: Yeah, that that's a great point. And again, I mean, it's still powered by the same underpinnings. It still has all the same great advanced features on top of it. So

235
00:32:24.600 --> 00:32:32.429
Philip Sellers: it's it's that true portability, you know. Same services, same operational thing at, you know, we were having a customer discussion

236
00:32:32.610 --> 00:32:34.470
Philip Sellers: last week, and

237
00:32:34.500 --> 00:32:51.450
Philip Sellers: really came down to how do you operate? And operating the same way across multiple different destinations, multiple different clouds not having to adapt for the individual sort of things in each cloud. So a lot of power in that

238
00:32:52.940 --> 00:33:14.619
Philip Sellers: lot of power. Well, guys, I wanna say, thank you so much for joining us today to talk about ebs storage within C 2 clusters on. Aws, this has been interesting. I was looking forward to today's conversation. So I wanna thank you all for listening. And thank you guys for joining into the conversation.

239
00:33:15.460 --> 00:33:16.619
Philip Sellers: Thank you, Philip.

240
00:33:16.970 --> 00:33:18.609
Philip Sellers: Until next year goes

241
00:33:19.040 --> 00:33:22.629
Philip Sellers: we will see you on the next podcast thanks. Everyone.