Latest / Nutanix Weekly / Nutanix Weekly: Simplifying Access to Geo Distributed Object Data Using Global Namespaces

Transcript

Nutanix Weekly: Simplifying Access to Geo Distributed Object Data Using Global Namespaces · Nutanix Weekly

1 00:00:03.420 --> 00:00:22.199 Philip Sellers: Welcome to Episode 70 of Nutanix Weekly. I'm your host, Phil Sellers. I am a solutions architect here at XenTegra, and I'm happy to have 2 great Nutanix resources on the line with me today I've got Jirah Cox, and I've also got Ben Rogers. 2 00:00:22.540 --> 00:00:24.739 Philip Sellers: Ben, Jihra, how are you guys doing today? 3 00:00:25.190 --> 00:00:26.210 Jirah Cox: Good, thanks, Phil. 4 00:00:27.120 --> 00:00:29.059 I'm doing great, Phil, I appreciate it. 5 00:00:29.190 --> 00:00:34.900 Philip Sellers: So then you were just telling us before we started, you just getting back off a vacation. You've been out 6 00:00:34.900 --> 00:00:59.900 Ben Rogers: on the North Carolina outer banks, and pretty remote, I imagine. Pretty pretty, too. Oh, my God! You know, it's it's being a native from North Carolina. When you get out that far you know, it's hard to believe you're in the same State. It literally feel it has a very tropical island. Feel to it. But a great time man did a lot of stargazing. Did a lot of cool things with my step. 7 00:00:59.900 --> 00:01:12.130 Ben Rogers: daughter, and so being a with my granddaughter. So then it's really a good time. So glad to be back glad to have time off, and looking forward to seeing what a what the future brings, my friend. 8 00:01:12.270 --> 00:01:29.579 Philip Sellers: That's awesome. Yeah, gyra, long time. No, see, I I got to spend some time with Jarra in person. Last week he he was able to join us for our mid your company connect and great seeing you last week good to see you through the whole integral community man, super impressive. 9 00:01:30.260 --> 00:01:43.970 Philip Sellers: Yeah, we we appreciate it. Jyra did a a great presentation for our team. We're always learning when we get together. So it's great to have partners that build into us. And Gyrus always a great resource to to help us that way. 10 00:01:44.370 --> 00:01:55.379 Philip Sellers:  so today's podcast episode, we we're talking about some new things going on inside of object storage from New York. So 11 00:01:55.500 --> 00:02:03.240 Philip Sellers: I don't want to steal gyrus. Thunder! But, gyra, you you brought this one to us. You want to lead off with a little bit of the news here. 12 00:02:04.030 --> 00:02:09.160 Jirah Cox: Yeah, man, certainly not. Not my thunder to steal, but definitely a super exciting announcement. 13 00:02:09.199 --> 00:02:21.379 Jirah Cox:  Coming out with our objects. 40 release, which is out out now, And full credit to Steve mackerel. That's who wrote this. He's one of our tech marketing engineers. 14 00:02:21.380 --> 00:02:44.600 Jirah Cox: which, if you don't know our our Tme team. That's like, 90% marketing. there's a 90% technical 10% marketing. Thank you. Got that backwards. and for this on the tentacle there. With a little bit of marketing sprinkled on So the teams, the teams fantastic, start to finish With Steve's real joy. He's one of our global object specialists. 15 00:02:45.330 --> 00:03:07.260 Jirah Cox: which is fitting because this release brings global namespaces. Right? So we can now take mechanics objects right, like our S 3 on Prem, you know, data in buckets as a web technology type of offering. And now unify that globally. Right? So you can have a global namespace. This has been a long time. Ask for a major customers to say. 16 00:03:07.540 --> 00:03:18.230 Jirah Cox: Hey, this is cool, that I can have a Raleigh or a Charlotte or a Seattle deployment for this. But I'm a global company, right? How do I really go big with this technology? And this is how we get there. 17 00:03:18.830 --> 00:03:21.530 Philip Sellers: So I have to ask, I mean, is this. 18 00:03:21.630 --> 00:03:36.350 Philip Sellers: for for technologists that have been in, you know, infrastructure for a long time. Sometimes object storage can be a little confusing. So is this sort of like Dfs namespace inside of a windows a D network. Is is it similar to that 19 00:03:36.710 --> 00:03:42.380 Jirah Cox: man that's interesting. That takes me back because I was thinking about some other ways to to talk about this 20 00:03:42.430 --> 00:03:55.110 Jirah Cox: as we get into this and some analogies to bring. I was guessing to talk about dns and domains versus like forests, and I think both are totally applicable right? It's like there are resources that I want to consume, and it may be maybe in control locally. 21 00:03:55.250 --> 00:04:14.419 Jirah Cox: but also access globally, right or able to access a second copy of them elsewhere. Right? So I think I think both those analogies really kind of come through for sure, like, dfs, yeah for smb, right? as a collection of like Sme stores that may or may not have the same contents. 22 00:04:14.490 --> 00:04:20.820 Jirah Cox: And yeah, this is a similar construct of global news faces for object stores that may or may not store the same contents 23 00:04:21.860 --> 00:04:36.030 Philip Sellers: awesome. So the introduction here it talks a little bit about Federation and and you mentioned this is new and objects for that. Oh, So from a a versioning standpoint, 24 00:04:36.330 --> 00:04:58.380 Philip Sellers: it is that tied to a particular Aos release is that a particular version that that we have to be at, or how independent, I guess, is, is the Newtonx objects from without memorizing them. Compatibility matrices. I think it's mostly independent from Aos, from prism element, for sure. 25 00:04:58.650 --> 00:05:16.270 Jirah Cox: objects does run within present central. That'd be the only thing right? So you're probably on the latest prison central for almost all customers, because that's the multi cluster management construct And so there's always goodness coming to that present central release, and that usually gets you on the right path to run the latest outics. Release as well 26 00:05:17.230 --> 00:05:26.949 Philip Sellers: Ben, as you're talking with customers and stuff. How many conversations. Are you having? Kind of around new tanks? Objects? I mean, what? What are customers talking to you about? 27 00:05:27.290 --> 00:05:50.280 Ben Rogers: Well, they're they're talking, you know, what's really interesting about it is, customers are wanting to look for ways to consolidate their object storage, especially when they're looking at cloud services, multiple cloud services. And so this is really good talking point for us, because we can consolidate all that form in one platform, and we can extend that from on Prem, which is where their traditional footprint is 28 00:05:50.280 --> 00:06:15.279 Ben Rogers: out to their new cloud footprints and really make it look the same across the environment. So we're having this conversation. I will be the first to admit that I'm coming up speed on this technology. I know, man, we've done a lot within us in the last 6 months. So I'm a little bit more on the customer side of this, where I'm looking at somebody like Gyro one. Educate me. How can I utilize this in my environment, and what is the best way for me to take advantage of this? 29 00:06:15.280 --> 00:06:24.499 Ben Rogers: So again, the Dfs, you know, the comparison was good for me, because I did run that. But but I'm a little more curious of, okay. 30 00:06:24.640 --> 00:06:40.540 Ben Rogers: I've got a global environment. I'm spread out across my environment. How do I ensure that. You know things are gonna drop where they need to go if I implement this Federation format. But yet I still need my silos for geographic regions if you would say. 31 00:06:42.680 --> 00:07:05.469 Jirah Cox: that's a great question. Right? So let's go. This article takes this for granted and skips over it. So let's go deeper off script here. But person like, why would I use this? Right? So the 2 big like used cases right? That we're seeing for object storage, and then, like, sort of next gen cloud, native application storage. And we can get into both of those for backups. Right? 32 00:07:05.470 --> 00:07:27.739 Jirah Cox: That's where we're helping customers move off stuff like basically traditional back of appliances where ultimately it was just a big piece of sheet metal, maybe with some disc shelves attached, but it is offering like an Smb share out to the network. And then, you know, back up applications. We're simply writing to that share. It was a giant, big almost like a storage array. But maybe even sometimes single controller. 33 00:07:28.100 --> 00:07:29.400 Jirah Cox: big pile of data. 34 00:07:29.630 --> 00:07:48.770 Jirah Cox: right? And that's fine. Often, that's a you know, price per pound. Kind of use case right? It's cheap and deep. and that's all fine as well. But the biggest sort of management pain came in with the lifecycling of that right like, how big can I get if I want to cross a certain threshold? How do I go and scale beyond that? 35 00:07:48.810 --> 00:07:59.980 Jirah Cox: Even if I don't scale in 5 years, 6 or 7 years, or whatever my financial schedule is, how do I get off of that? Go on the next one, right? And sometimes there's answers for that. And there's services for that. Sometimes there's replication tools for that. 36 00:08:00.210 --> 00:08:06.840 Jirah Cox: But typically that refresh was at least some amount of pain or management, or hassle or distraction from running the business 37 00:08:07.560 --> 00:08:17.249 Jirah Cox: with Newtonics. Right? We're now, of course, we can also still do Smb shares. But really the next Gen. Web scale way, to think about backup targets 38 00:08:17.310 --> 00:08:33.340 Jirah Cox: is with S. 3, right as the protocol right for storing backup data in object stores. This is where. Look at all a lot of your vendors right? Like your rubric, your cohesity. it's now natively in beam. It's in common vault, even if you have some local storage, maybe your last 14 last 30 days. 39 00:08:33.500 --> 00:08:42.399 Jirah Cox: It's sort of becoming just broadly accepted. That long term storage goes outside of that Smb, or I'll say, appliance, manage storage. 40 00:08:42.570 --> 00:08:48.729 Jirah Cox: and gets pushed out to S. 3. It sort of always assumes to be the cheapest of the cheap, the deepest of the deep. 41 00:08:48.930 --> 00:08:59.000 Jirah Cox: And also when you get there, you get fun capabilities, right stuff like worm, right? Stuff like archive retention lock, so that I get even more protection of the business against, like, say, like accidental deletion, or even malicious deletion. 42 00:08:59.240 --> 00:09:04.120 Jirah Cox: So then I get even more of a security blanket wrapped around my backup storage, and that's awesome 43 00:09:04.340 --> 00:09:10.029 Jirah Cox: should be moving in theory to a lower price per gig as well. So that is a win on the financial side. 44 00:09:10.740 --> 00:09:30.010 Jirah Cox: But then the sort of mechanics. Yes, and to all of that is the life cycling, right? So you could deploy like a petabyte, you know. archive today, running an s. 3 run that for 5 years, 6 or 7 years the hardware itself has lived its life. It's time to to leave the data center, bring in new hardware. Maybe it's twice as big right? Maybe now I have twice as much capacity. 45 00:09:30.600 --> 00:09:34.039 Jirah Cox: This is where the newtenance difference really applies. I bring in the new nodes. 46 00:09:34.370 --> 00:09:54.619 Jirah Cox: put them in the data center, expand that cluster to. Now bridge the old of the new hardware, eject those old nodes, and I've done 0 tuning, revisiting, we swizzling migration. Nothing right, the application that is writing to it, your beam, your rubric coesity, whatever come all doesn't even know that I made a change. 47 00:09:54.750 --> 00:09:57.280 Jirah Cox: But I just re I just re-plat from that entire 48 00:09:57.300 --> 00:10:00.469 Jirah Cox: ball of data without having to do anything, any real work. 49 00:10:03.090 --> 00:10:09.600 Philip Sellers: and that to me makes it feel like, you know, at a platform 50 00:10:09.670 --> 00:10:21.290 Philip Sellers: standpoint, you you've got those capabilities. But now you've brought that global namespace to it as well. So now you've got. You know, this object store, which can live forever 51 00:10:21.680 --> 00:10:32.929 Philip Sellers: can be upgraded can change its pro performance characteristics. And I don't have to update a single pointer or anything. I've I've effectively got the same 52 00:10:32.940 --> 00:10:39.829 Philip Sellers: same place to right forever and ever. Amen. 53 00:10:40.160 --> 00:11:01.009 Jirah Cox: probably has a use case for for backup and archive use cases as well, but it is much more in my mind, aligned with like a a cloud storage for applications kind of use case. Right. So if I'm putting out an application, whether that's internal or external doesn't matter. S. 3 is an authenticated protocol that can go inside the firewall as of the firewall. Either one's fine there. 54 00:11:01.330 --> 00:11:10.300 Jirah Cox: If I'm putting on an app or I'm distributing data internally. I had one customer who was distributing these 3D. 3D assets right to all their various global offices. 55 00:11:10.400 --> 00:11:15.840 Jirah Cox: or they wanted to sort of like compile, render them in one place and then consume them in a bunch of places 56 00:11:15.920 --> 00:11:18.020 Jirah Cox: with this kind of access. Now. 57 00:11:18.130 --> 00:11:31.389 Jirah Cox: we can have a a solutions, basically like an on Prem Cdn, where I can put them in one location, replicate them to a bunch of other locations, and all those locations can pull them down locally, right saving on when bandwidth, increasing performance, increasing speed. 58 00:11:31.410 --> 00:11:42.820 Jirah Cox: But if their local one was down for some reason they can also get elsewhere to retrieve that same data where it's stored elsewhere. That's why, I say it sort of like on Prem, Cdn, content delivery network type of outcome 59 00:11:42.910 --> 00:12:01.060 Jirah Cox: that we can now offer as one global federation or multiple federations. Even right? So I can have. you know, a whole bunch of I could have 30 offices right? And say, some are my, you know, accounting Federation. So my, you know, development out Federation, right? And I have those all different and managed within new tanks. 60 00:12:02.140 --> 00:12:12.109 Philip Sellers: Yeah, that that makes a lot of sense to me. And and as I think, about cloud native applications, you know, coming from an organization that was trying to move 61 00:12:12.270 --> 00:12:37.330 Philip Sellers: into more microservice and and cloud based technologies. You know, one of the things we were thinking about was, you know, pods of our application all around different geographies. And this seems like a huge enabler as we adopt. S. 3 type buckets in the application to now, then, have that data transport with us to each of those regions too 62 00:12:37.630 --> 00:12:39.230 Jirah Cox: totally 63 00:12:39.330 --> 00:13:01.430 Jirah Cox: I can think of a lot of use cases for like edge sites, I mean edge sites, of course, still need backup but they might even do like local video storage or whatnot. And I can then use that to replicate. Like many, the one, maybe I bring a bunch of remote sites back to one Hq data center grade site. But then I make them all look like one giant happy data storage, you know, family through a Federation as well. So it's really really pretty cool. 64 00:13:01.460 --> 00:13:27.929 Ben Rogers: So I can think of a a customer that we've been talking to that this will hit the mark right off the back. They they're running manufacturing, but each plant does different manufacturing, and they have to have different Logos for their packaging for that factory. But they want to have a unified space. Well, this will do exactly what you're saying. They can have everything pretty much housed in the data center, and then the pieces they need to have on the edge. They can either replicate those out or whatever technology. 65 00:13:27.930 --> 00:13:51.160 Ben Rogers: But when you're looking at their tree it'll all be, you know, Company Xyz, and then they'll have different locations. And those locations will have the specific artwork and everything that they need for that manufacturing facility. So this is gonna be great for that process. Because now I can go back and go, guys, we can make it look like all one tree. It can be, you know, Company Xyz, and it cut under Company Xyz. We can, did 66 00:13:51.160 --> 00:14:00.790 Ben Rogers: replicate portions of this out to the edge that you need is still have centralized storage back in the data center. So really cool, man, I look forward to having that conversation with our customer. 67 00:14:01.520 --> 00:14:20.369 Jirah Cox: Yeah, that sounds really cool. Actually, I can picture some like even like automated site deployments right where I just pick like, is this gonna be a red site or a blue site that I can deploy it, automate the full stack and then know that it's gonna get access to that same data set even immediately, right? And then also replicating over time. So it gets even more locality, and cache is closer to where the work is going to happen. 68 00:14:20.760 --> 00:14:42.869 Ben Rogers: And then I think it's cool. What you mentioned gyro which goes back to the just basic goodness of Britain. It's the ability to inject and eject nodes as the environment needs to grow upgrade. All of those things you really do forget when you talk about a service like this is built back on that platform and foundation, that we're always talking about the ease of use, flexibility, simplicity. 69 00:14:43.360 --> 00:14:54.949 Philip Sellers: That's the enabling factor here. And and I think that's that's the underscores as it develops as mechanics develops this platform. I mean, it's it's built on that enabling 70 00:14:54.960 --> 00:14:56.550 Philip Sellers: core technology. 71 00:14:57.040 --> 00:15:14.690 Philip Sellers: So I I do want to spend some time kind of peeling the onion a little bit and and talk about how we get into this architecture. This Federation you know. The next section of the blog post goes into it a little bit more. But, Jerek, can you explain a little bit from an architectural standpoint? 72 00:15:14.830 --> 00:15:29.209 Jirah Cox: Yeah, totally. So. And there's a button, and there's a there's gonna need. If you're more visual learner than like auditory, you can watch this all in a quick little Youtube video on our Youtube channel as well. But when you go to create a new object store Federation. 73 00:15:29.310 --> 00:15:39.650 Jirah Cox: Right? Then you get prompted to say, Well, what should be inside of it. And so then that's simply a matter of picking. You can do as few as one, but really like, I think 3 is recommended for sort of geodiversity and resiliency. 74 00:15:39.740 --> 00:15:41.190 Jirah Cox: Pick 3 different 75 00:15:41.220 --> 00:16:10.500 Jirah Cox: object stores, right? That then serve as like core members, right? And we call them core members, because that's where they they're going to store some additional data that really is like metadata of like, what is the Federation shaped like? And who else is in it? and of course, you know we like. If you've seen our cluster minimums, right? We like to do like minimum 3 of something, so we can still lose something and still have full continuity as well. So 3 is a good, a good starting point for scale out systems. And and we see that here as well. 76 00:16:11.040 --> 00:16:20.290 Jirah Cox: So there's sort of 2 components to it. Right? There's the metadata service, which is really tracking like who is storing what data and where and what is the shape and size of a given federation. 77 00:16:21.030 --> 00:16:27.600 Jirah Cox: And then, also, more importantly, those controllers. Right? So to think back to like our Dfs analogy sort of 78 00:16:27.620 --> 00:16:32.379 Jirah Cox: dfs could be like, I can go to a server in query like, Where is this file share? 79 00:16:32.510 --> 00:16:44.879 Jirah Cox: And the answer could be, It's here or it's over there. But I get the sort of traffic cop effect of I'm directed to. Where I, the resource I want to get to is located. Same thing here. Right? So the Federation Controller knows 80 00:16:45.050 --> 00:16:58.000 Jirah Cox: what lives where and then depending on whether whether I want to. Do you know? a discovery action, or actually like a crowd like create rename update, delete action. It'll tell me where to go to get to, to make sure that that happens. 81 00:17:00.510 --> 00:17:11.950 Philip Sellers: That makes sense. again. Yeah. I mean, high Residency. High availability. built into the product thought out from the beginning. So it, it's 82 00:17:13.130 --> 00:17:41.040 Philip Sellers: It's sounds like it's enterprise ready from the beginning, which is another Newton extent. I mean, as you talk about the commonality between, you know, things like your core number of of Newtonics. Dsf nodes. you know, files notes in the multiples of 3. Yeah, I mean it. It makes total sense. I think you'll see here from the beginning, right is, it's it's built to be cross from central right. So no need for this all to live 83 00:17:41.040 --> 00:17:58.929 Jirah Cox: in one person, central, in fact, the opposite. Since prism central usually is a let's call it a regional or availability zone construct. It's actually expected that you're probably going to cross that probably from day one. So you can have these object stores that are all federating together across multiple prison central. And that's expected and even encouraged. 84 00:17:59.010 --> 00:18:12.070 Philip Sellers: Yeah, that that's important to call out. I noticed that in the diagram. But it it's even more important to to point out, because we we typically think of prison central as that roll up point. But this is bridging across those. 85 00:18:12.670 --> 00:18:28.579 Philip Sellers:  so the the relationship to availability zones also kind of called out here. you know it. It's a and can you tell us a little more about that relationship to the availability zones and and kind of how to think about it 86 00:18:29.490 --> 00:18:51.920 Jirah Cox: totally right? So and even, and even it highlights here in the article that when you when you do that, multi PC deployment, one cool thing it does is that, of course, in the construct of of object storage right in the S 3 protocol, the access keys are actually sort of generated by the cluster owning the data. Right? So like you're fill up from Gyra, he's been 87 00:18:51.950 --> 00:18:56.110 Jirah Cox: our usernames don't matter whatsoever to the data, right? The object store really generates. 88 00:18:56.150 --> 00:19:05.159 Jirah Cox: the access keys, both the random random string of numbers and letters. That is, quote the username and also the password. Right? That's all just sort of 89 00:19:05.340 --> 00:19:30.150 Jirah Cox: dictated by the Audrey store. But the cool thing is that when you configure this replication, the the we we reference it here as the I am. Replication actually handles all that as well. So that that means now my keys can go anywhere to any object store, even though they were created at the. You know the Raleigh object store. I can use them in Charlotte or Seattle, or Tokyo, or anywhere else anywhere else. Those access keys now are. 90 00:19:30.350 --> 00:19:40.939 Jirah Cox: What's the right word here they can be granted access to objects and resources elsewhere, even though my keys might live in a different more created in a different store. 91 00:19:41.550 --> 00:19:46.390 Philip Sellers: Then you're gonna have to watch out. I've got your keys now, so might come after your car. 92 00:19:46.660 --> 00:20:04.490 Ben Rogers: So I I was not worrying about this again. I want. I'm looking at this from the customer point of view. So what you're telling me is that if I've got multiple object stores out there that are being managed by multiple prison Central's, we now have a way to kind of bind all those prison central and stores under one Federation. 93 00:20:05.760 --> 00:20:16.260 Jirah Cox: Yeah, for the 100 for the for the object side of it. Right? The S. 3 part of it. We've always had solutions for like vms and and file shares for, like. Smb, all that good stuff, this one's now. 94 00:20:16.330 --> 00:20:27.479 Jirah Cox: with respect to the objects protocol right? Yesterday. Protocol. Yeah. Those keys that you generated in any one of those sites can now gain portability in that Federation to go anywhere to any other object store 95 00:20:27.620 --> 00:20:31.580 Jirah Cox: which isn't explicitly granting access. But now there are. They are grants of bowl. 96 00:20:31.770 --> 00:20:32.580 Philip Sellers: Hmm. 97 00:20:33.310 --> 00:20:35.199 Jirah Cox: all right. So basically, 98 00:20:35.270 --> 00:20:52.259 Jirah Cox: you know, to user, continue using our Dfs analogy, which at some point, if you, if you really know s. 3, you probably are rolling your eyes at us. But if you don't this is probably helping right with that Dfs Federation right now. My my username password for one file server now works at the other one. If I've been, if I'm in the apples for that one 99 00:20:54.910 --> 00:21:18.939 Philip Sellers: so super important to we, we have to be able to see what's going on inside of it. So new tax thought about that. So we've got new views inside of Prison central for Federated namespaces as well. you know, the article goes in. We've got a nice screenshot. And I know a picture is worth a thousand words. So you can find the link in the description for the podcast but 100 00:21:18.940 --> 00:21:27.289 Philip Sellers: Kara, I mean what what's important for us to know and see in terms of object stores and and watching and and scaling out. 101 00:21:29.540 --> 00:21:43.540 Jirah Cox: If I think about this, for like, if I had to run this environment, right, what do I care about the most? And and you're right. It's on. It's on this week's edition of let's describe to you a screenshot in in words. Right? You know what, I'm sure if I created right, where are they located? 102 00:21:43.620 --> 00:22:12.360 Jirah Cox: you know, how big are they? Right? What? How much data am I storing in each one? That's super important. How do I get there. Right? So all of them have, of course, local IP addresses per site for accessing, and we'll get. We'll come back to Ips and accessing that way later on, and and probably also the last thing I want to know in a new tennis parlance is like which PC. Is managing them right, like sort of which also sort of hit touches on which availabilities are, are they a member of? Is that which is usually, you know, often regional, or like a continent, perhaps. 103 00:22:13.290 --> 00:22:28.699 Philip Sellers: and so you know, I mean I I think we we may take it for granted. but there's object stores, and then there's buckets, and and so a little bit of the screenshot here deals with the number of buckets that we've got and how many objects are in things. So 104 00:22:28.780 --> 00:22:37.739 Philip Sellers: I for someone approaching object store? New, I mean, how do you describe the difference between an object store, an object and buckets? 105 00:22:38.070 --> 00:22:49.820 Jirah Cox: Hmm! Someone could do a better job with this, but I would think it's it's a fair analogy to say that you can think of an object store kind of like a file server and a bucket like a share. Right? So it is a container. 106 00:22:50.270 --> 00:22:54.580 Jirah Cox: possibly one of several right, probably one of several on the logical object. 107 00:22:55.960 --> 00:23:20.560 Jirah Cox: and then an object would be analogous to a file right? And then, of course, you have the buckets. Then hold the outcome object themselves. which is the data you're storing right? Whether that is, you know, if you are running a social media site right every time someone uploads a new avatar or attaches a picture to a post. All those things are probably going to land somewhere on some flavor of S. 3 storage on the back end. 108 00:23:21.440 --> 00:23:30.279 Philip Sellers: so hopefully, no one punches us for that analogy. But I I think it's helpful for for infrastructure folks who, you know. 109 00:23:30.400 --> 00:23:34.300 Philip Sellers: approach to different kind of a problem, and if they ask 110 00:23:34.720 --> 00:23:48.310 Philip Sellers: The next section really talks us through how clients, requests or accesses. All right. I'm not sure that was English. Let me back that up and try to get how client requests are routed. I don't know what I said the first time. 111 00:23:48.660 --> 00:24:16.330 Jirah Cox: And we probably don't have to step through the datapath like call by call, I should we should point out we'd even say, this is on the new tenx developer blog, which is really cool. These are kind of more technical posts in nature. we sort of. We sort of pick and choose as we feed the blog engine right around the corporate phenix blog on the clinics.com the developer, blog on it to that dev which is where we are today, and also the community blog as well. We've seen some great stuff 112 00:24:16.330 --> 00:24:21.599 Jirah Cox: about Newtonics on, say ovh, or some folks that have put together some great blog posts on 113 00:24:21.600 --> 00:24:31.220 Jirah Cox: out of their home labs. So we have a a wonderful place, a a number of places we can pull from today. We're on the on the deaf site. So there is a a couple of very highly detailed paragraphs here 114 00:24:31.220 --> 00:24:43.079 Jirah Cox: around, how do calls work? I think for podcast level specificity. We can just say, guess what it works. There are a couple of actions that are more important, that do get right out through those core members. 115 00:24:43.210 --> 00:24:44.869 Jirah Cox: When I need to do stuff like 116 00:24:45.120 --> 00:24:59.369 Jirah Cox: I don't know to use some more terrible analogies. Right? The the S through Covent of like looking up a phone number in a phone book. But then, when I make that phone call, it can be either local kids. We used to have these things called phone books. They were printed out 117 00:25:00.090 --> 00:25:11.299 Jirah Cox: But when I make the phone call right? That it might be local, it might be remote. But my, my, my conversation gets where it needs to to either do the put or the get request to either place or retrieve new data. 118 00:25:11.960 --> 00:25:24.190 Philip Sellers: And I think that's important, too. So I mean, if you think about S. 3 as a protocol, you know, it's a little different. it's more like what you get with Http. Calls from a web browser 119 00:25:24.240 --> 00:25:41.019 Philip Sellers: as opposed to. You know your traditional smb, so you you've got get input, which are the same verbs you have from a web browser. Same thing that you would do with any Api So you know, definitely, very much cloud native technology. 120 00:25:41.030 --> 00:25:49.690 Philip Sellers: Yeah, I I was looking through these steps. And I was happy to hear you say, Let's don't go step by step. 121 00:25:50.230 --> 00:26:05.460 Jirah Cox: It's not to put people to sleep on the podcast I'm yeah. If you were to get in today to listen to the step by step. Handshake of how does my S. 3 request get looked up and then honored? I'm so sorry we disappointing you. but we do it to stay awake and not crash in traffic. 122 00:26:05.470 --> 00:26:28.529 Jirah Cox: But it's a great point. Follow up so because it's web native technology. Right now, we get to bring in really cool stuff that we sort of never had back in to stick with the analogy back in like the Dfs days of like. How do I put a load balancer in front of this? How do I do? Geo. Routing with that conversation around the load balancer, right? Like, if I work in the Budapest office, I want to retrieve data 123 00:26:28.580 --> 00:26:37.749 Jirah Cox: as closely to where I'm sitting as possible. Right? Maybe that's some more local or in a neighboring country, but not like have to go across the world to pick something up if it if it is closer. 124 00:26:37.970 --> 00:26:43.330 Jirah Cox: So with Gslb, which is kind of a I think, vendor agnostic term what global 125 00:26:43.760 --> 00:26:47.279 Jirah Cox: service load balancing? I don't. I know 3 of the 4 letters. 126 00:26:47.630 --> 00:26:51.030 Jirah Cox: I think it's global server live balancing. 127 00:26:51.450 --> 00:27:05.420 Jirah Cox: So basically, it's a way for you know, using basically some health monitoring Dns trickery, some, some perhaps waiting of records that I can put in as the admin. I can say when you ask where something is. If it's close to you, we'll send you some more close to you. 128 00:27:05.560 --> 00:27:13.719 Jirah Cox: but if that's down or unreachable or having a bad day, or whatever, we'll go somewhere else. So you still get your request honored. 129 00:27:13.750 --> 00:27:34.539 Jirah Cox: maybe not as close as it as ideally bright, but it's sort of a at way way of adding some awareness of data, health, and integrity to the conversation. So with this. Now we can do fun stuff like when I want to retrieve a a 3D asset brand, maybe from this bucket on my on. Prem, you know, Cdn, or restore from a backup right for my backup. Now, Federation cloud in privately. 130 00:27:35.080 --> 00:27:38.190 Jirah Cox: I can now get that from the closest location where it's available 131 00:27:38.210 --> 00:27:44.369 Jirah Cox: or somewhere farther away, if it's not replicated locally close to me. similarly, when I want to do 132 00:27:44.380 --> 00:27:52.970 Jirah Cox: a data right? Right? Maybe if I'm one of these artists generating 3D assets. I might have 3 offices around the world where I can do 133 00:27:53.220 --> 00:28:02.600 Jirah Cox: that the put right, the save action, and that will be replicated to 30 other offices. That can all do the retrieval right. I can set up that that replication in lots of fun ways. 134 00:28:02.620 --> 00:28:09.940 Jirah Cox: so because it's a web. Native technology load balancers eat this for breakfast. Right? They can do it very, very capably, right from the get go. 135 00:28:11.390 --> 00:28:32.559 Philip Sellers: you know the the next thing you know, if I'm a customer who already has object store and and is thinking about Federation and and hey, this really, really me to my use case. What happens to my local namespace? what? What happens as I federate? you know that that's the next concern. I think that that comes up. 136 00:28:32.900 --> 00:28:46.860 Jirah Cox: Yeah. So it's 6 rounds. and we show in the in the blog post here. Right? So the every Tenx cluster running. The object service includes the object browser right? Which is not the only way you can manage it. Of course you can get there with any s. 3 client. 137 00:28:46.970 --> 00:28:54.430 Jirah Cox: but we also do include one natively that runs within your browser, and as part of that you can browse the local namespace which doesn't go away. 138 00:28:54.480 --> 00:29:18.179 Jirah Cox: or the parts of it that also are holding federated resources as well. So it sort of becomes Oh, man, I almost I almost genuinely and not ironically, set up prism. to not not to be on brand, but to show that it can show like multiple facets of what's going on there right? The local and the remote maybe it's more like a split telescope. I think prism actually is is close enough to being on brand. 139 00:29:18.680 --> 00:29:43.660 Philip Sellers: Well, that's good. And and also says, any of the existing that is going to stay. So it's non disruptive to federate, which is also a great thing. It's not like you destroy anything as as you adopt Federation, you know, in fill of your your your Dfs analogy is getting frustratingly more and more useful the more we go on. probably most most frustrating to people that are are more like 140 00:29:43.660 --> 00:29:54.700 Jirah Cox: I can get to the share through the local file server, or, of course, through the Dfs again, namespace right? Like, it's more like logical traffic routing than it is. 141 00:29:54.700 --> 00:29:58.339 hard plumbing. Right? So to your point. Yeah, of course, like no data 142 00:29:58.340 --> 00:30:04.799 Jirah Cox: no data churn as a result of the Federation. unless I can figure it right, like migration or application. 143 00:30:05.050 --> 00:30:06.000 Philip Sellers: Yeah. 144 00:30:06.340 --> 00:30:24.109 Philip Sellers: And what's great in the the article here, we've got good screenshots, which, of course, listeners can't hear But if you happen to be watching on Youtube. You see it on screen. you've got different tabs associated with the type of namespace, whether it's local or federation that you're participating in. 145 00:30:24.370 --> 00:30:29.419 Philip Sellers: And it looks like, here, we can actually participate in multiple federations. Is that true? As well 146 00:30:29.500 --> 00:30:39.610 Jirah Cox: sure can. Yeah. So so you know, the Federation is  This is the sound of me thinking out loud. It's like a user, definable 147 00:30:39.620 --> 00:30:58.030 Jirah Cox: grouping, right? So like, there's no requirement that like, just because it runs the objects, you know, service on one at the next cluster that it has to be in all federations or none like I can pick and choose. I want this object store to be part of that one, but I can deploy it. I've already store that's part of a different Federation as well. 148 00:30:58.030 --> 00:31:15.209 Jirah Cox: I can think of use cases for that, for well, even for for use cases right like backup versus Cdn. Cloud, native application, storage and retrieval, or also so stuff like even like multi-tenant right? Like, I got 10 at Federation, 1 10 at Federation 2. And those are fully separate. 149 00:31:15.460 --> 00:31:16.890 Jirah Cox: you know, placements of data. 150 00:31:18.330 --> 00:31:26.739 Philip Sellers: Some. Ben, is you listening to this? What? What questions do you have? I mean, what what do you think? customers should be asking about. 151 00:31:26.890 --> 00:31:38.209 Ben Rogers: So I mean the the separate Federation things kind of got me interested in it. And I'm thinking of this mainly from mergers and acquisitions. So if I had started out with 152 00:31:38.370 --> 00:31:44.739 Ben Rogers: a parent Parent Federation, but I had to bring another Federation on in an M. And a situation. 153 00:31:44.890 --> 00:31:56.970 Ben Rogers: You lost me a little bit of like. How would would it be to Federation zones going to the same storage? Kind of be? Explain that a little better to me. I'm a little lost with that concept there. 154 00:31:57.060 --> 00:32:00.739 Jirah Cox: so could be either one really been right? So I 155 00:32:01.550 --> 00:32:25.020 Jirah Cox: we should caviar or talk about new tanks governed. S. 3. Right? There's ways you could certainly ingest data from like any other s. 3, whether that's public cloud or any other kind of on from s, 3. Solution. but yeah, to your point. We certainly can. use federations for like a data migration use case right? so that the the object store can live elsewhere. But then we bring it more into the family, right for governance reasons. 156 00:32:27.920 --> 00:32:40.280 Philip Sellers: And it looks like you. You've thought a couple of steps ahead. I mean, you know, migrations Federation Federation with fault, tolerance and and migration is also capability. 157 00:32:40.370 --> 00:33:04.559 Jirah Cox: yeah, I mean, there, I think the underlying thing is, there's a lot of things to think about as Federation came to life. talk us through a little bit of thought, tolerance and and migration use cases. Yeah. So so you know, when I've talked to this about this in the past, there's been that desire and some of those we solve for earlier, even before Federation But some things get even easier with Federation in play now 158 00:33:04.560 --> 00:33:11.649 Jirah Cox: of like great. If I have my, you know, La and New York data centers. And I can have the same data in each one 159 00:33:11.650 --> 00:33:36.900 Jirah Cox: or I want as same data in each one. And I, wanna you know, lose power to one site or lose my landlink to one of these data centers and everything. Just keep on working right? And then with that, like we talked about before like a Gslb or a Dns based direction, because I can always. I can also do it without Gslb, if I just simply want to sort of micromanage. My Dns records that are recite. I'm running site aware, Dns, servers that can work as well. 160 00:33:36.920 --> 00:33:49.270 Jirah Cox: I can now say, hey? The same data is in La or New York. Go to either data center right? Or go to whichever one is is closer to you, or which which are ones alive. So now I've gained site fault tolerance for that data set for that application for that use case 161 00:33:49.760 --> 00:33:53.729 Jirah Cox: like like Ben touched on. 162 00:33:53.760 --> 00:34:12.270 Jirah Cox: I could have a federation that includes La in New York, and a bucket starts life off in one of the other. But then we actually decide that. hey? This is, a very, very latency. Sensitive application. Move that bucket to the other one right where maybe the application is running. So move moving within a Federation 163 00:34:12.270 --> 00:34:26.159 Jirah Cox: or moving across Federation, or I can move from like to that local namespace into a federated namespace right? Saying, this used to be site local and by design. But now we want to make it actually more more available as part of the Federation as well. 164 00:34:26.489 --> 00:34:28.530 Philip Sellers: Yeah, that's awesome. 165 00:34:28.620 --> 00:34:39.680 Philip Sellers: you know, we keep talking about the global server load balancing? you know, the next section actually talks specifically about that with Geo distributed? 166 00:34:39.770 --> 00:34:57.260 Philip Sellers: is. Is this a third party? Gslb, that we're we're kind of talking about? And you know. So it's a separate appliance or application. That Scalar, you know I I can't even think f 5. Definitely. Those are the big 2 right in this scalar of 5. I mean, you could probably write it 167 00:34:57.260 --> 00:35:12.130 Jirah Cox: yourself with, and genetics with a whole bunch of of native web scalar. whatnot. What's your web server? scaling technology, but sure, certainly your turn key off the shelf. Commercial solutions will be stuff like that scalar stuff like a 5. 168 00:35:12.650 --> 00:35:20.870 Jirah Cox: but yeah, all of that. So there are. That is the mostly client facing load balancing. This is like when I want to go to. 169 00:35:21.140 --> 00:35:35.220 Jirah Cox: you know, objects Federation. O one.kentoso.com. Where is that thing, and it knows where that thing where those things are, and it directs you to the the closest location for that, or if if one sites down it directly to a surviving site, right? So that you still get 170 00:35:35.300 --> 00:35:42.690 Jirah Cox: so good service. There there are, and we have a caveat here in the article that there are some layers of load balancing so that we we use like envoy 171 00:35:42.860 --> 00:35:48.710 Jirah Cox: closer to the metal, right? So, though I like everything we do in tanx. This runs as a as a virtual machine runs as a Vm. 172 00:35:48.890 --> 00:35:52.490 Jirah Cox: And so, fundamentally, if you pop the hood. 173 00:35:52.510 --> 00:36:02.549 Jirah Cox: you know, objects to the service that runs on one or more prison element clusters right? The cluster literally just a collection of of nodes that do compute for virtual machines as well as storage. 174 00:36:03.030 --> 00:36:27.460 Jirah Cox: as multiple vms, right? I think your default sort of like running the bill out of the box. Obvious deployment is like, I think it's 4 worker vms, and 2 load bouncing vms. Last I looked. so there are some load balancer, you'll see like dash. Lb, in the Vm. Name that's going to run on, boy. But those that's doing low bouncing for us right? Oh, which Vm is governing this V disk, or this data store or this data placement 175 00:36:27.600 --> 00:36:34.569 Jirah Cox: that's at a lower level than than the customer facing. And to your point, Philip, customer provided Gslb fabric. 176 00:36:35.200 --> 00:37:02.440 Philip Sellers: Yeah. So I think that's a a huge distinction to make. You know, you're providing new tanks, providing everything that's needed under the covers customer needs to bring their own global server load balancing for client facing activities so, or Dns and likewise bring their own Dns server as well. Yeah. Dns, And you're you're right? I mean, yeah. So we we get into situations with with the Ands. I mean, you can do simple round Robin. 177 00:37:02.440 --> 00:37:06.329 Philip Sellers: But that's not really intelligent. And so 178 00:37:06.330 --> 00:37:18.209 Philip Sellers: bringing intelligence to the conversation. A Gslb. Which is going to route users to the closest. You graphic region really becomes advantageous to customers in. 179 00:37:18.360 --> 00:37:39.589 Philip Sellers: I would suspect most customers of the scale who are enterprise customers that really want to take care of this or take advantage of this Federation. They're probably already gonna have something in their portfolio to be able to provide it. And if not, I mean, you know, azure aws, there are great Gslv solutions and cloud providers as well. 180 00:37:39.910 --> 00:37:46.049 Jirah Cox: yeah, I'm getting picture a way to get here with using like active Directory zones and sight away records. 181 00:37:46.100 --> 00:37:58.690 Jirah Cox: And I can picture that quickly turning into an argument for buying Gslb as well. There's things you can do. And there's things that you actually want to actually own as the full solution. 182 00:37:58.790 --> 00:38:09.569 Ben Rogers: I know this is still fairly new for our portfolio. But have we had any clients use this in a sense of differentiating between on Prem and cloud as 3 buckets. 183 00:38:10.120 --> 00:38:16.350 Jirah Cox: We see my good question, Ben, so well, and to be, and to be super clear for our listeners. Right? So objects itself is 184 00:38:16.490 --> 00:38:35.269 Jirah Cox: go from memory here, 4 and a half, 5 years old. It's actually like super super, mature as a as an on-prem like the kinics owned and managed like this is version 4, that we're kind of highlighting here and some of the features. So the Federation is, that is the new part right? But you tanx as an S 3 object data store. Actually, kind of not so new. 185 00:38:35.270 --> 00:38:50.490 Jirah Cox: really. But but still, I mean, amazing question, Ben, so like, yeah, for sure. I mean, it's really part of when we say that in tanx is a cloud platform, right? And I don't say public or private anymore. It's all, of course, hybrid multi-cloud, because it's your cloud that goes wherever you want to run your business, whether that's 186 00:38:50.490 --> 00:39:06.659 Jirah Cox: phone or rent, or your building or cola or partner data center, or the integral data center or public cloud, or anything like it's your cloud man like, where do you want your cloud to be? And does your clouding to be scalable and rented? Or it doesn't, is it, you know, pretty static and owned, or all these things? 187 00:39:06.820 --> 00:39:10.570 Jirah Cox: But from a capability standpoint of what does your cloud probably need to have 188 00:39:10.580 --> 00:39:37.659 Jirah Cox: to support even today's apps like backup and tomorrow's apps like cloud native and container as applications. S. 3, as a protocol is sort of like something that you probably as a cloud provider to your business, which is sort of like my my thought technology for, like how you need to own and run it as a company. if you're a customer, right? Is like, I am a cloud provider to the business that can involve. You know I integrate all these vendors, and I can choose to make public cloud or private cloud, or any of that a component of that. 189 00:39:37.890 --> 00:39:42.630 Jirah Cox: It's like S. 3. Just got to be there, probably right? Because your developers. if they're developing apps. 190 00:39:42.670 --> 00:40:00.630 Jirah Cox: probably on a long of timeline, are gonna want to see this kind of capability, this kind of storage. even even your other vendors, right? I don't like. I've highlighted them here like at least, and probably not loaded to like your rubric's. Co. Used to these compuls. Beams. Want to speak s. 3 somewhere. so it just kind of becomes more of a more and more of a 191 00:40:00.630 --> 00:40:20.179 Jirah Cox: closer and closer to mandatory offering that you have to have same way. Similarly, like 30 years ago, was like. Do you offer Dns right? Maybe you said No, right? No, we do all you know. I don't know net buoy, but like eventually you got to a point where you said, yes, we offer Dns. And so now it's like, Do you offer? S. 3, and that's becoming more and more of a yes, elsewhere. 192 00:40:22.240 --> 00:40:33.660 Philip Sellers: Yeah, I mean it. It definitely seems to be the de facto object store language. I mean, I know I know Microsoft's got their own version of Asher blob. But 193 00:40:33.700 --> 00:40:39.100 Philip Sellers: almost everyone talks. S, 3. I mean. yeah, it's 194 00:40:39.520 --> 00:40:54.609 Philip Sellers: it's the most widely adopted. And to your point I I use scale out backup repositories inside of the you know, we were sending data out to an S. 3 storage provider, and 195 00:40:54.610 --> 00:41:21.910 Philip Sellers: you know it. It. It worked extraordinarily well for offsite immutable backups and in the latest version they can back up direct. Theme can do back up directly to S. 3 storage. So it it makes a new tanks cluster running Newtonics objects, a viable backup target. So those new avenues without adding additional operational complexity and things like that, you could. 196 00:41:21.980 --> 00:41:29.089 Philip Sellers: you know. Do it an entire backup base, Newton. It's cluster to the side, or, you know, possibly 197 00:41:29.100 --> 00:41:54.579 Jirah Cox: a a lower tier Archive along with your backup storage. So I I think the opportunities are huge for customers as they look at the landscape which is changing over the last few years. Yeah, to your point. I mean to your point. Fill up and into your question. Then, like why would I look at the tanks for that? Because we're, you know. Candidly, we're not like a household name yet as a backup target right in. Tunex is not 198 00:41:54.580 --> 00:42:10.149 Jirah Cox: commonly thought of that way. I don't. I don't see customers, you know, coming to me and saying, Hey, you know, giving an unsolicited proposal for a backup cluster. It's a thing we can do, but but we're still getting the word out there about that. What? What? Why would I want to before we've highlighted the the operational like sort of lifecycle differences like 199 00:42:10.150 --> 00:42:39.619 Jirah Cox: running on Newton's back cluster as easy as running any other in the next cluster, which is super super easy. both on day, one and day 1,500 when you want to refresh it. But also I see proposals all the time that have, you know, competitive financial comparisons against like public clouds. 3. Storage where we're saving the customer, maybe 30 to 50 against cloud storage. So better, better, better price for pound for these quote cheap and deep workloads. but also no egress charge right like this can be a cluster. Live next to your 200 00:42:39.690 --> 00:42:42.940 Jirah Cox: backup appliance or your production cluster. 201 00:42:43.050 --> 00:42:53.429 Jirah Cox: but I can get to that data for Free versus being like, Oh, I don't want to know big restore out of the cloud, because I'm gonna get hit with that cloud bill for the Cloud egress charge for the month. So pretty pretty differentiated solution there. 202 00:42:53.600 --> 00:43:11.269 Philip Sellers: and and there are alternatives or competitors, I guess I should say, competitors to Aws, who who obviously invented s. 3, created s. 3. There are whole businesses that exist trying to solve the same problem of egress charges. you know, as as cloud providers. 203 00:43:11.310 --> 00:43:24.200 Philip Sellers: you can do one better by getting it into the same data center or into other colos for further savings where you're doing the management instead of paying a cloud provider to manage your your S. 3 storage. 204 00:43:25.270 --> 00:43:33.360 Philip Sellers: Well, guys, I think this was an amazing topic and amazing session for us today. I know, I learned a lot then 205 00:43:33.630 --> 00:43:36.230 Philip Sellers: sticking out for you. 206 00:43:36.270 --> 00:44:00.809 Ben Rogers: Oh, yeah, man, just again, the new tanks. Unified storage systems are a great story for our company. man, I need to learn more about it, because it is somewhere that is another arsenal in my toolbox to present to clients. But appreciate you. Let me join today, definitely learned a lot about the Federation process of this and excited to get out and ask some question. My customers see how this would be useful for them. 207 00:44:00.910 --> 00:44:30.409 Philip Sellers: Yeah, I I agree with you. I think this is some of the the exciting stuff Newton's is definitely delivering. So it's it's great gyra, really appreciate you unpacking this and bringing it the topic forward for us today. My pleasure, man, thank you for the time. Thank you for it to my buddy. Steve here forget writing such an excellent blog post as well 208 00:44:30.490 --> 00:44:49.609 Philip Sellers: on behalf of zintagra Vera. And then I want to say, thank you for carving out a little time and listening to our podcast today. we will certainly be back with more and hope you'll join us for a future podcast episode. Until then. I'm Phil sellers for Z integra. And we'll catch you next time.