XenTegra - Nutanix Weekly

Nutanix Weekly: Convert Your Cluster to AHV and Configure Leap for Disaster Recovery

July 13, 2022 XenTegra / Andy Whiteside Season 1 Episode 55
XenTegra - Nutanix Weekly
Nutanix Weekly: Convert Your Cluster to AHV and Configure Leap for Disaster Recovery
Show Notes Transcript

On my previous blog (Link) I showed you how to build a metro availability. Now I want to "upgrade" both clusters to AHV and enable data protection with the help of Leap to achieve an RPO of zero (0).

This blog post are two posts combined. First is the in-place conversion of ESX to AHV and the second is how to enable and configure Leap.

Host: Harvey Green
Co-host: Jirah Cox
Co-host: Ben Rogers

WEBVTT

1
00:00:03.510 --> 00:00:12.780
Harvey Green: Alright, welcome everyone to episode 55 of new talents weekly podcast I have with me today, Mr Jared Cox jar how are you.

2
00:00:13.290 --> 00:00:14.910
Jirah Cox: Doing woman pay doing happy Monday.

3
00:00:15.780 --> 00:00:20.550
Harvey Green: Yes, yes, happy Monday, indeed, and Mr Ben Rogers.

4
00:00:21.630 --> 00:00:28.620
Ben Rogers: How are you i'm doing fine glad to have you on the podcast Harvey I missed your my first one, but let's see the journal, my second.

5
00:00:31.170 --> 00:00:37.350
Harvey Green: yeah um yes, I meant to be on the first one, but it just did not have.

6
00:00:38.610 --> 00:00:48.210
Harvey Green: And so you know, last week I was on vacation I come back today and jumping back into the podcast i'm like all right, who are you again, and what are we talking about.

7
00:00:48.540 --> 00:00:50.160
Jirah Cox: When I work what's my job.

8
00:00:50.550 --> 00:00:50.880
Jirah Cox: yeah.

9
00:00:51.210 --> 00:00:52.110
Jirah Cox: Was it a good vacation.

10
00:00:52.470 --> 00:00:58.860
Harvey Green: It was it was actually a good mental vacation that I needed more than, then I thought I did.

11
00:00:59.490 --> 00:01:02.370
Jirah Cox: The more the better indication, the more forgetful I am when I come back.

12
00:01:02.430 --> 00:01:04.110
Harvey Green: Yes, yes, so.

13
00:01:05.550 --> 00:01:08.430
Harvey Green: i've been plowing through that all day today.

14
00:01:11.700 --> 00:01:18.030
Harvey Green: So yeah but good good to be back glad to jump on with you guys and do this.

15
00:01:19.950 --> 00:01:34.860
Harvey Green: Talking through today converting your cluster to HIV and configuring leap for disaster recovery so just just in the title of there i'll let you start being since she's a newcomer we're gonna we're gonna ask the F and G.

16
00:01:38.850 --> 00:01:40.440
Harvey Green: What is HIV.

17
00:01:41.310 --> 00:01:42.690
Harvey Green: Oh, what is leap.

18
00:01:43.860 --> 00:01:53.850
Ben Rogers: HIV is the new tannic hypervisor so new tonics has their own hypervisor that we run on our platform that can be replacements for other advisors I vmware.

19
00:01:54.060 --> 00:02:07.320
Ben Rogers: sin server coming from our citrix days leap I believe it's not called leap anymore it's called something else, but I could be making a new guy mistake here, to be honest, but that's our backup and data protection products.

20
00:02:08.610 --> 00:02:25.980
Ben Rogers: that's that's a whole slew of protection tools that we have it can be replication backup basically your hands often attacks goodness of you know how we store data in our clusters So hopefully That was a good F and G answer Jerry jump in and say.

21
00:02:27.090 --> 00:02:32.700
Jirah Cox: No 100% and until the true about we are yet totally going through kind of a top to bottom rebranding.

22
00:02:34.050 --> 00:02:45.360
Jirah Cox: But yeah the native the native data protection replication recovery orchestration all all still that we all know and love that yeah it was definitely formerly brand is leap.

23
00:02:46.710 --> 00:02:55.320
Jirah Cox: This article I love, seeing that pop up on the on the blog this one again comes from that the tedx Community forum right next next.

24
00:02:56.130 --> 00:03:07.500
Jirah Cox: Next anything's dot com this one is a second blog from Jerome who did the previous one, that we covered referring to the the at that time the ESRI metro setup, so this is.

25
00:03:08.070 --> 00:03:16.380
Jirah Cox: He actually kill him like a whole bunch of birds with one stone here with one blog post so multifaceted converting from V sphere to HIV.

26
00:03:17.670 --> 00:03:29.160
Jirah Cox: Setting up the synchronous REP the rp oh zero on HP HP so again, you know that I, my vm won't write data until the second site has acknowledged that I have that data off site already.

27
00:03:30.270 --> 00:03:33.570
Jirah Cox: And then, lastly, at the end we'll get to this, he has a really clever script.

28
00:03:34.020 --> 00:03:41.970
Jirah Cox: That, then, can also help with automatically tagging and categorizing virtual machines in the environment, which is part of the the construct for managing.

29
00:03:42.300 --> 00:03:51.480
Jirah Cox: Data Protection right is moving from like a folder based structure to tag based structure, so we can we'll walk through all this it's a great article yeah.

30
00:03:52.020 --> 00:04:00.810
Harvey Green: that's perfect I was just bringing it up as you were talking through that and yeah I mean that totally looks logical yeah I just I read it, that fast.

31
00:04:01.260 --> 00:04:01.590
man.

32
00:04:03.840 --> 00:04:17.310
Jirah Cox: And so, so this was Jerome doing this in his lab where of course rebuilding would be a perfectly valid strategy it's just a lab, but I think is so neat that he also does show the real world use case of converting a cluster from one hypervisor to the other.

33
00:04:18.330 --> 00:04:22.230
Jirah Cox: With very minimal vm downtime and, of course, no data loss so.

34
00:04:24.060 --> 00:04:29.580
Jirah Cox: So we can get going, so he calls out before the conversion right, and this is, of course, is all in the documentation.

35
00:04:29.970 --> 00:04:36.300
Jirah Cox: Some of the pre racks right around what do we need the cluster to do to prepare to be converted at the hypervisor level there.

36
00:04:36.900 --> 00:04:50.460
Jirah Cox: So first will be n g to the new tannic guest tools that goes into each vm and really the key portion of that is that it also does some driver injection right, so that it can talk to the new storage controller get to all of its all the V disks those beams are going to one.

37
00:04:51.960 --> 00:05:01.410
Jirah Cox: Each host of course each hypervisor instance needs to have a Nick uplink team, so not just one port, please you know to nick's preferred.

38
00:05:02.670 --> 00:05:12.630
Jirah Cox: Li CP Lib bouncing disabled just to make sure that the networking will come back up in a simplified manner, it can get re enabled later on, but for the conversion workflow.

39
00:05:13.830 --> 00:05:20.400
Jirah Cox: LCP disabled at the time he drs should be enabled at the at the V Center cluster level.

40
00:05:21.060 --> 00:05:31.140
Jirah Cox: And then of course we're going to pause Dr activities because we're going to be turning on turning off the cluster itself will be stopping starting at the per node level so Dr activities or application will get paused.

41
00:05:32.790 --> 00:05:41.910
Jirah Cox: As part of this, he hit something here first drones first screenshot is in the i've hit in our lab is plenty where the conversion was will.

42
00:05:42.630 --> 00:05:54.090
Jirah Cox: 30 a quick little error if every every host V switch configuration is not identical and homogenous so he has one example where he has one host that has like four nick's but he's using two of them.

43
00:05:54.660 --> 00:06:09.930
Jirah Cox: and saying hey this host using for next, but only have two of them live doesn't match, you know host to, for example, that only has to nicks and they're both live so make those all match take those that take those uplinks out of the V switch as a quick fix their to prep for that conversion.

44
00:06:12.540 --> 00:06:21.360
Jirah Cox: Yes, so then actually goes into to disable mission control disabling admission control is important because we're probably going to violate your admission control.

45
00:06:22.110 --> 00:06:29.760
Jirah Cox: thresholds right and mission control says, if I have four hosts don't let me power on more than, say three hosts worth of resources by default.

46
00:06:31.380 --> 00:06:33.630
Jirah Cox: or N minus one levels of.

47
00:06:34.050 --> 00:06:49.740
Jirah Cox: resources so that I can't you know get too tight if I then have a host failure well we're actually cause a host failure as part of this process right were to take one host out of the pool and have one host less resources one hosts fewer resources so disable your AC there by design.

48
00:06:50.760 --> 00:06:56.550
Jirah Cox: And then, since this is your own doing in his lab the lab that he used to set up metro availability he's gonna go ahead and.

49
00:06:57.270 --> 00:07:06.660
Jirah Cox: roll back and disable the metro configurations I delete the opposite data stores after he's made sure that all the machines are running at the right side of that metro pairing.

50
00:07:07.680 --> 00:07:19.740
Jirah Cox: So with those projects in place and all knocked out he can get started, which is you know, like so many things on newt annex it's about one click so he just goes into prism picks the cluster and just go to settings convert cluster.

51
00:07:20.370 --> 00:07:25.620
Jirah Cox: That kicks off a whole bunch of validation checks pre flight inspections.

52
00:07:26.790 --> 00:07:31.020
Jirah Cox: there's even a great link here to what does that validation doing that users can click on and explore.

53
00:07:32.790 --> 00:07:40.410
Jirah Cox: But basically, when it when it's done all of its preflight checks it's going to tell you hey we're ready to go here do you want to proceed you're going to probably pick yes, if you want to proceed.

54
00:07:41.730 --> 00:07:42.960
Jirah Cox: Then you can get kind of a.

55
00:07:43.650 --> 00:07:47.670
Jirah Cox: We used to use this a lot for all of our upgrade ui is kind of this like multiple.

56
00:07:48.990 --> 00:07:52.740
Jirah Cox: Progress bars and then one kind of leads the Pack and the rest kind of follow it.

57
00:07:53.160 --> 00:08:08.820
Jirah Cox: So the at the nuts and bolts level what this conversions going to do is it'll change one hypervisor one host right or we say one node at a time to the new hypervisor so it'll pick some host let's say it picks hosts three to start with it before host cluster.

58
00:08:10.350 --> 00:08:22.020
Jirah Cox: reboot that one re install or install a new hypervisor in this case HIV and then you know do all things that need to do to become anything X note again so bring up icbm.

59
00:08:23.310 --> 00:08:34.470
Jirah Cox: confirm all the storage is still there, all the V disks are still there and then roll on to the next host so the the nodes get reimbursed to the hypervisor one one note at a time.

60
00:08:37.770 --> 00:08:39.240
Harvey Green: All right, then.

61
00:08:41.070 --> 00:08:47.490
Harvey Green: carousel a lot, I just want to make sure that you don't want to anything that he left that out.

62
00:08:49.950 --> 00:08:52.920
Ben Rogers: i'm going into former customer mode here instead.

63
00:08:52.920 --> 00:08:53.580
Harvey Green: Of ego.

64
00:08:54.060 --> 00:08:59.820
Ben Rogers: Instead of new tannic some employee, so I do have a few questions on this, and these would be things that.

65
00:09:00.240 --> 00:09:09.090
Ben Rogers: Your customers might ask Okay, so when these these hosts are coming down and they're being re brought up and they're being converted to hd host.

66
00:09:09.600 --> 00:09:28.650
Ben Rogers: The vm that are running on this, I assume they're being V motion off on down to tell me about that process what's happening to the bm as this process is taking place and at what point is the vm being moved from sx over to to hv.

67
00:09:29.850 --> 00:09:34.080
Jirah Cox: The the I should make sure, nothing has changed since I last.

68
00:09:34.770 --> 00:09:47.940
Jirah Cox: did this in the lab I think they're powered off because they have to be right they're gonna change hypervisor there's no real way to do that online so there's a little bit of impact so each virtual machine this whole operation goes into the giant you know maintenance window umbrella.

69
00:09:49.260 --> 00:09:55.530
Jirah Cox: So not not a non disruptive operation to individual virtual machines right, although the data, of course, is 100% safe.

70
00:09:57.030 --> 00:10:01.500
Jirah Cox: So isn't there powered off they're actually probably not live migrating right and it converts all the hypervisor.

71
00:10:01.920 --> 00:10:12.450
Jirah Cox: While the vm is powered off and then at the end it flips all the vm from being vs vs over to https and then renounce all of their storage which isn't really fundamentally touched during the process.

72
00:10:14.790 --> 00:10:19.830
Ben Rogers: what's the what's the what's the vm or being powered up and being converted over from.

73
00:10:20.400 --> 00:10:34.890
Ben Rogers: V sphere vm to hv and what's the time frame look like on that now, I know performance power of the environment is going to have a play, but statistically what could a customer think of how long that process will take they were dealing with a three node environment.

74
00:10:35.190 --> 00:10:36.330
Jirah Cox: Total yeah that's great question.

75
00:10:37.410 --> 00:10:49.590
Jirah Cox: and actually like that gentleman called out he put a stopwatch on one of his his first host took 30 minutes, which is pretty reasonable for an automated hypervisor installation and then all of the post install steps right which he actually even goes.

76
00:10:50.850 --> 00:10:57.960
Jirah Cox: To the detail of itemizing like rebooting it in the installer after that's done running the cgm installer.

77
00:10:59.640 --> 00:11:05.910
Jirah Cox: And then, a couple more subsequent reboots after that so it's about a 30 minute process per know that sounds about about right to my mind.

78
00:11:07.080 --> 00:11:14.670
Jirah Cox: So then, so that that will what people should be hearing, there is, it does take longer on larger clusters less time on smaller clusters it's a scale out operation.

79
00:11:16.950 --> 00:11:26.460
Ben Rogers: I think I think a lot of customers are going to be looking at this with the with the changes are coming down with the vmware I mean this could be definitely be something that.

80
00:11:26.790 --> 00:11:31.740
Ben Rogers: we're talking to a lot of customers about it, we have we've had a few that have kind of started the process.

81
00:11:32.070 --> 00:11:40.890
Ben Rogers: But I imagine, in the future, this is going to be a story that we're going to have to learn to tell, and you know, probably in a couple of situations walk through the customers doing this.

82
00:11:42.750 --> 00:11:44.820
Jirah Cox: Totally I still remember one of my first.

83
00:11:45.840 --> 00:11:53.250
Jirah Cox: PCs any techniques that I ran this is going back almost five years it actually you know this was a key criteria of.

84
00:11:54.000 --> 00:12:06.600
Jirah Cox: Of the proof of concept was if we deploy with one hypervisor can we, you know how painful, is it how quick, is it to change after the fact, to another another another choice so yeah for sure I think it'll only only get busier and busier doing that.

85
00:12:08.970 --> 00:12:14.220
Harvey Green: yeah I agree that was a kind of similar for me, I had a customer who.

86
00:12:15.240 --> 00:12:16.980
Harvey Green: When I was first getting started.

87
00:12:18.390 --> 00:12:30.120
Harvey Green: This was one of their requirements like that that it could just swap from one hypervisor to the other, and I when they told me and they said it, I looked at the guy like you wanted to do what.

88
00:12:33.240 --> 00:12:39.450
Harvey Green: And I was like you know what i'll humor this i'll go look, and I was like oh wow it can actually do this.

89
00:12:40.770 --> 00:12:54.450
Harvey Green: And here we are, you know years down the line, later, and you know we're still talking about it still telling the story to ben's point but this this will definitely be something that is that we see a lot more.

90
00:12:55.560 --> 00:12:56.280
Harvey Green: Coming up.

91
00:12:58.230 --> 00:13:03.240
Jirah Cox: Like you know and for those customers worth calling out here, one more consideration that drone touches on here.

92
00:13:04.440 --> 00:13:06.930
Jirah Cox: We need the Center running somewhere other than this cluster.

93
00:13:07.230 --> 00:13:21.510
Jirah Cox: For this process to work, because we need to make the Center host automation calls to visa V centers, we need to turned on and powered on through the entire process, so if necessary migrate that somewhere else other than the cluster that we're going to be migrating so pro tip there.

94
00:13:22.590 --> 00:13:40.350
Harvey Green: yeah and and agreed 100% and I know that there will be people who say well why, why does it have to be that way well, you need the Center of the whole time in order to make things work and if the cluster is converted, but the sun is still there it's not really the Center anymore is.

95
00:13:41.340 --> 00:13:41.760
Jirah Cox: Right.

96
00:13:41.790 --> 00:13:43.800
Jirah Cox: For sure your cluster managers.

97
00:13:43.830 --> 00:13:48.480
Jirah Cox: Then yeah we're, it is a it is going to be that the maytag man right not not to do.

98
00:13:49.590 --> 00:14:00.840
Ben Rogers: I do, I have a question about that you know we go, you were talking about that the system will go through his checks and balances I assume that's one of the checks that it makes that the V Center is not running on the cluster you're covered.

99
00:14:02.370 --> 00:14:14.520
Jirah Cox: The great question and one that I don't have the answer to I can I can picture it both ways I could get fancy with like scripting and me like hey what's my view Center IP address do I see that IP address on one of my uplinks is one of the vm that i'm hosting here.

100
00:14:16.620 --> 00:14:18.750
Jirah Cox: But I can probably think of edge cases where that.

101
00:14:19.020 --> 00:14:20.100
Jirah Cox: Detection logical probably.

102
00:14:20.280 --> 00:14:22.020
Jirah Cox: not apply or get missed.

103
00:14:22.140 --> 00:14:26.850
Jirah Cox: yeah that's probably good on the verify the human level of the Center not on the cluster we're going to convert.

104
00:14:27.030 --> 00:14:42.990
Harvey Green: yeah I would say the same, I I see too many holes and having it and it's funny right i'm saying this right now and i'm I just described doing this before i'm like you wanted to do what but it probably does do it, and I just don't know.

105
00:14:46.110 --> 00:14:49.200
Harvey Green: So no that's that's a great question.

106
00:14:51.060 --> 00:14:55.620
Jirah Cox: So um as our clusters convert here and finish that process in.

107
00:14:56.100 --> 00:15:06.330
Jirah Cox: In drones lab so he walks through the process to recreate the metro containers, so the storage containers that go from A to B and then from be back to a because, again in his lab he's going to.

108
00:15:06.630 --> 00:15:14.760
Jirah Cox: simulate running live workloads at both of these two sites at same time and either site can can protect the other after a failure or and recover the workloads.

109
00:15:16.170 --> 00:15:19.380
Jirah Cox: So he's renamed recreated those metro storage containers there.

110
00:15:21.270 --> 00:15:32.580
Jirah Cox: For application last season going to prison central and then now from here on out the rest, the process basically involves recreating the data protection and the otter recovery functionality.

111
00:15:33.240 --> 00:15:42.960
Jirah Cox: For the vm protection right so at this point hypervisor conversions all done in his lab we can extrapolate 30 minutes and say it took about probably two hours to run through for a four node cluster.

112
00:15:44.160 --> 00:15:52.500
Jirah Cox: So then he goes back into prison central and whether that's one PC managing two clusters or or one person central managing each of its own availability zone.

113
00:15:53.790 --> 00:15:59.430
Jirah Cox: Either way, so he enables leap right or the artist formerly known as leap for vm replication.

114
00:16:01.080 --> 00:16:11.700
Jirah Cox: it's primarily powered by categories, so when I categorize a vm and a vm can have multiple categories right like it can be tagged for production windows.

115
00:16:12.210 --> 00:16:25.050
Jirah Cox: er P, and in those three tags and describing you know the os it prod Dev test stance or validation as well as the application that's running and I can I can tag it multiple ways.

116
00:16:27.180 --> 00:16:30.780
Jirah Cox: As well as also then tie my data protection to all those tags.

117
00:16:32.100 --> 00:16:41.550
Jirah Cox: So we'll get into to how do you tag your vm because if you just did this process fresh you probably have potentially no tags if you've been doing visa V centers centric management.

118
00:16:41.850 --> 00:16:50.820
Jirah Cox: or anything switch over to hb well, then you have no tags, we should fix that for you so drone walk through a very clever way to do that here at the end of the blog post but.

119
00:16:52.710 --> 00:16:53.100
Jirah Cox: So.

120
00:16:54.300 --> 00:17:02.550
Jirah Cox: So he goes through, and creates tags that he then ties with his protection policies to match that you know vm that are running over at site a.

121
00:17:02.970 --> 00:17:15.630
Jirah Cox: Major replicate over to site B and vice versa vm that site be replicated over to cite a again doing a synchronous replication so rpm zero so all data is acknowledged and stored at both sites before we acknowledge it back to the virtual machine.

122
00:17:20.550 --> 00:17:28.380
Jirah Cox: A lot of us we've covered on previous blog posts but, again, this is, this is actually pretty standard you can't sleep configuration right so production policies replicate the data.

123
00:17:29.760 --> 00:17:35.790
Jirah Cox: And then the recovery plans are what describe how I want to bring my views back online, so this is where.

124
00:17:36.360 --> 00:17:42.690
Jirah Cox: For for metro right we're going to always want to use stretch layer to networking right, we have to have the vm be able to recover.

125
00:17:43.680 --> 00:17:54.240
Jirah Cox: without needing a VIP action right, so it was a single via single IP address over it's like a same IP address over at site B if you're going longer distance and if you're if you're not doing.

126
00:17:55.290 --> 00:18:09.270
Jirah Cox: synchronous replication then of course you also get into things like re IP addresses are moving in the network to follow the virtual machine, but for this use case of the rp a zero you probably want automatic fail over so he talks about how to set up the threshold there for.

127
00:18:10.500 --> 00:18:17.910
Jirah Cox: connectivity as well, he wants in his words you know automatic fail over of the particular vm from cluster one to cluster to after 30 seconds of.

128
00:18:18.930 --> 00:18:21.180
Jirah Cox: Being disconnected so it's going to monitor for.

129
00:18:22.500 --> 00:18:36.150
Jirah Cox: The status and then, if it doesn't if it loses its its pure site it'll automatically recover those workloads That gives you that outcome of you know, work recovering my vm at three in the morning, with no humans involved type of availability for the business.

130
00:18:38.070 --> 00:18:45.120
Jirah Cox: Coming on down here, he talks about how to configure the power on sequencing so you can actually have that set to you know hey it's 100 vm pair of them all at once.

131
00:18:45.480 --> 00:18:55.080
Jirah Cox: or these five first these 15 after that, and then the remaining 80 after that, so you can define your phases and startup orders in either.

132
00:18:55.560 --> 00:19:07.410
Jirah Cox: In either you know handpick list of like this vm that vm or again reuse those categories right so add a tag at a category for power on first after a Dr event power on second or.

133
00:19:08.070 --> 00:19:20.100
Jirah Cox: You know tag him, of course, we're all thinking of like domain controllers load balancers hey you know delivery controllers and Netscape lawyers right so critical stuff up first less critical stuff or dependent stuff comes up second.

134
00:19:21.690 --> 00:19:31.170
Jirah Cox: And, of course, he calls out here, another neat thing that if you're if you are using that stretch layer to networking, then you can do live migrations which is pretty pretty neat so, then you can actually live migrate vm from one side to the other.

135
00:19:31.410 --> 00:19:34.170
Jirah Cox: Because again the storage is are already replicated and staying in sync.

136
00:19:36.840 --> 00:19:49.410
Jirah Cox: You can define your test networks, so we always ask you to define if if you can do for networks, so if you have site a insight be you really want to have site a test site B test, as well as like a prod site be prod.

137
00:19:50.550 --> 00:19:58.380
Jirah Cox: Some people think about Dr they think I need three networks right prod Dr and test and our view of the world is probably that you need for networks, because if you fail over.

138
00:19:58.860 --> 00:20:07.830
Jirah Cox: We need to be able to have a test that goes back the other way back to where you came from so you'd want, even if you fail over the site be you probably won't have a site a test and a site a prod network.

139
00:20:10.260 --> 00:20:13.230
Jirah Cox: So for networks for that and then he shows.

140
00:20:14.370 --> 00:20:26.040
Jirah Cox: You know that has a he showed he shows in his blog post the the button so click on the walkthrough for performing live migration from cluster in his case cluster one the cluster to no downside, no downtime the vm no.

141
00:20:27.360 --> 00:20:28.590
Jirah Cox: No lost connectivity there.

142
00:20:30.090 --> 00:20:33.660
Jirah Cox: And then i'm not going to read you the scripts because it's long but as.

143
00:20:33.900 --> 00:20:34.710
Jirah Cox: you're seeing.

144
00:20:35.580 --> 00:20:37.470
Jirah Cox: harvey's disappointed i'm going to read a script well I.

145
00:20:37.860 --> 00:20:38.880
Jirah Cox: guess but.

146
00:20:40.470 --> 00:20:47.580
Jirah Cox: So this is really cool, so this is we've talked about this before a little bit playbooks right which is there was in prison central they're sort of like.

147
00:20:48.540 --> 00:20:57.720
Jirah Cox: If you've never automated anything before in your life, this is how you get started right so it's code this automation it's click and drag it's if this then that.

148
00:20:58.170 --> 00:21:10.380
Jirah Cox: chaining some events for like you know wait until Friday at 10pm then shut down this vm then take a snapshot then grow the V disk and then power back on and send me an email that it was all done or a slack or teams message.

149
00:21:10.830 --> 00:21:14.190
Jirah Cox: That kind of automation that you can just click and drag and do it all with your keyboard and mouse.

150
00:21:15.360 --> 00:21:20.310
Jirah Cox: So this is a way to take that framework of using a playbook within prison central.

151
00:21:21.390 --> 00:21:29.430
Jirah Cox: With this script here that he's he's provided his blog post to basically read vm names, so if you're if you have a good, healthy vm nomenclature.

152
00:21:30.900 --> 00:21:37.770
Jirah Cox: Around naming them like if you have P in there, and you have a site name and you have an APP name.

153
00:21:38.160 --> 00:21:50.880
Jirah Cox: Then it can read all that and, of course, just apply like red X to scrape out all those values and then tag it appropriately so it's great way to be able to in one shot create a bunch of useful tags and categories, on your vm on your clusters.

154
00:21:52.260 --> 00:21:59.580
Jirah Cox: You know, when you have nothing you actually can even have this run on even on new vm creation, so this is this can be more than just a one time script.

155
00:21:59.940 --> 00:22:14.640
Jirah Cox: You guys, you can have this run as kind of a hey once per hour check for newly created vm and if they haven't been categorized then apply these logical categories to them, so he was helpful day two operations there to connect keep good hygiene going within your environment so.

156
00:22:16.590 --> 00:22:26.610
Jirah Cox: So overall I think it's pretty fantastic it's a great blog post, if you want to see what the you know the ones that we can't do a podcast right and show you like what the user interface looks like for well for anything right.

157
00:22:27.180 --> 00:22:39.060
Jirah Cox: We can describe it to you with very pretty words, but if you want to see what this process looks like for how to convert a cluster from one provider to another, this is what the interface looks like a new tannic and how quickly you can do it.

158
00:22:41.760 --> 00:22:44.820
Harvey Green: Absolutely, thank you for that for sure.

159
00:22:45.960 --> 00:22:49.170
Harvey Green: Mr Rogers any Mr Rogers.

160
00:22:52.260 --> 00:22:59.520
Ben Rogers: i'm still you know me I got a customer hat on this one for sure So the first thing i'm thinking of is how many products, what I.

161
00:22:59.970 --> 00:23:16.530
Ben Rogers: have had to have had to do this in the past, so, for me it would be vmware zero to you know the Dell back in our emc back in time that I was buying so now what i'm seeing is in one platform one foundation product.

162
00:23:17.610 --> 00:23:24.930
Ben Rogers: With all with all this goodness, I can buy the the clusters, I can manage the clusters with with prison central.

163
00:23:25.170 --> 00:23:30.480
Ben Rogers: I then can go, you know purchase the leak features and that goes on top of it, but just how all of this.

164
00:23:30.660 --> 00:23:39.600
Ben Rogers: Will you know, bring my product set down instead of all these different products from having to use and piece together, I now can do all this under one umbrella.

165
00:23:39.930 --> 00:23:49.140
Ben Rogers: and assume that I can call one support numbering a hey i'm having problems with this and i'll be able to get help and that helped one though the product from India in.

166
00:23:50.070 --> 00:23:54.300
Ben Rogers: I said something like this up Similarly, when I was seeing a say.

167
00:23:54.720 --> 00:24:05.580
Ben Rogers: But I was using other products, and there were times that I would have to call specific vendors that didn't have knowledge of the underlying infrastructure in that made the conversations very.

168
00:24:05.940 --> 00:24:11.880
Ben Rogers: difficult because you gotta trust this I mean people don't put this in and hope that it works, you know.

169
00:24:12.420 --> 00:24:19.470
Ben Rogers: they're going to be testing this they're going to be doing, you know I love the idea of doing the playbooks that was not something that wasn't at my fingertips at the time.

170
00:24:19.740 --> 00:24:30.570
Ben Rogers: i've been in the prison program and seeing the low code no code is awesome for people that don't have any coding experience to get some automation happening so for me as a customer i'm going wow.

171
00:24:30.990 --> 00:24:39.540
Ben Rogers: I can you know there's risk of vmware now I now have a way of getting you know away from vmware on HP which i'm already paying for five.

172
00:24:39.750 --> 00:24:49.410
Ben Rogers: New tenants clusters, some people say that it's free it's not free it's built into the system and built into the price, you know let's be honest with our customers, but then coming back with leap.

173
00:24:50.220 --> 00:24:57.840
Ben Rogers: or data protection services or whatever the name is the formula artist named we're talking about to be able to create this kind of replication.

174
00:24:58.320 --> 00:25:15.270
Ben Rogers: and ability to go between two clusters I data centers is really made a compelling compelling story, and one that if I was a customer buying technology that I would definitely be looking at this and looking at the numbers of what this cost versus other solutions that are.

175
00:25:16.830 --> 00:25:21.420
Jirah Cox: Well, and think about I think it's so interesting bends a great point to think about like upcoming changes.

176
00:25:21.780 --> 00:25:31.140
Jirah Cox: And it's like what what kind of upcoming changes can this kind of system tolerate once it's set up that are really not events right if i've got four nodes and four nodes that each site, so it ain't no its total.

177
00:25:31.560 --> 00:25:39.120
Jirah Cox: And I grow yeah my business is growing I grow to eight nodes per site 1616 total that's a non event to this configuration right.

178
00:25:40.110 --> 00:25:48.720
Jirah Cox: You know I move some workloads to the cloud I shrink down to six and six that's a non event to this configuration right clusters grow cluster shrink that's all dynamic on our side.

179
00:25:50.310 --> 00:25:56.160
Jirah Cox: The upgrades on both sides right full full stack management from everything from like Nick firmware and bios.

180
00:25:56.550 --> 00:26:04.770
Jirah Cox: Up to hypervisor storage and this application Management Code and operations and the automation for the fail over all managed right through lcs.

181
00:26:05.250 --> 00:26:12.330
Jirah Cox: For my upgrades as well as like hey we hit five years the hardware dedicated I need to you know move on to a new solution.

182
00:26:12.660 --> 00:26:16.800
Jirah Cox: Maybe we want to change from something like super micro or Dell onto like an HP platform.

183
00:26:17.250 --> 00:26:22.740
Jirah Cox: Again, a non impactful change to this configuration right keeps on running the entire time as we.

184
00:26:23.160 --> 00:26:31.020
Jirah Cox: change all the tires on the bus as we drive down the highway right or, to use an analogy, so the the freedom and flexibility of what you can do.

185
00:26:31.830 --> 00:26:39.510
Jirah Cox: Because it becomes part of your private cloud without having to re engineer, the solution right or every five years, if you were on any other platform if you're going to throw away.

186
00:26:39.990 --> 00:26:50.730
Jirah Cox: The compute and storage and refresh both at once to your point that's a lot of work that we just described, and we can do both of those unintended with basically zero operator interaction whatsoever.

187
00:26:51.750 --> 00:26:54.210
Jirah Cox: So really practically giving back a lot of time in your day.

188
00:26:54.630 --> 00:27:00.450
Jirah Cox: To focus on frankly more important things right, the business can just trust this and let you go work on what's next.

189
00:27:01.620 --> 00:27:03.420
Ben Rogers: Now, I do have another question about it.

190
00:27:04.590 --> 00:27:17.220
Ben Rogers: I did have stretch layer to it my environment that was a very difficult thing for me to achieve what are you guys seeing out in the field, how many customers are set up with a stretch layer to environment between their data centers.

191
00:27:18.600 --> 00:27:23.280
Jirah Cox: comes down a little bit to their networking provider it's certainly easier on others and harder on on some.

192
00:27:25.290 --> 00:27:28.080
Jirah Cox: scale depends on how many how many sites they might have in play.

193
00:27:30.270 --> 00:27:42.090
Jirah Cox: Both are valid i'd say it's about where do you want to put the enos right like if you're not doing it well, that your networking configuration is simple, but you need a lot of kind of monitoring and planning around.

194
00:27:42.690 --> 00:27:54.930
Jirah Cox: Okay, you know if I if I just have two sites keep it simple now I need to track to IP addresses and which ones live in DNS and which one are my customers going to get to my internal application user is going to get to load balancing gets kind of fun.

195
00:27:56.640 --> 00:28:02.190
Jirah Cox: So we were kind of, in my opinion, as a non network guy just someone who's kind of network competent slash dangerous.

196
00:28:02.610 --> 00:28:12.660
Jirah Cox: we're moving complexity into the os and up right and my recovery plans, compared to maybe it's more expensive at the network layer maybe it's more initial setup.

197
00:28:13.050 --> 00:28:18.360
Jirah Cox: But now I don't have to worry about any of that from ios and up level to push that down into the network stack so.

198
00:28:18.690 --> 00:28:26.940
Jirah Cox: I mean scalability matters here right your gateways trombone in your traffic, there are considerations that, frankly, you shouldn't come to me for guidance on.

199
00:28:27.450 --> 00:28:34.080
Jirah Cox: There are smarter people to to look at your scenario and tell you which ones, the better choice for you, but both are valid for sure.

200
00:28:34.830 --> 00:28:41.250
Ben Rogers: So I think I think the question I would have to ask my company is you know what's your art yet how fast, you want to get back up.

201
00:28:41.430 --> 00:28:48.330
Ben Rogers: Sorry, to know IP conflicting no IP changes the is going to run just the same as it did in primary.

202
00:28:48.810 --> 00:28:57.330
Ben Rogers: Good to go, so I think a lot of that you have to be you have to have those conversations when your organization, you know what do you want to rpi to look like what you want you to look like.

203
00:28:57.570 --> 00:29:10.860
Ben Rogers: What stress, do you want the business to incur while we're getting to our our to because they talk about business continuity and business continuity and Dr are they work together, but they're different.

204
00:29:11.070 --> 00:29:14.010
Ben Rogers: And in times of trying to maintain continuity, while you're.

205
00:29:14.010 --> 00:29:19.770
Ben Rogers: Doing Dr practice can that can get that can get stressful very quick and so.

206
00:29:20.160 --> 00:29:31.890
Ben Rogers: very interesting another question I have has to come with the playbook say this gentleman's written this very elaborate script if i'm hearing you correctly, this script was put together with our.

207
00:29:32.550 --> 00:29:45.690
Ben Rogers: Low code no code in it export it in can be imported back in Am I hearing that correctly or did this gentleman actually fat finger or fat finger this into this, you know text file and imported in educate me on that i'm wondering.

208
00:29:46.140 --> 00:29:54.270
Jirah Cox: Know total yeah exactly what you described it's it's impossible exportable, you know you can write it in one PC and then give it to your customers or give it to a teammate.

209
00:29:54.720 --> 00:30:05.700
Jirah Cox: as well, like the way he's posted here into his blog post yeah so so we say it's low code no code it actually can also you can inject Code into it right to do even more fancy advanced stuff.

210
00:30:06.570 --> 00:30:20.550
Ben Rogers: that's awesome, you know as a as an employee learning the product, this has been one thing this is incredible to be able to bring this type of automation and not have to understand it coding background it's just incredible for administrator.

211
00:30:21.450 --> 00:30:31.380
Harvey Green: yeah absolutely that's and that's another thing, and you, you you haven't heard me say it yeah and since since you're here and you're new new tactics, for your sanity.

212
00:30:34.740 --> 00:30:48.450
Harvey Green: You don't have to go and learn every bit of this right, you don't have to be a networking expert you don't have to be a coding expert you don't have to be a Dr expert, but you get all of those things out of this one platform to your point.

213
00:30:48.450 --> 00:30:49.020
Jirah Cox: So yeah.

214
00:30:49.560 --> 00:30:54.480
Jirah Cox: Well, what about one more freebie on my freebie to get the audience So if you go to New tannic Dev.

215
00:30:55.650 --> 00:31:07.260
Jirah Cox: Which is our site focused on developers there's an entire code library under automation and then playbooks library, where you know so, so this is one example of a playbook there's other code samples for other playbooks.

216
00:31:08.460 --> 00:31:15.480
Jirah Cox: All up there, that you can download it and then upload into your prison central to get those other pre written.

217
00:31:15.990 --> 00:31:26.190
Jirah Cox: playbooks at your disposal there, so if you if you take nothing else away from today there's a freebie for you, that there's more playbooks than you already even see inside your person central yeah absolutely.

218
00:31:27.870 --> 00:31:28.410
Harvey Green: All right.

219
00:31:30.000 --> 00:31:33.810
Harvey Green: Anything else from from your customer mindset, Mr Rogers.

220
00:31:34.980 --> 00:31:39.570
Ben Rogers: Not my biggest thing right now is I would love to get in the lab and see this thing run in real time.

221
00:31:40.470 --> 00:31:46.680
Ben Rogers: Right anybody could I cool so that's that's really my next goal is to take this blog and kind of guy let's.

222
00:31:47.070 --> 00:31:53.220
Ben Rogers: let's put this in the lab and see if this you know comes to reality, but from for me, being a former customer.

223
00:31:53.550 --> 00:32:00.090
Ben Rogers: This would be great especially some of the challenges that we're looking from a marketplace, not just technology, but how the markets changing.

224
00:32:00.660 --> 00:32:16.440
Ben Rogers: And then, also with all the changes that are going on with vendors that you know, have been around for years, this is a good direction and something I think a lot of people are going to be looking at if mechanics can make it as easy as it's documented katie bar the door, my friend.

225
00:32:16.770 --> 00:32:21.360
Harvey Green: yeah absolutely so so direct to that point, how can we learn more.

226
00:32:24.030 --> 00:32:32.250
Jirah Cox: I love learning from labs so I know I can get those from my friendly eugenics account team, I can get that from the INTEGRA boot camps make that easy as well.

227
00:32:32.580 --> 00:32:35.580
Jirah Cox: So I would I would look for the next one of those coming up, and probably trying to join that.

228
00:32:36.690 --> 00:32:38.670
Harvey Green: That sounds like a good idea to me.

229
00:32:40.290 --> 00:32:49.770
Harvey Green: And if they do do that then i'll be right there with them to host and kind of train them through so definitely looking forward to.

230
00:32:50.310 --> 00:33:01.980
Harvey Green: jumping all with anybody who decides to get on learn some more ask them more questions go through this process, you know, however, they However, you want to experience it will make them.

231
00:33:02.310 --> 00:33:05.310
Jirah Cox: happy when I looked if I know it wasn't from boot camp is.

232
00:33:05.370 --> 00:33:20.070
Harvey Green: Man, you know you can just go to his integrity.com and check out our events page and that's where we have them listed, but I will say, I believe, on top of my head he made me do it off the top of my head, but I believe the next one is the 29th of July so.

233
00:33:20.820 --> 00:33:21.690
got one kind of like.

234
00:33:23.730 --> 00:33:24.030
Jirah Cox: sure.

235
00:33:24.330 --> 00:33:26.850
Harvey Green: yeah you absolutely can go register right now.

236
00:33:29.790 --> 00:33:41.310
Harvey Green: So, yes integrity.com and you'll go to the events page and all events will show you everything that we have not just a new tonics workshop that i'm doing i'll show you everything there.

237
00:33:42.120 --> 00:33:49.920
Harvey Green: You can also get to all of our podcast episodes because you love this one so much and you want to listen to the other ones so i'm here.

238
00:33:50.880 --> 00:33:52.650
Harvey Green: Before I know.

239
00:33:54.630 --> 00:33:58.770
Harvey Green: To 36 whichever one you want.

240
00:34:02.730 --> 00:34:10.710
Harvey Green: All right, I appreciate it guys definitely appreciate you getting on, and discussing this and we will have fun next week.

241
00:34:11.760 --> 00:34:12.000
Jirah Cox: cool.