Latest / Nutanix Weekly / Nutanix Weekly: Step-by-Step Guide to Deploying Nutanix Metro Availability

Transcript

Nutanix Weekly: Step-by-Step Guide to Deploying Nutanix Metro Availability · Nutanix Weekly

WEBVTT 1 00:00:02.520 --> 00:00:06.629 Andy Whiteside: Everyone welcome to episode 53 of mechanics weekly i'm your host Andy whiteside got. 2 00:00:07.589 --> 00:00:24.630 Andy Whiteside: Harvey green with me, who is kind of local he's a I don't know 45 minutes away by car and gyros now two and a half, three hours away by car, we were just debating define local in 2022 Harvey was your answer to how you to find local in 2022. 3 00:00:25.080 --> 00:00:38.130 Harvey Green: I told jarrod that his mother, the latency between where he is and where I am round trip in my car isn't what it used to be at all so he's not as local as he used to be yeah. 4 00:00:38.880 --> 00:00:45.180 Jirah Cox: If I recall my high school physics i've been saying i'm two and a half to three hours away make certain assumptions about speed. 5 00:00:46.410 --> 00:00:46.890 Andy Whiteside: Well yeah. 6 00:00:47.550 --> 00:00:49.290 Harvey Green: I defined in my car. 7 00:00:51.120 --> 00:01:01.110 Andy Whiteside: Well, and you're really saying how fast, can I get to you in this case, get there and get back and acknowledge somebody acknowledged that you got they're not in this is really good for what we're gonna talk about here in a second. 8 00:01:03.240 --> 00:01:10.020 Andy Whiteside: But you know so Harvey i'm not doing it today, but let's say able to leave my office and go pick up my kids at school, I know exactly how to get there. 9 00:01:10.320 --> 00:01:18.960 Andy Whiteside: Yes, but because I don't know what traffic is going to be like where I live, where you live it's a nightmare i'm sure where I live, now probably a nightmare to yeah um. 10 00:01:19.590 --> 00:01:25.170 Andy Whiteside: You know I don't know how to get there, because I don't know what the traffic situation is going to be, therefore, I use smart software. 11 00:01:25.500 --> 00:01:34.680 Andy Whiteside: Okay, like an sd way and type of thing, but in this case I use GPS and it's in my car I turn it on, even though I know where i'm going and occasion it's like oh no don't go that way you need. 12 00:01:34.680 --> 00:01:35.040 Right. 13 00:01:36.240 --> 00:01:40.290 Andy Whiteside: I gotta be stubborn oh i'm going this way and I go the way I know and like oh no car accident. 14 00:01:40.500 --> 00:01:41.970 Three hours sitting in traffic. 15 00:01:43.800 --> 00:01:51.420 Andy Whiteside: Which kind of maybe takes us to our topic for today and and I asked about we were talking about stretch clusters, the other week and I brought up. 16 00:01:52.770 --> 00:01:54.450 Andy Whiteside: metro know was a call. 17 00:01:57.120 --> 00:02:07.800 Andy Whiteside: And gyro has brought that topic for today from the new tannic Community blogs, step by step guides deploy new tactics metro availability. 18 00:02:08.280 --> 00:02:17.970 Jirah Cox: Yes, a drone wrote up a fantastic blog post here I love, how are our Community blog engine assigned some the label of trendsetter fantastic. 19 00:02:18.750 --> 00:02:33.450 Jirah Cox: career as your own on your trend setter status and yeah I think another fun connection to make here between you driving somewhere you've already learned how to get to, but the value is the software he called out, but also the the data right the real time data of like. 20 00:02:34.530 --> 00:02:46.020 Jirah Cox: How are the roads running right and what do I want to avoid as I get from A to B there has a lot of applicability right, because we can use our we can use a metro cluster obviously for. 21 00:02:47.040 --> 00:02:56.910 Jirah Cox: worst case scenarios, but there's value in even not all the way to worst case scenarios as well right so like we can use it for like say planned maintenance right if I know that I need to. 22 00:02:59.730 --> 00:03:08.670 Jirah Cox: get ahead of like say generator maintenance or transfer switch or ups maintenance, maybe I want to go ahead and move workloads over to other data Center anyway right rather than. 23 00:03:10.050 --> 00:03:15.030 Jirah Cox: You know, trust that ups maintenance is going to go totally totally smoothly yeah. 24 00:03:16.170 --> 00:03:23.910 Andy Whiteside: The goal is to get there and get there as fast as you can, but you want to get there in one piece so getting there is the most important part. 25 00:03:24.150 --> 00:03:26.370 Andy Whiteside: yeah we have become overly. 26 00:03:27.540 --> 00:03:37.320 Andy Whiteside: Overly familiar with the idea of the acceptance that we have to get there fast and that's today's age, but getting there getting there all in one piece. 27 00:03:38.730 --> 00:03:39.480 Harvey Green: Yes. 28 00:03:40.500 --> 00:03:43.290 Harvey Green: Totally oh packet or limb loss. 29 00:03:49.170 --> 00:03:50.760 Jirah Cox: I can't agree yeah. 30 00:03:54.210 --> 00:03:56.580 Jirah Cox: This podcast is officially against limb loss. 31 00:03:56.610 --> 00:03:58.890 Jirah Cox: Yes, i'll plant that flag. 32 00:03:59.850 --> 00:04:01.590 Andy Whiteside: No blood and guts and Gore. 33 00:04:02.880 --> 00:04:03.510 Harvey Green: that's right. 34 00:04:03.690 --> 00:04:04.200 Jirah Cox: So to. 35 00:04:04.500 --> 00:04:05.910 Andy Whiteside: me no data loss either, though. 36 00:04:06.480 --> 00:04:07.500 Jirah Cox: Totally no data loss. 37 00:04:07.680 --> 00:04:08.670 Jirah Cox: Know James what data loss. 38 00:04:08.970 --> 00:04:15.150 Jirah Cox: So to start painting a word picture here right in drums drums right up here, I have is. 39 00:04:15.810 --> 00:04:31.740 Jirah Cox: I think this is a lab deployment so start off with two new tonics clusters, so we want one cluster in like site a or availability zone, a or data Center a another cluster in sight to availability zone to data Center to what uh however you break them up. 40 00:04:32.790 --> 00:04:45.030 Jirah Cox: The entire point or at the end state of deploying and you say next metro cluster which is really tuning to X clusters and then and then one in this case, this is using V sphere as the hypervisor which is not required, you can do it on HP as well. 41 00:04:46.440 --> 00:04:54.660 Jirah Cox: Is the outcome of you know all all the humans are asleep at three in the morning one data Center goes fully dark loses power let's say. 42 00:04:55.590 --> 00:05:06.390 Jirah Cox: All I want all workloads to automatically resume at the other data Center and to your point Harvey what zero data loss right so just as if the vm is crashed at one site. 43 00:05:06.900 --> 00:05:13.050 Jirah Cox: And they will power, on the other side, as if it was a DJ event from node to node within one cluster but we're going to cross. 44 00:05:13.380 --> 00:05:22.980 Jirah Cox: A larger geography than just within one cluster right we're not going from blade to blade node to node rack Rack, this is going to go from data Center at the data Center be right is the. 45 00:05:24.420 --> 00:05:28.920 Jirah Cox: expected and desired outcome so to do that we've got our clusters that each site. 46 00:05:29.940 --> 00:05:37.050 Jirah Cox: Because each cluster has an autonomous unit right so i'm going to write in this case, probably two copies of data and cluster a two copies of data and cluster B. 47 00:05:37.620 --> 00:05:44.880 Jirah Cox: keep them in sync and then with synchronous replication right no data loss I wait for that remote acknowledgement. 48 00:05:45.300 --> 00:05:57.930 Jirah Cox: So if a vm is running it site a I wait for site be to tell me hey i've got that data as well before I acknowledge back to the guest vm hey i've got your data right, so the right doesn't succeed, to the guest os until we've got data written on both clusters. 49 00:05:59.130 --> 00:06:00.480 Jirah Cox: So, within each cluster then. 50 00:06:01.860 --> 00:06:12.600 Jirah Cox: You know, then on each cluster I create a local data store basically or a data store that goes from from data store eight site A to B and then it's i'd be I created a data store container. 51 00:06:12.960 --> 00:06:21.240 Jirah Cox: From site beat a so i've got both my both my directions their journeys the the the nomenclature metro one dash two and metro to dash one. 52 00:06:22.290 --> 00:06:35.760 Jirah Cox: But basically it's It shows in the labeling right for a human to see these are vm that replicate from one site to another site and what the direction is there, so we can keep a straight as we're like building a new vm in our vm creation wizard so. 53 00:06:36.090 --> 00:06:47.490 Andy Whiteside: i've got cluster number one in building one and then how far away can cluster number to be to do this and how much redundancy do I have to have. 54 00:06:48.600 --> 00:06:49.200 Jirah Cox: So. 55 00:06:49.320 --> 00:06:50.790 Jirah Cox: The next person is not set. 56 00:06:50.880 --> 00:07:02.250 Jirah Cox: By how far away, is not a factor of distance factor of latency book says we want to be five milliseconds away or less in reality we want to be as close to the or less as possible. 57 00:07:03.420 --> 00:07:06.630 Jirah Cox: If you told me that the link has four milliseconds of latency from end to end. 58 00:07:07.110 --> 00:07:20.970 Jirah Cox: Then that's four milliseconds you're going to add to each and every single right for the life of the cluster right you're slowing down all vm right operations by that delay, so we want that to be as low as possible zero milliseconds one millisecond as much, much better. 59 00:07:21.240 --> 00:07:34.140 Harvey Green: So that that's very, very important that you bring that up because you know, one of the things that we talked about a lot with 10 X is the acknowledgement of rights and the kind of women to this a little bit too, but. 60 00:07:34.680 --> 00:07:52.440 Harvey Green: You want to make sure that you've got the optimal set and that you're not killing yourself performance wise to try to make this work, because you actually are waiting on that latency to take place before those rights are acknowledged as I write. 61 00:07:52.830 --> 00:08:03.090 Jirah Cox: 100% yeah yeah if a vm lives inside one and you've configured it for synchronous replication decided to then it's going to wait until site to says i've got that data, before I can proceed. 62 00:08:03.900 --> 00:08:19.890 Harvey Green: yeah so for for all the people who haven't been doing this very long they say well for a millisecond that's nothing I got you know 30 or 40 or 50 or 60 between this Simon this next slide Why would I care about for. 63 00:08:22.320 --> 00:08:24.450 Jirah Cox: Good because it's a lot for your storage system. 64 00:08:25.200 --> 00:08:30.480 Jirah Cox: started adding 60 milliseconds to everything you did on your laptop you would be negative one phone call. 65 00:08:31.560 --> 00:08:32.940 Jirah Cox: or or looking for a new laptop. 66 00:08:33.660 --> 00:08:40.080 Harvey Green: Right so that's that's for the I guess the the big answer behind that is that for a millisecond every right. 67 00:08:40.410 --> 00:08:42.600 Jirah Cox: Every single right. 68 00:08:42.780 --> 00:08:48.300 Andy Whiteside: So that's what we really talk in fiber configurations, in order to get this done so, we do have a copper these days. 69 00:08:49.200 --> 00:08:58.770 Jirah Cox: The medium doesn't matter too much well to be at any kind of meaningful distance you probably will be fiber away, you could I sure you could use copper technically to be properly agnostic. 70 00:09:00.390 --> 00:09:06.840 Jirah Cox: It almost becomes a matter of function of availability planning right and like shared nothing so. 71 00:09:07.290 --> 00:09:17.070 Jirah Cox: Could I get from like a data Center hall to data Center hall like we have some regional data centers around here that have multiple kind of shared nothing availability zones within one roof. 72 00:09:18.420 --> 00:09:28.320 Jirah Cox: And if you want to do that, of course, you totally could but normally most customers will be looking to go like across the city, maybe across the state, depending on what size of state you're sitting in when you listen to this. 73 00:09:29.610 --> 00:09:31.740 Jirah Cox: New England, yes, Texas, maybe not. 74 00:09:33.090 --> 00:09:34.230 Jirah Cox: in general. 75 00:09:34.320 --> 00:09:38.040 Jirah Cox: 50 ish miles i've heard is kind of a typical translation of. 76 00:09:39.180 --> 00:09:42.870 Jirah Cox: The kind of low latency you'd want to to build this kind of a construct on top of. 77 00:09:45.270 --> 00:09:48.090 Andy Whiteside: And that that aren't that rf so right. 78 00:09:49.110 --> 00:09:51.570 Andy Whiteside: redundancy factor of two. 79 00:09:51.630 --> 00:09:52.350 Harvey Green: To yeah. 80 00:09:52.590 --> 00:09:53.220 Andy Whiteside: Now, would you. 81 00:09:53.250 --> 00:09:56.580 Andy Whiteside: Typically, have a say you got to have at least redundancy factor of two, on the other. 82 00:09:56.580 --> 00:09:59.640 Andy Whiteside: side to courage and are we waiting on both thumbs right you're just one of them. 83 00:10:00.930 --> 00:10:03.390 Jirah Cox: Both but they occur, you know simultaneously. 84 00:10:04.830 --> 00:10:15.480 Harvey Green: yeah so that that latency we're talking about potentially that formula seconds only has to happen once and then, once it gets to the other side it's writing that second right locally. 85 00:10:16.260 --> 00:10:20.610 Jirah Cox: Because don't like in some ways don't overthink it like it's the cluster. 86 00:10:20.910 --> 00:10:25.980 Jirah Cox: So my data to the other cluster the cluster won't acknowledge it until it right is compliant with the rf. 87 00:10:27.390 --> 00:10:30.870 Jirah Cox: Right, so you sort of are waiting on both be related in the cluster to acknowledge it. 88 00:10:31.770 --> 00:10:39.510 Andy Whiteside: Okay, so it's the clusters, the brain of a quick question for you, it doesn't miss I did a quick search, we have to have prison central to pull this off for now. 89 00:10:39.660 --> 00:10:41.400 Jirah Cox: We actually do. 90 00:10:42.660 --> 00:10:51.120 Jirah Cox: not really for this one as as drones are up in his lab yeah not not fully required recommended as a lot of value to every environment yeah. 91 00:10:52.650 --> 00:11:02.070 Andy Whiteside: If you can see what i'm doing I did I did the path being out yahoo.com and i'm working my way down the chain to start seeing you know more than four seconds seconds and they'll let. 92 00:11:03.210 --> 00:11:21.600 Jirah Cox: Well, so remember that often there's some black magic going on there right if you say it in Google 8888 right or 888844 either one that's a magical IP that like can have over responder closer to my house then say California. 93 00:11:21.900 --> 00:11:22.260 Jirah Cox: Right. 94 00:11:22.320 --> 00:11:23.670 Jirah Cox: So there's some there's some. 95 00:11:26.550 --> 00:11:29.580 Jirah Cox: I don't know enough to know if that's a bgp funniness or. 96 00:11:30.300 --> 00:11:37.500 Andy Whiteside: i'm actually not trying Google see the Yahoo, in this case was 30 something milliseconds i'm pinging things that I found the. 97 00:11:37.800 --> 00:11:39.510 Andy Whiteside: Green oh along the way. 98 00:11:39.960 --> 00:11:40.650 yeah. 99 00:11:45.090 --> 00:11:45.750 Andy Whiteside: oppressive hmm. 100 00:11:46.230 --> 00:11:47.790 Jirah Cox: I know the path thing is interesting. 101 00:11:48.000 --> 00:11:48.360 Jirah Cox: it's like it's. 102 00:11:49.320 --> 00:11:59.520 Andy Whiteside: crazy yeah it's kinda like trace route, but it gives you I think I don't know long time ago I learned it and thought it was the most amazing thing when I was using trace routes, I started using path beings. 103 00:11:59.730 --> 00:12:00.810 Harvey Green: hmm interesting. 104 00:12:01.890 --> 00:12:02.340 Andy Whiteside: Something. 105 00:12:02.520 --> 00:12:16.740 Jirah Cox: worth calling out like almost every time that you entertain this kind of design within text metro this isn't going to be over you're either private lines or a vpn tunnel or dark fiber you know you wouldn't really do it over the real Internet. 106 00:12:16.860 --> 00:12:22.170 Harvey Green: yeah another good point you know you don't want us to go outside your network and come back. 107 00:12:24.030 --> 00:12:27.450 Jirah Cox: Well, it would add a dramatic predictability to latency. 108 00:12:27.480 --> 00:12:28.860 Harvey Green: Exactly yeah. 109 00:12:29.730 --> 00:12:36.600 Andy Whiteside: So the very first time I experienced this, I had a university they had two data centers across the parking lot from each other. 110 00:12:37.110 --> 00:12:46.020 Andy Whiteside: And they had super low latency and they had redundant fiber that went out the back of the building out the front of the building through the under the parking lot around the parking lot. 111 00:12:46.560 --> 00:13:01.710 Andy Whiteside: And they actually didn't deal with the metro cluster they ended up going with the cluster and they put two nodes in one building two nodes in the other and the nuttiness guys were looking really not happy with that, but they did it and it seems to have worked is that common. 112 00:13:02.520 --> 00:13:06.060 Jirah Cox: Not common not recommended glad it's working out for them. 113 00:13:07.200 --> 00:13:10.530 Jirah Cox: But I would also postulate that's probably untested failure. 114 00:13:12.870 --> 00:13:14.370 Jirah Cox: Primarily because. 115 00:13:15.630 --> 00:13:20.400 Jirah Cox: We never recommend you know with any distributed system right you wouldn't want. 116 00:13:22.080 --> 00:13:29.070 Jirah Cox: a quorum violating amount of notes yeah to be able to be partitioned right or split brain. 117 00:13:29.310 --> 00:13:41.820 Jirah Cox: So if you have two and two and then they can't communicate neither one really understands which one is the is the quorum and either those failures constitute like an an rf violating level of failures. 118 00:13:42.240 --> 00:13:55.500 Harvey Green: Right yeah if you've got to into, and one of those sites goes down, and now you have to have, for then you're not in a good position to recover from anything I mean your. 119 00:13:56.460 --> 00:14:03.660 Harvey Green: I guess everything at that point will begin thrashing trying to figure out where the other side is because we need at least three. 120 00:14:04.590 --> 00:14:15.630 Jirah Cox: Well, or you nearly three, but also for node cluster you only configure rf to which is a lose one of anything type of scenario and instantly we've lost two so we're kind of already in a in a bad way. 121 00:14:15.900 --> 00:14:23.070 Andy Whiteside: Yes, well and I guess the thing that made it slightly okay was the fact they had lots of redundancy which physically that might have been Okay, but. 122 00:14:23.400 --> 00:14:30.570 Andy Whiteside: Still, could have been a human error that could have wiped out that redundancy and next thing you know everything is going crazy thinking it's, the only thing left on the planet. 123 00:14:30.840 --> 00:14:32.580 Harvey Green: Absolutely yeah. 124 00:14:33.480 --> 00:14:43.650 Jirah Cox: We wouldn't really go crazy but, but I have no there's the you know, whatever whichever one you call the surviving side here is like Okay, with it, and just keep on running of the pair of to. 125 00:14:44.040 --> 00:14:53.580 Jirah Cox: write that we'll just we'll just stop all operations wait until we can restore cluster health and then resume forward in time we're actually you know new taxes remarkably resilient platform. 126 00:14:54.090 --> 00:15:05.850 Jirah Cox: In terms of like taking good care of customer data and and accommodating the unexpected but that accommodating can often be like we'll just turtle up and safeguard your data until you heal the network that we get back up and running. 127 00:15:07.110 --> 00:15:10.050 Andy Whiteside: My life at home, something will happen everybody just starts away for dad to get home. 128 00:15:16.500 --> 00:15:18.300 Andy Whiteside: My kids my wife is gonna listen to this. 129 00:15:18.420 --> 00:15:19.020 Andy Whiteside: On nevermind. 130 00:15:20.130 --> 00:15:23.280 Harvey Green: yeah something something sort of literal split brain yeah. 131 00:15:23.970 --> 00:15:40.800 Harvey Green: yeah I was gonna say good for you, they turtle up and wait for you to get home i'm sure it is annoying but not as annoying as they continue to just go further and further down that rabbit hole So then, by the time I get to it it's 10 times worse than it was when it started. 132 00:15:42.060 --> 00:15:45.090 Andy Whiteside: Honestly, my boys will definitely do that, like they. 133 00:15:46.980 --> 00:15:51.540 Andy Whiteside: just keep wrapping the string around the lawn mower blade until I just is unfixable. 134 00:15:53.610 --> 00:15:55.980 Harvey Green: yeah yes that's what I expect. 135 00:15:58.260 --> 00:15:58.530 Andy Whiteside: Okay. 136 00:15:59.220 --> 00:16:12.570 Jirah Cox: So we've got our tunes unix clusters one in one cluster per site each of them has you know those those data stores those containers that are you know from me to you and from you to me replication created on both sides. 137 00:16:14.520 --> 00:16:18.660 Jirah Cox: Then we of course we want to add all nodes to a vmware cluster in the Center. 138 00:16:19.950 --> 00:16:30.660 Jirah Cox: One cluster right, so this is a key point we're going to use to new tax clusters add them both to one single V Center cluster reason for that being is because, when reason he is excited as our. 139 00:16:31.200 --> 00:16:45.300 Jirah Cox: hypervisor the management and control plane dictates that the H a boundary is at the cluster level, so you can't have V sphere ha from one cluster to another that's all we want all nodes to be in one single these for cluster. 140 00:16:46.650 --> 00:16:57.030 Jirah Cox: So it's it's intuitive once you think about it, but some people might on their own think they want two clusters, which would be an accurate geographical representation, but we want where she went the opposite, we want one. 141 00:16:58.140 --> 00:17:02.250 Jirah Cox: One logical cluster with to participate in tax clusters within it. 142 00:17:04.650 --> 00:17:18.330 Jirah Cox: Once they're in there there's an accommodation here given for like how vcs gets placed right the way that these for does modern ha, that of course is fine doesn't need any any real tinkering just create a bcs data store preach site, because those of us won't migrate won't move. 143 00:17:20.370 --> 00:17:31.470 Jirah Cox: Within that there's some recommendations here on drs right basically leave drs fully automated threshold three, of course, no power management, no advanced options that's all pretty straightforward. 144 00:17:32.820 --> 00:17:45.780 Jirah Cox: Some flags here around the PD handling for each host for how we want to handle at events ha handling of course monitor vm for availability on host failure restart vm. 145 00:17:47.160 --> 00:17:51.660 Jirah Cox: admission control failures right for most rfp clusters tolerate one failure. 146 00:17:52.740 --> 00:18:01.530 Jirah Cox: For data store heartbeat right so like the to metro data stores and then advanced options can also stay up to there as well, so now this point we've got. 147 00:18:03.510 --> 00:18:13.380 Jirah Cox: Our containers created our boutiques clusters created our single visa V Center cluster created and we've got our dear as an option set on both of those two clusters. 148 00:18:13.680 --> 00:18:17.250 Andy Whiteside: Entire, whereas the Center living in this world doesn't matter. 149 00:18:17.580 --> 00:18:17.970 So. 150 00:18:19.260 --> 00:18:29.610 Jirah Cox: Ideally, the books as the most right answer is it live somewhere else right we don't want it to necessarily be on one of these clusters that it is protecting for drones live environment yeah he calls out that even does that. 151 00:18:30.840 --> 00:18:39.480 Jirah Cox: But there's considerations for like an actual production environment where if you're going to go do this for real for your day job the Center should go elsewhere right yeah and there's actually a reason. 152 00:18:40.200 --> 00:18:53.280 Jirah Cox: we'll get back to so we'll also be creating later on a witness vm witness vm absolutely has to be outside the cluster that it's protecting right so it's going to be witnessing which of my to surviving surviving clusters is already. 153 00:18:54.870 --> 00:19:03.450 Jirah Cox: You know alive, which ones, my survivor which ones offline so we already have a third availability zone right for the witness V centers should go there as well, probably. 154 00:19:05.370 --> 00:19:13.350 Andy Whiteside: And tyra maybe we're going into a section down below here where it talks more about the witness, is it a witness a witness looking at both clusters that works. 155 00:19:13.410 --> 00:19:18.930 Jirah Cox: Correct yep a witness both clusters both can see it both get get registered to it yep. 156 00:19:19.560 --> 00:19:32.820 Andy Whiteside: Is that does anybody mechanics offer that piece as a service like external or maybe I just came up with the business model, but he can that does new tannic software as a service or is that a vm that lives on the network somewhere. 157 00:19:33.480 --> 00:19:43.230 Jirah Cox: It is a vm that does live somewhere on your network in terms of as a service, I mean I saw the next clusters of the service that can run witness films. 158 00:19:44.220 --> 00:19:59.040 Jirah Cox: But also, in a less jokey way you can even earn that anywhere you want it to write you can run it on nani 10 X right on anything you wanted to you could run it on anything next cluster in public cloud anywhere you needed to you want to treat like a third availability zone yeah okay. 159 00:19:59.730 --> 00:20:04.650 Andy Whiteside: it's not a lot to those things it sounds scary and then you do it one time I go that's all I did. 160 00:20:04.950 --> 00:20:14.880 Jirah Cox: Now it's very lightweight and all it is basically just you know i'm sure it is more than this basically just raise your heartbeats and then let someone know that it's the survivor and if. 161 00:20:16.320 --> 00:20:17.280 Jirah Cox: If they can't see each other. 162 00:20:17.670 --> 00:20:21.570 Andy Whiteside: it's some type of virtual appliance right it's not a windows box is that. 163 00:20:21.750 --> 00:20:22.890 Jirah Cox: Correct it's a ritual blinds. 164 00:20:23.220 --> 00:20:25.380 Andy Whiteside: Not a container that's Why would have virtual appliance. 165 00:20:25.920 --> 00:20:28.770 Jirah Cox: Correct also not containers virtual points okay. 166 00:20:31.200 --> 00:20:37.230 Jirah Cox: So then one additional bit of construct here right is going to be creating host groups and. 167 00:20:38.400 --> 00:20:47.460 Jirah Cox: affinity rules with envy Center so what that means is that we want to teach the Center right i've got host group one host group to. 168 00:20:48.000 --> 00:20:58.890 Jirah Cox: And then we'll also then create some should rules with envy Center to say these vm should run on cluster one these idioms should run a cluster to because obviously a we want data locality be we don't want. 169 00:20:59.850 --> 00:21:13.080 Jirah Cox: All the rights getting dragged across to the wrong cluster because each each storage data right each each data store is owned by one cluster or the other, so we want to make sure that those Games get preferential access to where the data actually lives in as readable. 170 00:21:13.290 --> 00:21:21.210 Andy Whiteside: And when you see, mostly in the field is it pretty much one clusters loaded up in the next other ones to illness thumbs waiting or the people kind of divide out the workloads there's. 171 00:21:21.570 --> 00:21:25.200 Jirah Cox: You could do either one there is probably. 172 00:21:27.570 --> 00:21:36.210 Jirah Cox: Probably no real need to go for full and empty because statistically, I would hope that as you're planning this as if, as a company. 173 00:21:36.630 --> 00:21:46.740 Jirah Cox: Your data centers i've hopefully equal risk right there's not one that's like more likely to go offline than the other, if that is the case, you know if if one you know goes down every third Tuesday for. 174 00:21:47.370 --> 00:21:52.290 Jirah Cox: Inexplicably reasons, then sure treat that as the empty one right and plan to run new workloads there. 175 00:21:53.490 --> 00:22:04.980 Jirah Cox: But but but, for the most part, most for the most part, most companies would prefer to run with like balance workloads right and most application servers will bring that way to write run half my domain controllers on one side half that the other half of my. 176 00:22:06.870 --> 00:22:18.270 Jirah Cox: You know web servers and one of the other deploy ag databases, with a leg on each side right so it's better in most ways to split my workloads across those but you could do either one yeah. 177 00:22:19.410 --> 00:22:26.010 Andy Whiteside: I think the reality at least it has been up until recently, as you had the old building, there was the data Center he bought a new data Center. 178 00:22:26.280 --> 00:22:35.040 Andy Whiteside: Now the old building became the backup and it never should have been the data Center To begin with, but you know, all I can afford is one and, but now, with the world of co lows and cloud that has a better. 179 00:22:36.810 --> 00:22:49.050 Jirah Cox: yeah it'd be my hope, but it is just that I hope that you know yeah right with high quality modern colo is that having to two data centers neither which is inherently more risky than the other is can be an easy reality. 180 00:22:50.460 --> 00:22:56.370 Jirah Cox: So we've got our our rules in place that you know certain vm should run on on one side, certainly am should run at the other side. 181 00:22:59.100 --> 00:23:14.820 Jirah Cox: And then yeah we get here to deploy the witness, so we deploy that as a virtual appliance given an IP address, and then we within each each as closer register those clusters, with the witness vm so they both check in their heart beating to make sure that they are online. 182 00:23:15.930 --> 00:23:17.430 Jirah Cox: So, then, I lost it. 183 00:23:17.760 --> 00:23:18.990 Andy Whiteside: How often are they touching it. 184 00:23:19.440 --> 00:23:20.370 Jirah Cox: um I don't know. 185 00:23:21.480 --> 00:23:23.040 Jirah Cox: Very often, it must be. 186 00:23:23.070 --> 00:23:24.090 Andy Whiteside: Like almost non stop. 187 00:23:27.660 --> 00:23:32.730 Jirah Cox: mean yeah I would assume yeah that's got to be very, very frequent yeah okay. 188 00:23:33.870 --> 00:23:38.100 Jirah Cox: um you know mail a postcard once a week that should be fine right. 189 00:23:41.040 --> 00:23:47.760 Jirah Cox: So the we can deploy it in your lab if you want, you can then become packet sniffing watch how often those things call each other. 190 00:23:49.890 --> 00:23:51.450 Andy Whiteside: And why you would hard, we can do that and let me know. 191 00:23:53.640 --> 00:23:55.500 Jirah Cox: So you're not that curious okay interesting. 192 00:23:56.340 --> 00:23:57.240 Andy Whiteside: have other things. 193 00:23:57.420 --> 00:23:59.160 Andy Whiteside: Of course we all do at this point. 194 00:23:59.190 --> 00:24:07.860 Andy Whiteside: But maybe a was the guy's name had a really cool name guy who wrote the blog drum your own list is the restaurant i'm sure he knows. 195 00:24:08.010 --> 00:24:08.430 Jirah Cox: There you go. 196 00:24:09.810 --> 00:24:24.990 Jirah Cox: So, the last thing to do, then, is a turn an application right so we're going to replicate and we named our our containers running meaningfully right from one to two and from two to one we're going to go in and they were application in that direction named in the in the container. 197 00:24:26.340 --> 00:24:35.370 Jirah Cox: And that's it that's the, that is the end of the setup process with talk you through it in the span of a single podcast episode So then, what does this look you do. 198 00:24:36.330 --> 00:24:41.430 Jirah Cox: For one right, of course, you can now live migrate across clusters right because the motion within a data store. 199 00:24:41.940 --> 00:24:49.890 Jirah Cox: The much within a cluster is super easy to do with the V Center level so that lets you get your live migration, and this is where where we like we open with. 200 00:24:50.370 --> 00:25:01.710 Jirah Cox: scenarios, where you can do planned workload migration to avoid say plan to data Center maintenance, so that would be easy right and now we're back to rerouting around traffic on the way to school. 201 00:25:03.660 --> 00:25:14.970 Jirah Cox: So with that I can you know turn off either update my drs rules or turn off ERS project updating the rule is better update my role to save these vm should run at the other site. 202 00:25:16.410 --> 00:25:18.810 Jirah Cox: don't migrate over, and then I can activate their. 203 00:25:19.830 --> 00:25:31.950 Jirah Cox: Their container right, so I can take the data store named one to an activated at site to to make it readable there so that i've moved all my workloads into one basket and now I can. 204 00:25:32.730 --> 00:25:47.730 Jirah Cox: Do maintenance packet data Center one yeah and then I can move them back over so i've got my my live migration across data centers they're pretty easy and all i'm really doing is touching my drs rules there for where that should rule will place my vm. 205 00:25:48.840 --> 00:25:53.700 Jirah Cox: But then the other real outcome that most customers are going to look at this for is that you know. 206 00:25:54.600 --> 00:26:04.470 Jirah Cox: The smoking whole data Center goes dark at three in the morning kind of scenario and my vm Czar and ha event away from recovering at the alternate data Center so that's sort of a. 207 00:26:04.800 --> 00:26:07.950 Jirah Cox: You know no human touch is a button, but all the workloads come back up. 208 00:26:08.730 --> 00:26:21.210 Jirah Cox: is usually that's really the the plan you know there's some migration maintenance is a nice to have but, really, they must have is the no data loss all data written across to another data Center before it. 209 00:26:21.990 --> 00:26:28.380 Jirah Cox: Ever gets acknowledged and then auto workload result resuming across the wire there at the other data Center or the real. 210 00:26:30.090 --> 00:26:31.140 Jirah Cox: Huge deliverables. 211 00:26:31.740 --> 00:26:41.430 Andy Whiteside: So harvey's probably had more interaction with this and I have most of my world has been around vdi and building, you know non persistent on one side nonprofits, on the other, but have control over your control over there. 212 00:26:41.820 --> 00:26:45.480 Andy Whiteside: And if one went down all the other stuff just kept going I ran a half my load but. 213 00:26:45.780 --> 00:26:52.230 Andy Whiteside: I still had something available now where it really becomes interesting on the vdi world is all those persistent desktops that. 214 00:26:52.530 --> 00:27:07.560 Andy Whiteside: You know they can't live in both places same time this all of a sudden solve that challenge, and there are lots of rollouts where they have hundreds if not thousands of persistent vdi workloads that need to need to be available have if one day that's what's other cluster was gone. 215 00:27:08.730 --> 00:27:09.390 metric plus. 216 00:27:12.120 --> 00:27:22.290 Andy Whiteside: or vm this one's always been a fascinating to me so i've kind of dominate any specific comments or questions or thoughts on metro clusters and what you've seen. 217 00:27:23.700 --> 00:27:42.000 Harvey Green: I mean, for me, is what I guess what I would have expected, I mean not not a lot of last week shouldn't say, not a lot, there are lots of customers who do get this kind of flexibility, because they have those sites that are geographically. 218 00:27:43.860 --> 00:27:51.300 Harvey Green: Geographically available for this something that's this open enough or fast enough or low enough latency that they can pull this off. 219 00:27:52.710 --> 00:28:11.160 Harvey Green: It doesn't happen for everybody, so it's not something that i'd say I run into very often but it's definitely something that i've run into often enough that you know it's it's good to know the ins and outs behind it and how you can set it up to test like Jerome did. 220 00:28:12.450 --> 00:28:13.710 Jirah Cox: And some of the key like. 221 00:28:13.920 --> 00:28:24.630 Jirah Cox: What is it not call out like you don't need specific node types, not a ton of virtual appliances to deploy it's the one witness right and beyond that you're just using regular detect clusters to do it so. 222 00:28:24.660 --> 00:28:32.550 Andy Whiteside: Direct that brings up a couple things, let me ask, let me ask the one question just popped in my head I guess you got to have at least the same amount of storage capacity on both sides. 223 00:28:32.910 --> 00:28:39.810 Andy Whiteside: If you're going to be going from each direction towards each other, you got to have enough storage to cover that replication right. 224 00:28:39.990 --> 00:28:45.030 Jirah Cox: I don't know if it's a hard requirement but boy I would you recommend it yeah otherwise like it's pretty interesting yeah. 225 00:28:45.330 --> 00:28:48.780 Andy Whiteside: And then we talked all through this article this blog about doing it with. 226 00:28:49.140 --> 00:28:50.400 Andy Whiteside: vmware it probably just. 227 00:28:50.400 --> 00:28:54.570 Andy Whiteside: gets us even slightly easier if not a lot easier on HIV or not. 228 00:28:55.080 --> 00:29:09.090 Jirah Cox: Correct yeah because in this one right we're sort of using the concert and the Center of ha is a cluster property eugenics already knows when it's managing an HP environment that each cluster you know, has its own hga control plane. 229 00:29:10.170 --> 00:29:18.270 Jirah Cox: So the steps, a little bit different set it up, but yeah the vm recovery automatically across synchro on HP is also possible yeah cool. 230 00:29:19.440 --> 00:29:25.110 Andy Whiteside: Well guys, I think that wraps it up, this is, this is very interesting this This, to me, is a little more interesting than red hat open shift, I have to admit. 231 00:29:27.900 --> 00:29:28.230 Andy Whiteside: i'm. 232 00:29:28.260 --> 00:29:29.190 Jirah Cox: Sorry redhead. 233 00:29:30.420 --> 00:29:34.740 Andy Whiteside: it's good stuff it's just not how my you know where my where my passions been. 234 00:29:36.360 --> 00:29:41.220 Andy Whiteside: There was a brief like three months, there were, I tried to become a Linux server guy in the early 2000s. 235 00:29:42.390 --> 00:29:58.710 Andy Whiteside: That in a unix guy and then, then I got the way I didn't I did not make it I ended up back in the windows in the vdi world I thought was more fun, but I get it, I love getting down deep into Colonel and commanding myself away. 236 00:30:00.000 --> 00:30:04.080 Jirah Cox: And both are important, you could use this to protect your red hat open shift environment for sure sure. 237 00:30:05.550 --> 00:30:10.590 Andy Whiteside: Well guys happy Monday and thanks for joining, and this was fun and we'll we'll do it again a week. 238 00:30:11.430 --> 00:30:12.000 Jirah Cox: Every Wednesday. 239 00:30:12.960 --> 00:30:13.440 Harvey Green: See you guys.