Latest / Nutanix Weekly / Nutanix Weekly: Introducing AOS 6.1

Transcript

Nutanix Weekly: Introducing AOS 6.1 · Nutanix Weekly

WEBVTT 1 00:00:03.210 --> 00:00:17.369 Andy Whiteside: hey everyone, welcome to episode 44 new tactics weekly i'm your host Andy whiteside as some of you guys know from listening we don't do a lot of like a spruce it up a lot, not a lot of intro music at exit music so Harvey decided, he would sing something for us. 2 00:00:19.980 --> 00:00:21.690 Harvey Green: twinkle twinkle little star. 3 00:00:24.420 --> 00:00:25.860 Andy Whiteside: Okay, good now twinkle twinkle little. 4 00:00:28.050 --> 00:00:33.030 Andy Whiteside: Alright sorry I put Harvey on the spot that i'd like to lighten the mood on a on a Monday. 5 00:00:34.260 --> 00:00:43.590 Andy Whiteside: harvey's with us Harvey green director of all kinds of things solutions architect as INTEGRA now director heads integrity of are you changing the world this week. 6 00:00:44.370 --> 00:00:46.200 Harvey Green: I am doing my best. 7 00:00:48.840 --> 00:00:50.310 Harvey Green: it's still early is still Monday. 8 00:00:51.000 --> 00:00:56.520 Andy Whiteside: Well, did I wrote he he has a whole new version of ios that he released he's doing his part oh. 9 00:00:56.580 --> 00:00:58.080 Jirah Cox: yeah I was very busy all weekend yeah. 10 00:00:58.830 --> 00:00:59.550 Jirah Cox: Finally, got around to it. 11 00:01:01.470 --> 00:01:11.640 Andy Whiteside: So that's that's the Voice of America job you guys have a new guy friend of our starting into tactics here in a few weeks, and he asked me what he needed and I was like just just know gyro just just make sure you know who gyrus that's all you need to know. 12 00:01:12.570 --> 00:01:15.510 Jirah Cox: Not not exactly scalable advice there but. 13 00:01:16.710 --> 00:01:19.140 Jirah Cox: I appreciate the compliment nonetheless yeah. 14 00:01:19.800 --> 00:01:24.450 Andy Whiteside: Well that's great very valuable resource lucky to have you on our podcast you. 15 00:01:24.510 --> 00:01:25.590 Jirah Cox: have to be here thanks for hosting. 16 00:01:26.370 --> 00:01:29.400 Andy Whiteside: So I said episode 44 I think they're wrong. 17 00:01:31.260 --> 00:01:35.880 Andy Whiteside: So episode 44 we're going to cover this blog from February 24 introducing. 18 00:01:37.320 --> 00:01:49.710 Andy Whiteside: Acropolis operating system acronym a os i'm a big fan of translating acronyms into their actual names, so that people get lost six dot one which is six period, one measure basically on them. 19 00:01:50.100 --> 00:01:50.490 Jirah Cox: I think we. 20 00:01:52.140 --> 00:01:53.010 Jirah Cox: are familiar with dots. 21 00:01:53.790 --> 00:01:54.240 Harvey Green: What is. 22 00:01:55.470 --> 00:01:56.820 Andy Whiteside: Why don't why don't we call this. 23 00:01:57.870 --> 00:02:02.730 Andy Whiteside: Acropolis operating system 2202. 24 00:02:05.880 --> 00:02:15.720 Andy Whiteside: You know, for the new naming Convention everybody's using you guys are still doing numbers and what point you hit this plateau and the numbers don't make sense anymore you're not doing Acropolis 99.8 like a radio station. 25 00:02:15.840 --> 00:02:23.580 Jirah Cox: Actually, the features here it's just not evenly distributed right actually PC is on the 2202 bandwagon so. 26 00:02:24.900 --> 00:02:29.190 Jirah Cox: I don't know, maybe I always get there one day, maybe it doesn't maybe maybe it stays a rebel. 27 00:02:30.510 --> 00:02:41.490 Andy Whiteside: Well, so i'm somewhat on topic and we're going to jump into HP here in a second, but your attendance is new tannic is full of acronyms give us your top 10 off top your head your own spot. 28 00:02:41.880 --> 00:02:47.370 Jirah Cox: Oh man, we ship like five new ones like last week alone we got like the ND bees and nc eyes and. 29 00:02:47.400 --> 00:02:48.120 Harvey Green: that's right. 30 00:02:48.210 --> 00:02:55.020 Jirah Cox: And us is and all kinds of good stuff yeah Of course you got all the oldies but goodies ALS is and CBS. 31 00:02:57.060 --> 00:03:01.890 Andy Whiteside: Whose fault is that is that the technical guys that like acronyms or is that the marketing guy. 32 00:03:03.090 --> 00:03:05.610 Andy Whiteside: Who does the acronym madness to ask, I can tell you. 33 00:03:05.850 --> 00:03:06.180 Jirah Cox: man. 34 00:03:06.570 --> 00:03:11.820 Andy Whiteside: i'm not a newbie, but I have not to newbies to come into them into his integrity and watching them just. 35 00:03:13.050 --> 00:03:16.560 Andy Whiteside: eyes roll back in their heads, all the acronyms I have no idea what any of means. 36 00:03:17.760 --> 00:03:19.980 Andy Whiteside: it's kind of a little bit of a problem in our industry. 37 00:03:21.060 --> 00:03:25.170 Jirah Cox: So it definitely is industry wide right the tlc is a three letter acronyms. 38 00:03:26.250 --> 00:03:26.610 Andy Whiteside: yeah. 39 00:03:28.260 --> 00:03:33.060 Andy Whiteside: Is it because people don't know what they stand for, is it because people, just like to be cool and use the acronyms. 40 00:03:33.180 --> 00:03:36.090 Jirah Cox: A tradition, mostly I guess. 41 00:03:36.540 --> 00:03:37.020 yeah. 42 00:03:38.040 --> 00:03:39.600 Andy Whiteside: we're just trying to shortcut anyway. 43 00:03:39.660 --> 00:03:42.540 Jirah Cox: I don't know i'm going I don't I don't get pulled in those meetings. 44 00:03:44.700 --> 00:03:56.610 Andy Whiteside: Well, so what we're talking about today is the new tannic celebrating system Acropolis operating system ios six dot one I think i've said that multiple times now it's it's new where was the previous release. 45 00:03:57.540 --> 00:04:05.520 Andy Whiteside: 606 dot oh so we're looking at an incremental change here, based on that nomenclature name nomenclature. 46 00:04:06.450 --> 00:04:07.410 Jirah Cox: yeah it's the. 47 00:04:10.170 --> 00:04:15.900 Jirah Cox: Second SDS short term support release in this trade yeah. 48 00:04:17.370 --> 00:04:24.210 Andy Whiteside: i'd love to know is, who do you think decides whether it's when it becomes a new whole number, the technical guys the marketing guys. 49 00:04:24.990 --> 00:04:25.740 i'm. 50 00:04:26.940 --> 00:04:29.220 Jirah Cox: Both I don't know more meetings that i'm not in. 51 00:04:29.700 --> 00:04:33.570 Andy Whiteside: yeah I don't know if you use a MAC or not use a MAC or windows. 52 00:04:33.840 --> 00:04:34.980 Jirah Cox: or use a couple of X yeah. 53 00:04:35.400 --> 00:04:36.360 Andy Whiteside: yeah no windows. 54 00:04:36.450 --> 00:04:38.430 Jirah Cox: I remote into windows computer. 55 00:04:38.790 --> 00:04:39.930 Andy Whiteside: yeah windows 10. 56 00:04:40.200 --> 00:04:42.390 Jirah Cox: or windows, the windows 10 yep yeah. 57 00:04:42.780 --> 00:04:50.430 Andy Whiteside: I mean that's a great example of no more operating system, who had seven new one coming out every month and then all sudden the marketing guys hey I think it's not renewing they're going here comes a new. 58 00:04:50.790 --> 00:04:54.540 Jirah Cox: yeah right and then somebody can go like oh it's one of those 11 verses you know. 59 00:04:55.500 --> 00:04:56.010 Jirah Cox: It was actually. 60 00:04:57.150 --> 00:05:01.830 Harvey Green: The last version of windows you'll ever have and you'll ever need never be another one. 61 00:05:02.700 --> 00:05:03.390 Harvey Green: You know the bully. 62 00:05:03.750 --> 00:05:05.700 Jirah Cox: Both keeping up with each other, now they're both on 11. 63 00:05:06.600 --> 00:05:08.400 Andy Whiteside: i'm not gonna lie, I thought this was gonna be the top. 64 00:05:09.120 --> 00:05:09.930 Harvey Green: Oh. 65 00:05:10.830 --> 00:05:12.120 Jirah Cox: This is look at solder. 66 00:05:13.500 --> 00:05:17.550 Jirah Cox: People to inform us to hear our commentary about what a 15 year old os. 67 00:05:19.200 --> 00:05:26.730 Jirah Cox: probably never actually ran as their daily driver, but no vista definitely got got the short end of the stick there like it was unfairly maligned no. 68 00:05:27.300 --> 00:05:27.930 well. 69 00:05:29.280 --> 00:05:30.900 Andy Whiteside: windows me might have got it worse. 70 00:05:31.920 --> 00:05:33.150 Jirah Cox: windows, I mean deserved it. 71 00:05:38.790 --> 00:05:44.640 Andy Whiteside: Alright, so a crop this operating system six dot one incremental release gyro. 72 00:05:45.870 --> 00:05:56.310 Andy Whiteside: what's the does the intro in this blog have anything of relevance to it that kind of tips its hat to why six dot one came about, are we going to find that here in a minute we start going through it. 73 00:05:57.510 --> 00:05:59.910 Jirah Cox: I think it's pretty pretty awesome pretty well rounded release. 74 00:06:01.590 --> 00:06:09.630 Jirah Cox: Making yeah i'll say i'll say just agree with the intro right making on Prem and hybrid clouds everywhere just better overall. 75 00:06:11.730 --> 00:06:14.670 Andy Whiteside: yeah like oh see, I have a new guy that's going to be working for you guys I believe and. 76 00:06:15.450 --> 00:06:23.610 Andy Whiteside: He was a trying to understand from the interview process is new tannic software for the cloud or on premises, because it sounds like you just cloud. 77 00:06:23.970 --> 00:06:35.880 Andy Whiteside: And you know, obviously that's where your company wants people to go and they want to go with you at the same time, you know it's one heck of a cloud software that enables on premises and transitions into the cloud or or vice versa right back and forth. 78 00:06:36.210 --> 00:06:37.860 Jirah Cox: it's software for wherever your cloud is. 79 00:06:38.370 --> 00:06:42.690 Andy Whiteside: that's right defined cloud or better yet defined clouds and we can have that conversation. 80 00:06:44.880 --> 00:06:55.140 Andy Whiteside: Alright, so section one talks about the memory, or the first non introductory section memory overcommit for HIV, which stands for Acropolis hypervisor. 81 00:06:56.820 --> 00:07:01.890 Andy Whiteside: I tell me where that didn't work before where that was sort before and what you guys have done now. 82 00:07:02.700 --> 00:07:16.230 Jirah Cox: Sure yeah basically before it was all memory was one to one assigned blocked right So if you promised a vm eight gig memory, then we had to go find it a host somewhere and allocated for just that vm use, so it wasn't over committed wasn't shared. 83 00:07:17.460 --> 00:07:25.680 Jirah Cox: With this now, you can promise more memory to your virtual machines than they actually have present on the hosts in the cluster right so. 84 00:07:26.040 --> 00:07:30.600 Jirah Cox: something you know to do on other other hypervisor is for a while we're bringing it down to HP as well. 85 00:07:31.260 --> 00:07:43.860 Jirah Cox: With us exact same design considerations that have always existed elsewhere have if you promise too much and then use too much we can't make more memory for free that's a hardware defined limit, not a software defined limit. 86 00:07:44.910 --> 00:07:56.550 Jirah Cox: So use with us with consideration us carefully but it's fantastic for like live environments, you know development environments where you know you need to be able to spin up you know hundreds of vm. 87 00:07:58.560 --> 00:08:04.260 Jirah Cox: And, and the usage windows vm is very dynamic I had one customer years ago, who. 88 00:08:04.800 --> 00:08:16.320 Jirah Cox: Who every every night at midnight just powered off all other the other delphiniums and if you didn't come into work, the next day if you were off that day, then you your vm didn't take up any resources right you just powered them on when you got your coffee in the morning. 89 00:08:17.670 --> 00:08:30.030 Jirah Cox: So those kind of environments right where you aren't particularly picky about performance for any one single vm you just want you know, to let everybody see what needs to be seen by the at the os level absolutely great feature. 90 00:08:30.420 --> 00:08:43.470 Harvey Green: So let me highlight something that you said there and and do that by highlighting something you didn't say there you said Dev and you said test, but you did not say pride why. 91 00:08:45.060 --> 00:08:49.080 Jirah Cox: it's a it's totally up to the customer right it's what are your requirements for your environment. 92 00:08:49.590 --> 00:09:03.330 Jirah Cox: Personally, you know what I coach my customers is you know something to turn on for prod day one, maybe not right, which is why we've we've taken a very cautious approach to even if developing it shopping at HP is what seven seven years old now eight years old now. 93 00:09:05.010 --> 00:09:15.120 Jirah Cox: Because the as soon as you overcommit memory, then you have an opportunity for overdemand of memory and you have to get an interesting fun things like paging. 94 00:09:16.320 --> 00:09:23.100 Jirah Cox: and other other fun behaviors right that guess what are just not even something have to worry about with our memory overcommit enabled. 95 00:09:23.490 --> 00:09:25.350 Harvey Green: So i'll have to tell you this. 96 00:09:27.120 --> 00:09:44.280 Harvey Green: One of the, I guess, I will call it a safety one of the safeties that I always was happy that Nintendo his head was this one, where you could not just go out there and over commit your memory by you know 221321. 97 00:09:46.050 --> 00:09:51.750 Harvey Green: And so I like that this is in there and I also don't like this is. 98 00:09:53.460 --> 00:09:59.250 Jirah Cox: i'm with you i'm totally with the rv and and that's why it's a customer by customer environment by environment choice. 99 00:10:00.150 --> 00:10:05.070 Jirah Cox: to opt in i'm with you, if it was my environment to run I probably wouldn't enable it for production. 100 00:10:06.030 --> 00:10:10.560 Jirah Cox: i'm it took a meeting with one customer years ago, who they said, you know, without. 101 00:10:11.130 --> 00:10:20.400 Jirah Cox: Without this feature you'll never you know go and come in our data Center right in a major way, at least, and we looked at their V Center and they had they were running for two one in production right. 102 00:10:20.820 --> 00:10:41.640 Jirah Cox: At the at the hundreds of terabytes of memory scale and i'm like Okay, I can see your point where, if you're running this and managing it safely today, then, if I say you need to buy for X as much memory to run hv that might be challenging so you know use what you use wisely yes. 103 00:10:42.000 --> 00:10:47.700 Andy Whiteside: So, so I had forgotten this was in here because we never tell anybody that overcommit, even though I do understand. 104 00:10:48.570 --> 00:11:01.350 Andy Whiteside: That it makes me makes some sense to some people, the two questions for you guys one, what do they do in hyper scale lawyers, do they overcommit you and you don't realize it or you opt in or opt out what's How does it work there. 105 00:11:03.600 --> 00:11:04.110 Andy Whiteside: Do we know. 106 00:11:04.410 --> 00:11:06.480 Jirah Cox: I I think I couldn't give you a firm answer. 107 00:11:07.710 --> 00:11:11.250 Jirah Cox: They probably would tell you they probably would say doesn't matter if you can't tell. 108 00:11:11.880 --> 00:11:16.080 Jirah Cox: yeah right managing of what overcommit ratio might exist. 109 00:11:16.950 --> 00:11:24.270 Andy Whiteside: So here's the second part of that question, the second question, maybe they're tied together Harvey if you Okay, so if you don't do it in memory. 110 00:11:25.980 --> 00:11:33.420 Andy Whiteside: In other words, if you overcommit and it's not able to happen in real physical memory and it has to go somewhere else, where does it go. 111 00:11:36.210 --> 00:11:38.310 Harvey Green: me make sure I understand the question if. 112 00:11:38.820 --> 00:11:39.930 Jirah Cox: it's a question or pop quiz. 113 00:11:42.720 --> 00:11:50.370 Andy Whiteside: So if you if you overcome it and you run out of physical memory and it has to start paging or you know traditional paging. 114 00:11:51.450 --> 00:12:00.450 Andy Whiteside: So, I guess, a new machine if it runs out in this case it thinks it still has it does it does the system start doing paging page swaps for you. 115 00:12:00.930 --> 00:12:08.940 Jirah Cox: Right yeah usually that's same thing happens inside the ios can happen outside the ios inside the osu page into your windows page file or Linux page. 116 00:12:10.110 --> 00:12:18.120 Jirah Cox: Like swap partition and, similarly, a vm can page out to you know, have the EMS allocated page files as well, but. 117 00:12:18.270 --> 00:12:21.480 Andy Whiteside: If i'm doing that in a system where i'm going to a file and i've got. 118 00:12:22.740 --> 00:12:28.620 Andy Whiteside: You know envy me or ssd that slow the slow i'm i'm still pretty darn fast right. 119 00:12:30.510 --> 00:12:30.750 Jirah Cox: or. 120 00:12:32.970 --> 00:12:34.560 Jirah Cox: Perhaps, maybe for a certain point of view. 121 00:12:34.560 --> 00:12:34.950 Although. 122 00:12:35.970 --> 00:12:45.390 Jirah Cox: I probably would agree with that right if it's if a vm things its memory unexpected memory speed that your orders of magnitude slower, even going to disk there. 123 00:12:46.500 --> 00:13:00.780 Harvey Green: Well, and so the other thing that I would bring up is even if I ignore the rest of what's going on the fact that you are now paging potentially to a physical disk at this point. 124 00:13:01.260 --> 00:13:13.770 Harvey Green: makes you nowhere near as portable as you used to be, and so, in the event of a disk failure or node failure, all of the all of the magic of new tactics and this you know. 125 00:13:14.580 --> 00:13:29.250 Harvey Green: resilient system is no longer in my eyes as resistant and me as resilience and maybe they've got some more magic on the back end that I just don't know about yet, but I just don't like the setup. 126 00:13:30.630 --> 00:13:35.010 Jirah Cox: Well, and also lastly there's probably no world where that makes economic sense if you. 127 00:13:35.130 --> 00:13:37.050 Jirah Cox: want X amount of memory. 128 00:13:37.080 --> 00:13:44.430 Jirah Cox: Sorry that's a harsh answer but probably true if you bought X amount of memory and then you fill it all up and you clearly objectively need more. 129 00:13:45.810 --> 00:13:49.290 Jirah Cox: The storage tier there isn't a costume more than buying a memory that you clearly made. 130 00:13:49.530 --> 00:13:56.640 Jirah Cox: Right so maybe it's a stopgap emergency method, but but, in reality, like you just buy more memory by what you need yeah. 131 00:13:57.420 --> 00:14:02.430 Harvey Green: This is why I both like that it's there and I don't like that it's the. 132 00:14:03.570 --> 00:14:11.040 Jirah Cox: Time in a place right that what I ironically given you know our venn diagram here of our skill sets I can picture. 133 00:14:12.150 --> 00:14:17.880 Jirah Cox: Any you see environment being actually punish a great candidate right very, very thirsty workloads. 134 00:14:19.230 --> 00:14:32.310 Jirah Cox: Lack of lack of very thirsty a lot of not a lot of insight into like potentially what's my our by our forecasted need right, so I can make some promises here for the environment in general paint with a broad brush and then trust the ball sort of self out. 135 00:14:34.110 --> 00:14:51.480 Andy Whiteside: Well, so here's what I was getting out with all that I get the way we used to be scared of doing this when we had slower drives we had less smart architecture, but with the Acropolis operating system, control and storage layer i'm less scared of overcoming, then I was back then. 136 00:14:53.220 --> 00:15:01.200 Harvey Green: with which I agree with the merits of that and that's honestly why it makes me even more risky because. 137 00:15:02.490 --> 00:15:23.700 Harvey Green: I could see the potential of somebody you know, taking that mindset and then over committing on purpose on to the point that they can, to the point that, when they do actually need to overcome if they don't have that as a luxury anymore. 138 00:15:24.270 --> 00:15:27.900 Andy Whiteside: Well that's why I brought up, I wonder what the hyper steelers do they don't tell us do they they. 139 00:15:28.260 --> 00:15:31.590 Andy Whiteside: Because they're Point two divers like you can't tell, then you don't need to know. 140 00:15:33.750 --> 00:15:34.830 Harvey Green: that's exactly right. 141 00:15:36.300 --> 00:15:44.820 Harvey Green: And maybe maybe this is the same way I haven't seen it in action, yet, and maybe maybe i'm being overly cautious but. 142 00:15:46.170 --> 00:15:47.970 Harvey Green: i'll be overly cautious. 143 00:15:48.270 --> 00:15:56.340 Andy Whiteside: It would be neat to be able to go to the hyper scales and figure it out that way for examples INTEGRA has new tactics running in our data centers we offer that as a cloud, we could. 144 00:15:56.610 --> 00:16:07.830 Andy Whiteside: We could say that if you check this box or sign on this agreement you've never had that happen you don't have to come check behind us to try and see if you're getting over committed or not, it just you know here's an agreement they won't happen. 145 00:16:09.330 --> 00:16:09.600 yeah. 146 00:16:11.940 --> 00:16:18.150 Andy Whiteside: All right, let's go to the topic we all love talking about the most which is databases how we're going to make these things scale up. 147 00:16:19.260 --> 00:16:22.170 Andy Whiteside: In the new Acropolis operating system six that one. 148 00:16:23.640 --> 00:16:25.800 Jirah Cox: yeah, so this is, this is a very exciting. 149 00:16:26.880 --> 00:16:34.140 Jirah Cox: enhancement that, in a nutshell right we call it kind of vetoes charting but basically it lets a virtual disk controller. 150 00:16:35.400 --> 00:16:39.990 Jirah Cox: run in a multi threaded fashion, so we can get multiple paths to get to the same disk. 151 00:16:41.730 --> 00:16:49.110 Jirah Cox: That dramatically in this in this release speeds up the Read performance is quite a bit, so this you know we've said, for years, we still say. 152 00:16:49.650 --> 00:16:58.080 Jirah Cox: The best way to get performance out of your databases with multiple disks it's also in like the sequel and Oracle best practices right lots of disks and spread your data files across them. 153 00:16:59.250 --> 00:17:07.860 Jirah Cox: First, you know, some people when they first moved to new tannic then that's maybe not practical they can't get the downtime to take the database offline and relay it out onto multiple data files. 154 00:17:08.460 --> 00:17:15.510 Jirah Cox: So we still want to ship enhancements that helped them out where they are right so help those single large databases run faster. 155 00:17:16.170 --> 00:17:29.310 Jirah Cox: And so that's what this enhancement is doing here is improving the performance for that by some some really dialing numbers you don't we don't want to you know read bar charts here into audio form but take a look at it it's it's very compelling stuff. 156 00:17:31.200 --> 00:17:42.480 Andy Whiteside: We could use the numbers, the percentage number, but let me just visual explain the visual here in terms of what it does so we've got our hypervisor inside the hypervisor is a control vm star controller. 157 00:17:43.500 --> 00:17:49.680 Andy Whiteside: It runs stargate real quick direct tin tin 22nd definition what stargate is. 158 00:17:49.920 --> 00:18:02.640 Jirah Cox: Yes, very good is the process by which you know, a hypervisor you know sends io requests to mechanics and then we figure out what node and what disk needs to service all of those stargate because you can kind of go in anywhere and come out anywhere else. 159 00:18:03.780 --> 00:18:11.370 Andy Whiteside: And then that hands off to the V disk controller we talking to software inside the control vm I guess to be are based on the. 160 00:18:11.400 --> 00:18:16.170 Jirah Cox: Right so like what what part of all what part of our code owns like your C drive or your D drive. 161 00:18:16.740 --> 00:18:17.070 yeah. 162 00:18:18.690 --> 00:18:22.680 Andy Whiteside: And then now we're getting down to a single V disk in parallel. 163 00:18:23.730 --> 00:18:25.740 Andy Whiteside: reads and writes or just reads. 164 00:18:26.070 --> 00:18:28.350 Jirah Cox: This one enhances rates OK. 165 00:18:29.820 --> 00:18:30.120 Andy Whiteside: OK. 166 00:18:33.150 --> 00:18:40.680 Andy Whiteside: So now, I mean i'm playing devil's advocate through well okay so it's always important if i'm the the storage guy I want to. 167 00:18:40.950 --> 00:18:54.150 Andy Whiteside: Okay, I want my readers to be right, but I sure as heck one my rights to be right, so what you guys are doing here is you're making the reads a lot faster maybe a step one to doing this process getting more getting more performance out of access to that data. 168 00:18:54.870 --> 00:19:00.660 Jirah Cox: Right and number of reads and writes can follow different code paths so that's why you can see an enhancement that hits one of those and not the other yeah. 169 00:19:01.980 --> 00:19:13.290 Andy Whiteside: And then, if I go down here to the bar chart i've got the green bar and now the blue bar and it looks like on the right hand side i'm getting significantly more something's. 170 00:19:13.980 --> 00:19:16.080 Jirah Cox: that's on the left there right the use case you know. 171 00:19:16.290 --> 00:19:25.200 Jirah Cox: single V disk right, so if you've moved from like a three tier deployment of your database and moved on new tonics without sort of following our best practices. 172 00:19:25.800 --> 00:19:29.040 Jirah Cox: sequel Oracle best practices still on a single large V disk. 173 00:19:29.520 --> 00:19:43.860 Jirah Cox: Performance improvement there, but then, also on the right side if you are deploying it cornea best practices, even more benefit for you there right, because now if you're deployed across 888 disk and the system those all benefit from the improvement as well, so, then you get even more. 174 00:19:44.880 --> 00:19:46.470 Jirah Cox: even faster read enhancement. 175 00:19:49.980 --> 00:20:00.000 Andy Whiteside: Well, and that just continues to show that new tannic serious about getting those naysayers on the database side over to new tactics. 176 00:20:00.120 --> 00:20:00.480 yeah. 177 00:20:04.230 --> 00:20:08.730 Andy Whiteside: um let's move on to the next one, because I know Harvey didn't want to talk about the database, one that much. 178 00:20:12.000 --> 00:20:18.450 Andy Whiteside: You have a you have any dog in that database file Harvey are you just gonna say yeah I did uh. 179 00:20:20.790 --> 00:20:22.140 Harvey Green: yeah do. 180 00:20:24.450 --> 00:20:31.020 Andy Whiteside: The next one talks about something that sounds extremely interesting octane slash envy me. 181 00:20:31.620 --> 00:20:47.610 Andy Whiteside: tearing I know envy me has been a hot topic at least for me the last couple years because anything fast and anything fastest good anything unbelievably fast is good he's a better it's over what what are you guys doing it this piece of the enhancements. 182 00:20:47.850 --> 00:20:53.460 Jirah Cox: yeah I think I think this first graphic kind of tells a really fun story where it shows you know hard disk drives spinning, you know magnetic. 183 00:20:53.880 --> 00:21:05.640 Jirah Cox: Storage less than 500 I OPS per device and ssd maybe call it 20,000 I OPS per device envy me ssd 400,000 and obtain maybe 550,000 so. 184 00:21:05.970 --> 00:21:20.910 Jirah Cox: All still crazy fast, but there's a little bit of daylight between the envy me performance, the paint performance with this enhancement now as storage can differentiate between those two things so used to be, they were both just so crazy fast, they would go into one tier together. 185 00:21:22.350 --> 00:21:28.710 Jirah Cox: The the tearing them out here now lets us, you know deliver say like obtain tier performance. 186 00:21:29.610 --> 00:21:38.010 Jirah Cox: To the very hottest subsets of data right like think back to when we you know our first launched with our very tiny as as DS and spinning disks. 187 00:21:38.520 --> 00:21:47.940 Jirah Cox: Are hybrid nodes right but, but you can get very, very fast performance out of them, because all the hot data went on to the hottest tier of storage on in that case ssd. 188 00:21:48.390 --> 00:21:57.750 Jirah Cox: This brings back that same kind of functionality, right now, if I had the system that had octane plus envy me drives my very hardest data goes into the very hottest tier of storage. 189 00:21:59.370 --> 00:22:08.010 Andy Whiteside: So spinning hard drives were great back in the day, and then we got to ssd and then we got to India me now the fastest thing is Intel obtain. 190 00:22:08.340 --> 00:22:15.510 Jirah Cox: yep yeah it's a it's it's candidly very weird to say you can configure system where envy me is the slow tier. 191 00:22:17.400 --> 00:22:21.780 Andy Whiteside: Where does the Intel obtain live in regard to the system board. 192 00:22:23.490 --> 00:22:30.570 Jirah Cox: It looks like a regular desk or you'd see it next year, you know ssd it's still another form of solid state, but that works kind of diluted right. 193 00:22:32.070 --> 00:22:34.380 Jirah Cox: it's another form of stories that we just live in a disk slot. 194 00:22:35.520 --> 00:22:53.820 Andy Whiteside: And I was under the impression end me was partially fast because of where it's set in relation to the system board and not having to go through a storage controller is the Intel obtain just so fast going through a controller is irrelevant and it's just reads and writes fs. 195 00:22:54.000 --> 00:23:03.780 Jirah Cox: My understanding is that both of them are are you know pci devices right so and both of them can bypass control or they just become become pci E devices. 196 00:23:08.730 --> 00:23:09.240 Andy Whiteside: yeah I mean. 197 00:23:10.290 --> 00:23:11.070 Andy Whiteside: What needs that. 198 00:23:12.600 --> 00:23:21.720 Harvey Green: yeah i'm sitting here, just like shaking my head, because all I hear is it went from crazy fast to stupid fast. 199 00:23:23.790 --> 00:23:30.120 Jirah Cox: And that's part of the value prop right, we want the software to be ready for the hardware and the demands of tomorrow. 200 00:23:31.500 --> 00:23:38.310 Jirah Cox: And and evolve to let you the customer take advantage of the latest and greatest hardware without changing your management. 201 00:23:38.970 --> 00:23:50.340 Jirah Cox: plane without having to rework the workloads, you know as the hardware gets better it's easy to add those kind of nodes to the cluster move workloads on to it inject the oldest nodes in the cluster and get on with your life. 202 00:23:51.030 --> 00:24:11.070 Harvey Green: yeah i'm sitting here, looking at this chart and it's talking about the latency between the two and starts out on the left with hard drives it more than two milliseconds then we get into microseconds and here we are going from less than 100 microseconds all the way down to 10 so. 203 00:24:12.810 --> 00:24:13.650 Harvey Green: This is. 204 00:24:15.060 --> 00:24:17.610 Harvey Green: whoo that's that's fast. 205 00:24:18.630 --> 00:24:18.990 Jirah Cox: It is. 206 00:24:19.140 --> 00:24:21.330 Harvey Green: very fast so. 207 00:24:21.360 --> 00:24:25.800 Andy Whiteside: dire we have a nice diagram kind of a flow workflow here on the screen wants you to explain this. 208 00:24:30.630 --> 00:24:33.960 Jirah Cox: Is a verbal whiteboard in a in an audio medium. 209 00:24:34.320 --> 00:24:36.840 Jirah Cox: And it shows the right path right now. 210 00:24:37.860 --> 00:24:46.800 Jirah Cox: reads can come from lots of places right both persistent storage and you know whether that's hot or cold to your storage, as well as even. 211 00:24:47.280 --> 00:24:54.660 Jirah Cox: The cash that can live within the CRM itself and then rights go through our blog and then find their way to where they need to live elsewhere in the system as well. 212 00:24:55.680 --> 00:24:55.920 yeah. 213 00:25:01.500 --> 00:25:22.470 Andy Whiteside: This next there's another bar chart here it basically just talks about either all envy me versus envy me plus obtain so help me understand this in the case of envy me plus obtain, would you be using which one would be the fast one octane, of course, right. 214 00:25:23.820 --> 00:25:32.100 Jirah Cox: Right yeah yeah and all envy me versus and we may pose an opt in to your updating devices are like tiny right think about like 200 gig 400 gig. 215 00:25:33.540 --> 00:25:42.330 Jirah Cox: If I can get a bigger than that but, like commonly deployed sizes are there they're tiny but that latency is crazy low right so letting the hottest amount of data flow on to those. 216 00:25:44.250 --> 00:25:50.310 Andy Whiteside: lungs obtain that around because I I thought I was the cool kid talking about envy me and I didn't know, I was dating myself. 217 00:25:50.610 --> 00:25:51.480 um. 218 00:25:52.860 --> 00:25:57.150 Jirah Cox: I mean Wikipedia probably would say like five six years, maybe what venture to guess on my part, but. 219 00:25:57.990 --> 00:25:59.370 Harvey Green: Just a couple years. 220 00:25:59.430 --> 00:26:02.700 Jirah Cox: takes a while to find stuff for free protect find its way into the data Center right. 221 00:26:02.910 --> 00:26:12.510 Andy Whiteside: Right right alright so here's a question and obtain drive computer didn't VOC a terabyte of August, you just said what's the biggest opportunity would find Dr. 222 00:26:12.990 --> 00:26:18.510 Jirah Cox: I the ones I feel like I handle commonly in a configuration or yeah like 200 gig 400 gig. 223 00:26:19.230 --> 00:26:25.410 Andy Whiteside: So 200 gig versus 200 gig India me versus 200 gig ssd if there is such thing anymore. 224 00:26:25.710 --> 00:26:27.810 Andy Whiteside: But what give me pricing like. 225 00:26:27.870 --> 00:26:29.610 Jirah Cox: I are not a hardware guy. 226 00:26:31.290 --> 00:26:32.850 Jirah Cox: I mean newegg.com I don't know. 227 00:26:34.890 --> 00:26:35.190 Andy Whiteside: Okay. 228 00:26:36.450 --> 00:26:37.500 Andy Whiteside: All right, i'm learning a lot here. 229 00:26:38.550 --> 00:26:52.260 Andy Whiteside: Alright next section talks about the enhanced business continuity encrypted Dr traffic improve ios vss provider let's go with the encrypted Dr traffic that's pretty self explanatory but. 230 00:26:52.650 --> 00:26:58.470 Jirah Cox: yeah maybe some of harvey's customers over on on the on the Gulf side you know have stronger preferences around. 231 00:26:58.830 --> 00:27:10.440 Jirah Cox: I want all the application traffic from A to B to be encrypted and now that's an easy that's an easy, yes, without needing to bring in like another vpn tunnel or doing like switch to switch IP SEC. 232 00:27:13.560 --> 00:27:14.520 Andy Whiteside: yep so easy enough. 233 00:27:15.570 --> 00:27:22.080 Andy Whiteside: Improved ALS so across the substrate operating system vss provider. 234 00:27:23.610 --> 00:27:26.130 Andy Whiteside: I think I should know what vss means but somebody educate me. 235 00:27:27.150 --> 00:27:39.840 Jirah Cox: that's the volume snapshot service, I might have that a little bit off, but that's because what it does, is it lets you it's it's how you can do in gas gas right for in guest data when you're taking a backup. 236 00:27:42.540 --> 00:27:46.410 Jirah Cox: commonly of stuff like sequel or outlook back in the day when we ran outlook on Prem. 237 00:27:48.510 --> 00:27:58.680 Jirah Cox: So with these enhancements you can do stuff like incremental backups or, if you have multiple vss writers, you can target which one you want to have class for the given snapshot. 238 00:28:00.780 --> 00:28:03.840 Andy Whiteside: I just I used to shut on my vm down take my backups. 239 00:28:05.700 --> 00:28:07.410 Andy Whiteside: there's not there's not a secret anymore I don't. 240 00:28:07.890 --> 00:28:10.170 Jirah Cox: throw the tapes in the trunk drive to the safe deposit box. 241 00:28:12.270 --> 00:28:16.050 Andy Whiteside: I couldn't take my brakes until the storage that tape backup guy showed up every day. 242 00:28:20.550 --> 00:28:23.490 Andy Whiteside: Okay Harvey any comments on either one of those. 243 00:28:24.540 --> 00:28:28.530 Harvey Green: No, I mean this, these are all very, very good things I like. 244 00:28:30.810 --> 00:28:31.680 Jirah Cox: harvey's a fan. 245 00:28:32.700 --> 00:28:44.370 Andy Whiteside: Alright next section talks about deeper storage inside starts with a E s on hybrid clusters, or they were at least are nice enough to give us the what he stands for autonomous extent store. 246 00:28:45.960 --> 00:28:48.240 Andy Whiteside: What is this on hybrid clusters do for me. 247 00:28:48.720 --> 00:28:50.250 Jirah Cox: So, as we shipped. 248 00:28:51.510 --> 00:28:55.110 Jirah Cox: miss a couple years ago in round terms, it was one of our next. 249 00:28:56.370 --> 00:28:58.620 Jirah Cox: headlines that brought. 250 00:29:00.480 --> 00:29:10.230 Jirah Cox: yeah this feature called upon a success story, which I describe it when i'm whiteboarding for customer has made a data locality right, so you you write data in your vm. 251 00:29:10.710 --> 00:29:26.040 Jirah Cox: We write metadata as the storage provider around where that data lives in the system right So if you wrote a megabyte of data that our system is to record what node is storing that and on what desk and then what other node and what other disk system is storing it for like say rf two. 252 00:29:27.540 --> 00:29:35.190 Jirah Cox: minutes to locality says hey with it with a is here, what if we let the cluster not worry about all the details right. 253 00:29:35.700 --> 00:29:46.770 Jirah Cox: If the node wants to move from disk one to disk disk to that's a node local decision and the rest of us are doesn't have to care about that right so less Meta data stored globally. 254 00:29:47.670 --> 00:29:59.280 Jirah Cox: mean smaller databases means faster performance and then, so what this is really talking about here is now that functionality comes to hybrid notes so yea it was all flash and faster nodes for a long time. 255 00:30:00.240 --> 00:30:04.710 Jirah Cox: So now even even your ssd plus spinning this systems get to get to benefit from that. 256 00:30:05.850 --> 00:30:06.930 Jirah Cox: enhance performance as well. 257 00:30:10.080 --> 00:30:11.400 Andy Whiteside: or read comments. 258 00:30:13.230 --> 00:30:14.010 Harvey Green: nope. 259 00:30:14.310 --> 00:30:15.420 Harvey Green: harvey's a fam like it. 260 00:30:17.430 --> 00:30:19.920 Harvey Green: These these are like checking boxes for me right now. 261 00:30:22.080 --> 00:30:26.730 Andy Whiteside: Alright next section talks about storage consumption reporting improvements. 262 00:30:27.930 --> 00:30:32.070 Andy Whiteside: Probably pretty straightforward but jarrod give us give us what this does and what it means for. 263 00:30:33.120 --> 00:30:33.450 Jirah Cox: yeah. 264 00:30:34.530 --> 00:30:38.280 Jirah Cox: Totally beefing up the storage widget there on the prism dashboard. 265 00:30:39.900 --> 00:30:50.940 Jirah Cox: biggest one I love here is showing the snapshot usage versus actual data storage usage right so more details more at your fingertips easier to use good stuff. 266 00:30:54.150 --> 00:30:59.280 Andy Whiteside: Have you can you think of a time where this information would have been valuable that you didn't have. 267 00:30:59.610 --> 00:31:00.360 Yes. 268 00:31:02.340 --> 00:31:21.300 Harvey Green: Literally exactly what you just described, where a customer was storing a bunch of snapshots and did not did not fully recognize why they were lacking in storage and you know, sometimes. 269 00:31:22.560 --> 00:31:30.600 Harvey Green: From a customer standpoint, you want to make sure you have I mean try this customer they they wanted to have a lot of. 270 00:31:32.190 --> 00:31:40.440 Harvey Green: A lot of backup copies because they had just emerged from a ransomware event that they did not discover for a couple weeks. 271 00:31:41.010 --> 00:31:47.550 Harvey Green: And so they you know, one of the ways that they wanted to move forward was to make sure that they had. 272 00:31:48.000 --> 00:31:58.320 Harvey Green: A month worth of snapshots to go back to, but there was no real thought given to what kind of space that would take up for them. 273 00:31:59.070 --> 00:32:19.620 Harvey Green: So they started eating through a lot of space and wondering why in the world they're fairly new system was not giving them the amount of storage space that they expected and being able to see this much more easily would have saved them at least some time and heartache. 274 00:32:20.640 --> 00:32:36.840 Jirah Cox: yeah I can think of that or you know it's it's more fashionable nowadays to have like say two data centers and you don't call them prod and Dr right we're one is all running all the all the workloads one's running none. 275 00:32:37.950 --> 00:32:51.930 Jirah Cox: Now you're typically more active active and you run half the things on each one, and of course it's it's still the case that if you can do application level availability that's always better than infrastructure level availability like active directory does application level availability. 276 00:32:55.890 --> 00:33:01.830 Jirah Cox: With that right have had a cluster that was running some vm but also receiving replicas of other vm from other sites. 277 00:33:02.310 --> 00:33:16.410 Jirah Cox: This would be immediately useful to say here's what the clusters consuming locally for its own vm maybe it's replicating those elsewhere and then other vm or our incoming by replication what's the space breakdown between those two kinds of buckets of data, yes. 278 00:33:17.070 --> 00:33:24.270 Andy Whiteside: Is it fair to say this data was available, but at a lower level somewhere in the Shell somewhere versus in the ui. 279 00:33:24.510 --> 00:33:29.820 Jirah Cox: yep totally agree more up to the surface surface and easily reportable. 280 00:33:30.930 --> 00:33:39.690 Andy Whiteside: I mean it may or may not have happened but way back in the day I might have been able to find this stuff through a cry, but I just started deleting snapshots until I saw the desired result that might have happened I don't. 281 00:33:41.280 --> 00:33:45.930 Jirah Cox: mean between that and and Andy just letting them rip with. 282 00:33:47.070 --> 00:33:50.550 Jirah Cox: memory over consumption Harvey i'm hearing you need to double check so. 283 00:33:53.160 --> 00:33:55.620 Andy Whiteside: They haven't let me out of the lab scenario and a long. 284 00:33:55.620 --> 00:33:57.090 Andy Whiteside: Time oh okay. 285 00:33:59.760 --> 00:34:09.510 Andy Whiteside: All right, enhanced virtual networking, the first thing I saw when I glanced down was this three letter acronym vpn what's what's this thing about the southern that extension piece. 286 00:34:10.320 --> 00:34:17.520 Jirah Cox: So vpn or oh yeah right and then also really vpc as well, so like virtual virtual private clouds. 287 00:34:18.720 --> 00:34:28.080 Jirah Cox: So with this now with the flow networking, you can extend your sub nets across sites now, which is very exciting so that. 288 00:34:28.470 --> 00:34:38.700 Jirah Cox: That you can now have a software to find something that that you know you see it as spanning both of these two data centers in reality that you have no network harbor supporting that and right all done in software. 289 00:34:40.290 --> 00:34:47.190 Andy Whiteside: yeah I could see this being very values, is there any type of latency requirement sub sub millisecond to do this, or is it doesn't matter. 290 00:34:48.930 --> 00:34:57.270 Jirah Cox: I don't have a chapter in verse memorized on that one I assume laws of physics still apply So if you have bad latency you can probably not have a great day, turning this on. 291 00:34:58.140 --> 00:35:04.290 Andy Whiteside: yeah but you talked a while ago about having you know active active data centers workloads in both places. 292 00:35:04.320 --> 00:35:04.740 Jirah Cox: Totally. 293 00:35:05.010 --> 00:35:11.820 Andy Whiteside: I guess you could have application performance issues but, in general, your data Center just logically became two places. 294 00:35:12.240 --> 00:35:21.300 Jirah Cox: 100% yeah give me good software defined networking is built on a foundation of good hardware defined networking right so thou shalt have good latency and throughput. 295 00:35:21.750 --> 00:35:29.670 Jirah Cox: And then you have a great experience, using a software defined overlay On top of that, for ease of management and mobility which. 296 00:35:30.150 --> 00:35:32.370 Harvey Green: Which direct commandment laws that. 297 00:35:33.240 --> 00:35:34.170 Harvey Green: have good latency. 298 00:35:34.890 --> 00:35:37.050 Jirah Cox: We call it number one have a good network. 299 00:35:39.330 --> 00:35:52.440 Andy Whiteside: It was funny I was in Cancun, last week I couldn't communicate with anybody I tried every APP I can think of friend of mine recommended I use, you know what's that he's like oh my European friends yeah like yeah but if I have bad networking it doesn't matter whatever i'm using. 300 00:35:54.360 --> 00:36:01.050 Andy Whiteside: It was funny i'm not a non technical person, but they have the answer like look you got bad network you got bad network you can't do much about it. 301 00:36:03.960 --> 00:36:06.240 Harvey Green: that's like not having enough memory earlier. 302 00:36:08.640 --> 00:36:13.020 Jirah Cox: What Harvey it sounds like you're saying I can't just go download more memory I don't understand yeah. 303 00:36:13.080 --> 00:36:13.470 No. 304 00:36:15.930 --> 00:36:22.680 Andy Whiteside: All right, multiple external networks is a call out here what's has that as a subset of enhanced the virtual network. 305 00:36:23.880 --> 00:36:30.990 Jirah Cox: yeah the the example given here I think it's super neat where within within a vpc right, we could define different. 306 00:36:31.410 --> 00:36:35.760 Jirah Cox: Rules to say when this virtual machine wants to go talk to an internal service like active directory. 307 00:36:36.360 --> 00:36:49.470 Jirah Cox: don't net to go do that when I do want to go out to the Internet or perhaps other targets do nat do using that to for that that traffic flow so have more control more flexibility for the way your Apps need to behave. 308 00:36:53.280 --> 00:36:57.060 Andy Whiteside: And this is all relative to building these clouds within a cloud concept. 309 00:36:58.080 --> 00:37:00.360 Jirah Cox: Right yeah fundamentally right, how do we help. 310 00:37:01.830 --> 00:37:09.810 Jirah Cox: You know it teams open up their APP store or their their hosting ability for their internal teams to go and deploy Apps. 311 00:37:10.260 --> 00:37:23.940 Jirah Cox: without needing to do sort of hard fixed allocation on real networks on real switches every single time right if you can get in software, if I could have overlapping sub nets right which is. 312 00:37:24.780 --> 00:37:32.430 Jirah Cox: very crucial for like hosting providers, you know all these problems that we have to solve that are easily more easily solved in software than they are in hardware. 313 00:37:33.090 --> 00:37:33.300 Right. 314 00:37:35.340 --> 00:37:50.280 Andy Whiteside: next section here says simplified management and automation the first subsection says vm templates for HIV Is this something that age v's catching up with the rest of the guys in terms of template management process. 315 00:37:50.400 --> 00:37:53.970 Jirah Cox: I think it even brings a couple a couple of new tricks a bit slave as well. 316 00:37:55.350 --> 00:38:06.330 Jirah Cox: The the, this is the feature i'd say for sure hop into the test drive environment kick the tires on it see what you can do, because one of the really neat tricks is the ability to. 317 00:38:07.470 --> 00:38:14.850 Jirah Cox: version your templates right, so I can like going back to like an EDC environment, I can say this is my February 2022. 318 00:38:15.330 --> 00:38:23.400 Jirah Cox: template and then I can go and deploy 100 games from that 200 games from that next one that powered on I apply my updates and security patches. 319 00:38:23.910 --> 00:38:36.720 Jirah Cox: And I check that back into the library, as the march 2022 template right so that that concept of version and templates and flagging them for availability internally for consumption, I think, is really, really slick. 320 00:38:39.660 --> 00:38:40.020 Andy Whiteside: rv. 321 00:38:41.250 --> 00:38:49.200 Andy Whiteside: And he got history tons of history with the items and templates and rolling out from templates and, yes, where does this fit in your. 322 00:38:50.460 --> 00:38:54.930 Harvey Green: Well, I mean just just makes the process easier, this is. 323 00:38:56.370 --> 00:39:01.320 Harvey Green: A new set of features kind of what Dan was talking about that we can use to help with. 324 00:39:02.580 --> 00:39:14.430 Harvey Green: Some some future os deployments that are outside of the outside of the purview of you know other imaging type software, this is something that is built in that you no longer have to. 325 00:39:15.120 --> 00:39:21.570 Harvey Green: either go create a process yourself or they'll use some other third party tool to you know help you make this happen. 326 00:39:27.060 --> 00:39:29.850 Andy Whiteside: next section talks about multi node removal. 327 00:39:31.290 --> 00:39:41.700 Jirah Cox: So to paint a word picture here, if I had say an eight node cluster and I wanted to eject three of those nodes to go send the monitor we mission to start a new cluster for a new. 328 00:39:42.090 --> 00:39:50.340 Jirah Cox: purpose right the ability to add grow clusters shrink clusters long standing mechanics value prop that you can grow and shrink as your as your needs change. 329 00:39:51.480 --> 00:40:05.340 Jirah Cox: If I wanted to inject those three nodes before now, I would object to know date of the note seven and the notes six and when I injected node eight right i've got data on there that I had to move elsewhere in the cluster so that note eight becomes empty, and I can walk away with it right. 330 00:40:06.450 --> 00:40:18.990 Jirah Cox: So you could potentially imagine that I might have moved the same bits from eight to 972 notes six and then to somewhere else in the cluster like four times, can I kind of wasted work there, so now with this enhancement a you can tell it. 331 00:40:20.820 --> 00:40:22.020 Jirah Cox: That you can. 332 00:40:24.540 --> 00:40:31.050 Jirah Cox: Remove multiple at a time, and it also doesn't therefore do cause itself any rework there to shuffle those bits over and over and over again. 333 00:40:32.370 --> 00:40:38.790 Andy Whiteside: And i'm assuming obviously that it does the math and make sure that that's safe to remove all those and me, I didn't wouldn't be in here, but I. 334 00:40:39.030 --> 00:40:49.860 Andy Whiteside: mean that this thing is very useful because more than likely when you're sizing down a cluster cluster cluster you're probably going to do more than one node if you're retiring some older stuff are moving stuff around. 335 00:40:50.250 --> 00:40:58.590 Jirah Cox: Totally right, I mean it's applicable to what's what's now a reality for our customers right that has been with us for for long enough now on their server. 336 00:40:58.950 --> 00:41:08.610 Jirah Cox: server virtualization workloads if you had a let's say in a cluster you know running your data Center maybe you bring in the latest hottest Intel R amp D cpus maybe you need six nodes now. 337 00:41:10.200 --> 00:41:20.190 Jirah Cox: we've said, for years, but now it's finally a reality for you that's like the easiest upgrade you don't have to do at all you just add those six nodes to your cluster for like three days you're running a 14 node cluster. 338 00:41:20.850 --> 00:41:27.840 Jirah Cox: And then, what you would have used to had to do was just you know one one week just go in and check the note every day right just eject eject eject. 339 00:41:28.200 --> 00:41:39.600 Jirah Cox: Every day, with your coffee you're just rejecting a different node and eventually you're down to those six new nodes now that's one click for you, instead of eight clicks to reject those eight old nodes right. 340 00:41:40.830 --> 00:41:45.390 Andy Whiteside: There it's not have that conversation I think about the two or three times I retired of saying in my career and. 341 00:41:45.840 --> 00:41:56.190 Andy Whiteside: The joys of rolling that thing out the door, which was joy, also the fact that point, sometimes it didn't fit in and out the door or in the elevator and you're going Helen heck they get it up here I don't get it down. 342 00:41:58.740 --> 00:42:03.720 Andy Whiteside: Alright, so next section talks about storage container management in prison central. 343 00:42:05.430 --> 00:42:21.960 Jirah Cox: Well, so bringing more of the what's traditionally been a prison element function up in the prison central, making it therefore under the purview of PC are back and robust control and also decentralized right, so I can now see all my containers across all my clusters in one spot. 344 00:42:24.300 --> 00:42:26.940 Andy Whiteside: I missed the opportunity to talk about the crew that acronym. 345 00:42:27.720 --> 00:42:28.110 yeah. 346 00:42:29.220 --> 00:42:31.560 Jirah Cox: that's that was not compliant it's a four letter acronym. 347 00:42:33.750 --> 00:42:35.520 Andy Whiteside: Maybe it deserves to be i'm. 348 00:42:36.570 --> 00:42:39.240 Andy Whiteside: Harvey give me your best attempt to explain why this matters. 349 00:42:41.130 --> 00:42:42.420 Harvey Green: A best. 350 00:42:44.700 --> 00:42:45.000 Andy Whiteside: topic. 351 00:42:48.210 --> 00:43:05.340 Harvey Green: So um, I think, and I guess Jerry you correct me if i'm wrong here, I think this is necessary because we've got a lot of things that are moving to prison prison centrally managed instead of. 352 00:43:06.360 --> 00:43:12.210 Harvey Green: Prison element direct on the node, and this is just helping move into that direction, a little easier. 353 00:43:12.630 --> 00:43:21.240 Jirah Cox: yeah I got a convenience enhancement right like bring bring more of the functionality into into the browser tab you're already logged into. 354 00:43:21.570 --> 00:43:21.930 yeah. 355 00:43:25.050 --> 00:43:30.180 Andy Whiteside: Alright, enhance maintenance mode how much can we enhance the maintenance. 356 00:43:31.980 --> 00:43:37.830 Jirah Cox: So another one that historically has been kind of a seelye operation now it's in the in the gooey there. 357 00:43:39.600 --> 00:43:50.190 Jirah Cox: That but also bring some new tricks to it that, when you say I need to you know change out and more memory to these nodes because we tried overcome it and we want to go back to. 358 00:43:50.910 --> 00:43:58.350 Jirah Cox: adding more memory, to the nodes then when I take that data into maintenance mode and then take it down and add dims to it and then bring it back up. 359 00:43:58.650 --> 00:44:11.280 Jirah Cox: It also remembers wireless vm lived and then moves those Games back onto the note that they belong on to or belong in air quotes there to restore data locality right, so that we don't have to chase them around within the cluster to re localize more data. 360 00:44:12.900 --> 00:44:19.080 Andy Whiteside: And just another example of intelligence in efficiencies through you know, continue to evolve, the software. 361 00:44:22.170 --> 00:44:24.930 Andy Whiteside: and explain enhancements. 362 00:44:26.250 --> 00:44:30.930 Jirah Cox: So X played not not a household name just yet really deserves to be. 363 00:44:32.190 --> 00:44:43.380 Jirah Cox: Our low code no code automation done right within prison central So what if you want to change together a bunch of actions like at you know, on Friday at 10pm take this vm down. 364 00:44:44.490 --> 00:44:53.040 Jirah Cox: Add maybe grow the hard drive or add some memory to that virtual machine power backup send me a team has message or slack message, or maybe a whatsapp if you want to. 365 00:44:54.090 --> 00:44:55.140 Jirah Cox: Call some APIs there. 366 00:44:56.580 --> 00:45:03.810 Jirah Cox: Let me know that you did it right or your email the application owner to say i've completed your change request for your virtual machine a crowd request, if you will. 367 00:45:05.190 --> 00:45:17.340 Jirah Cox: that's all existed natively within within prison central so we're making that functionality smarter here with new things that it can do so, adding here some look up actions, where we can look up this as a cluster a host or a virtual machine. 368 00:45:18.540 --> 00:45:32.280 Jirah Cox: So if you, you know that that provides all kinds of accessibility for like if you had a random IP address you can now call a playbook to say look up this IP address find the matching virtual machine and then sending back the vm name or convert it somehow. 369 00:45:33.480 --> 00:45:40.770 Jirah Cox: But then also more fun send those alerts like I said slack teams, you know if you know the whatsapp API you could probably code that yourself. 370 00:45:41.490 --> 00:45:56.880 Jirah Cox: Now natively send a pager duty right so for your OPS teams, you know that want to get alerts perhaps that match a certain level of severity right if it's if it's the the red klaxon alert that I want to get that on my phone by a pager duty that's a native integration now. 371 00:45:59.280 --> 00:46:01.260 Andy Whiteside: You guys in tell me we're going to talk about automation. 372 00:46:03.570 --> 00:46:04.500 Jirah Cox: trigger warning Randy. 373 00:46:04.830 --> 00:46:12.840 Harvey Green: I was gonna bring that up for first you allow them to overcommit memory now you give them an automated tasks to shut a machine down and just add memory. 374 00:46:13.440 --> 00:46:21.720 Jirah Cox: Well, the way I the way I describe it to admins is like if it's a vm that that that you do something on add add cpu memory, whatever add a new desk. 375 00:46:23.070 --> 00:46:32.790 Jirah Cox: And you only do it during a maintenance window and it's only Fridays at 10 well, you could you could simply be awake Friday at 10 on the laptop on the vpn and make the change. 376 00:46:33.240 --> 00:46:38.340 Jirah Cox: Or, I would rather you know do that Thursday morning, you know nine in the morning program all the changes. 377 00:46:38.760 --> 00:46:51.000 Jirah Cox: use a repeatable run book for that, instead of trigger based on time to say hey at 10pm when you automated system are awake you go do this for me and just email me if there's any problems with it, otherwise you know don't bug me. 378 00:46:54.180 --> 00:46:58.500 Andy Whiteside: yeah you guys like if I was still running the world you'd have to like crank the thing on the front of Carter started. 379 00:47:02.910 --> 00:47:05.790 Andy Whiteside: Imagine how much bonding between husband and wife that created. 380 00:47:08.040 --> 00:47:09.870 Harvey Green: Oh, my gosh i'd rather not. 381 00:47:11.790 --> 00:47:14.700 Andy Whiteside: No i'm just kidding i've gotten used to punch in the button. 382 00:47:16.710 --> 00:47:23.370 Andy Whiteside: Well, like always it's pretty simple to go kick the tires with this thing called test drive I assume it's reading. 383 00:47:23.790 --> 00:47:33.840 Andy Whiteside: Well they're just says right there and test drive today so everything we've talked about here can be played with in a matter of moments just by going out to the new tactics test drive site. 384 00:47:34.530 --> 00:47:39.300 Jirah Cox: yeah I think it's I think it's super exciting it's you know mix of major and and. 385 00:47:40.590 --> 00:47:49.110 Jirah Cox: You know more visible and less visible enhancements right kind of a mixed bag they're very well rounded but you know throughout it all the key is. 386 00:47:49.590 --> 00:48:00.570 Jirah Cox: Just software that makes your structure get better over time right so it'd be like your engine X cluster does more for you tomorrow than it did yesterday and runs better runs faster over time, I think that's the coolest thing over. 387 00:48:01.620 --> 00:48:07.620 Andy Whiteside: Well, and for people that have been around me lately i'm constantly talking about digital transformation what phase you're in because it's never ending. 388 00:48:07.830 --> 00:48:13.350 Andy Whiteside: And because integrity integrity we're always talking about digital workspace fronting that digital transformation. 389 00:48:13.620 --> 00:48:24.360 Andy Whiteside: To I was doing that to you and Harvey jumped on a while ago I showing you our workspace right you've got this amazing digital transformation thing have any new tactics, I would argue that your digital workspace that front ends it isn't. 390 00:48:25.410 --> 00:48:34.680 Andy Whiteside: I mean, maybe you have another one one I didn't see but the one that I saw was very lacking in terms of all the things that that can be leveraged for to go along with that digital transformation. 391 00:48:35.790 --> 00:48:37.380 Jirah Cox: We don't we don't have different was banks don't we. 392 00:48:38.430 --> 00:48:38.700 Jirah Cox: yeah. 393 00:48:39.960 --> 00:48:42.900 Harvey Green: So so Jerry you did all this in a weekend you. 394 00:48:43.530 --> 00:48:45.960 Harvey Green: have yourself a raise that looks like a fancy charity oh. 395 00:48:45.960 --> 00:48:47.850 Jirah Cox: Thanks, but we had a long weekend. 396 00:48:52.710 --> 00:49:00.930 Andy Whiteside: Alright guys well we're out of time i've got another podcast to do, but I appreciate you guys joining and we'll get this posted in the next 48 hours. 397 00:49:02.010 --> 00:49:02.790 Harvey Green: sounds good. 398 00:49:02.910 --> 00:49:03.780 Jirah Cox: cool talk to. 399 00:49:04.470 --> 00:49:04.650 me.