WEBVTT 1 00:00.180 --> 00:02.370 So regarding deploying an NSX Manager 2 00:02.370 --> 00:04.620 or a cluster of NSX Managers, 3 00:04.620 --> 00:06.510 let's first of all put a game plan together. 4 00:06.510 --> 00:09.210 So I've currently got a Management Cluster, 5 00:09.210 --> 00:12.810 and it contains exactly two ESXi hosts. 6 00:12.810 --> 00:16.050 That's ESXi-C, and ESXi-D, and at the moment, 7 00:16.050 --> 00:19.230 ESXi-D is currently running my vCenter Server. 8 00:19.230 --> 00:20.063 And what we're gonna do now 9 00:20.063 --> 00:21.690 is we're gonna plan on the implementation 10 00:21.690 --> 00:23.670 of our first NSX Manager, 11 00:23.670 --> 00:26.460 and we'll go ahead and use ESXi-C as the home 12 00:26.460 --> 00:27.810 for that little VM. 13 00:27.810 --> 00:29.460 Or I guess I shouldn't say little VM. 14 00:29.460 --> 00:31.410 We have some options regarding, you know, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 14 00:29.460 --> 00:31.410 We have some options regarding, you know, 15 00:31.410 --> 00:33.600 extra small, small, medium, or large, 16 00:33.600 --> 00:35.790 regarding how much resources we wanted it to take. 17 00:35.790 --> 00:37.620 But in any case, as far as our plan goes, 18 00:37.620 --> 00:40.500 let's use ESXi-C in our Management Cluster 19 00:40.500 --> 00:43.650 as the home for this NSX Manager VM. 20 00:43.650 --> 00:44.700 Now, in a production environment, 21 00:44.700 --> 00:47.160 it's very likely we're not just gonna have one NSX Manager. 22 00:47.160 --> 00:48.900 We'd very likely have three. 23 00:48.900 --> 00:52.140 So let me go ahead and add a couple more ESXi hosts here 24 00:52.140 --> 00:54.570 based on a plan for some fault tolerance 25 00:54.570 --> 00:55.860 and some redundancy. 26 00:55.860 --> 00:58.860 And this one we'll call ESXi-E. 27 00:58.860 --> 01:01.020 And this will be ESXi-F. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 00:58.860 --> 01:01.020 And this will be ESXi-F. 28 01:01.020 --> 01:02.460 So then what we'd do is we'd go ahead 29 01:02.460 --> 01:06.720 and for our three NSX VMs that we're using for management, 30 01:06.720 --> 01:08.430 we'd put them on separate hosts. 31 01:08.430 --> 01:12.003 So this could be NSX.11, and this could be NSX.12, 32 01:12.960 --> 01:15.420 and this could be NSX.13. 33 01:15.420 --> 01:18.840 And the three of those collectively would be in a cluster. 34 01:18.840 --> 01:20.340 And ideally, each of those members 35 01:20.340 --> 01:21.720 of this NSX Management Cluster 36 01:21.720 --> 01:23.730 would be in different ESXi hosts, 37 01:23.730 --> 01:25.260 again, for the benefit of fault tolerance. 38 01:25.260 --> 01:27.030 That way, if we lose one of our ESXi hosts, 39 01:27.030 --> 01:30.960 we still have a couple NSX Managers in our cluster WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 01:27.030 --> 01:30.960 we still have a couple NSX Managers in our cluster 40 01:30.960 --> 01:32.430 that are still up and active. 41 01:32.430 --> 01:34.410 So let's imagine that we have deployed 42 01:34.410 --> 01:38.280 three NSX Manager appliances as part of a cluster, 43 01:38.280 --> 01:40.350 and then you and I are sitting on the management network, 44 01:40.350 --> 01:41.850 or we have access to the management network, 45 01:41.850 --> 01:43.830 and this is our management PC right here. 46 01:43.830 --> 01:45.720 So one of the challenges is that if we do have a failure, 47 01:45.720 --> 01:47.280 let's say ESXi-C fails, 48 01:47.280 --> 01:49.380 or for some reason this VM fails, 49 01:49.380 --> 01:50.640 it's no longer functioning, 50 01:50.640 --> 01:52.470 either way, that's out of commission, 51 01:52.470 --> 01:54.990 how do we know which IP address to connect to, 52 01:54.990 --> 01:58.560 to use the graphical user interface for the NSX Manager? 53 01:58.560 --> 01:59.640 And the solution to that problem 54 01:59.640 --> 02:01.590 regarding which IP address do we connect to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 01:59.640 --> 02:01.590 regarding which IP address do we connect to 55 02:01.590 --> 02:03.930 is to use a virtual IP. 56 02:03.930 --> 02:06.180 So let's imagine that we set up a virtual IP address, 57 02:06.180 --> 02:07.530 and here on my management network, 58 02:07.530 --> 02:10.920 this is the 192.168.1.0 network. 59 02:10.920 --> 02:13.920 It happens to be VLAN 1 in my studio here. 60 02:13.920 --> 02:17.490 And let's set up a virtual IP address of .10. 61 02:17.490 --> 02:19.110 And that would be for the NSX cluster. 62 02:19.110 --> 02:21.510 So what we would do is we would connect to .10 63 02:21.510 --> 02:23.640 for the graphical user interface. 64 02:23.640 --> 02:26.730 Or for using APIs, we'd go to the .10 address. 65 02:26.730 --> 02:28.530 And then one of the NSX Managers 66 02:28.530 --> 02:29.970 inside that Management Cluster 67 02:29.970 --> 02:32.100 would be responsible for responding to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 67 02:29.970 --> 02:32.100 would be responsible for responding to 68 02:32.100 --> 02:35.100 and interacting with us as we communicate with .10. 69 02:35.100 --> 02:36.870 So in that case, it wouldn't matter too much 70 02:36.870 --> 02:39.330 if we had one individual NSX Manager 71 02:39.330 --> 02:40.860 that wasn't available as part of the cluster, 72 02:40.860 --> 02:42.840 because we're connecting that virtual IP address, 73 02:42.840 --> 02:43.980 and behind the scenes, 74 02:43.980 --> 02:46.800 one of the existing running NSX Manager nodes 75 02:46.800 --> 02:47.970 is gonna support that. 76 02:47.970 --> 02:51.210 So let me bring back ESXi-C into a running state. 77 02:51.210 --> 02:52.620 And behind the scenes, what's happening 78 02:52.620 --> 02:54.930 with these NSX Managers inside the cluster 79 02:54.930 --> 02:57.660 is they are sharing a common database, 80 02:57.660 --> 02:59.013 and it's called CorfuDB. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 81 03:00.060 --> 03:02.430 So the word Corfu is not regarding the Greek island, 82 03:02.430 --> 03:03.600 but rather it's regarding 83 03:03.600 --> 03:06.360 a common, object-oriented, real-time framework, 84 03:06.360 --> 03:08.670 some acronym regarding a common database 85 03:08.670 --> 03:10.260 that's maintained in memory, 86 03:10.260 --> 03:11.640 that's based on a shared log. 87 03:11.640 --> 03:14.730 So long story short, the NSX Managers in the cluster, 88 03:14.730 --> 03:16.680 behind the scenes, they are sharing 89 03:16.680 --> 03:18.360 and interacting with the CorfuDB, 90 03:18.360 --> 03:20.520 which is distributed across them. 91 03:20.520 --> 03:23.640 So, again, if we have one NSX Manager that goes away, 92 03:23.640 --> 03:26.070 the shared database regarding NSX is being shared 93 03:26.070 --> 03:27.450 across the remaining two, 94 03:27.450 --> 03:29.370 which is gonna provide fault tolerance 95 03:29.370 --> 03:31.620 inside of our NSX Management Cluster. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 95 03:29.370 --> 03:31.620 inside of our NSX Management Cluster. 96 03:31.620 --> 03:33.240 Another important aspect to be aware of 97 03:33.240 --> 03:34.380 with the Corfu database is, 98 03:34.380 --> 03:36.360 because it's being maintained in real time 99 03:36.360 --> 03:37.620 across these devices, 100 03:37.620 --> 03:42.060 we don't wanna do snapshots on our NSX Manager VMs. 101 03:42.060 --> 03:43.470 In fact, as part of the deployment, 102 03:43.470 --> 03:45.270 it's disabled by default. 103 03:45.270 --> 03:48.060 If you try to do a snapshot, it won't be available to you. 104 03:48.060 --> 03:50.100 And let's chat for a moment about the integration 105 03:50.100 --> 03:54.510 that's required between our NSX Management and our vCenter. 106 03:54.510 --> 03:56.310 So I'm gonna put a little line here 107 03:56.310 --> 03:58.470 just representing that they need to work together. 108 03:58.470 --> 03:59.430 And one of the questions might be, 109 03:59.430 --> 04:01.620 well, why do we need to work together with vCenter? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 109 03:59.430 --> 04:01.620 well, why do we need to work together with vCenter? 110 04:01.620 --> 04:03.300 Well, NSX needs to know several things. 111 04:03.300 --> 04:04.800 One of 'em, for example, might be, 112 04:04.800 --> 04:09.330 which ESXi hosts do we want to add the NSX software to, 113 04:09.330 --> 04:12.120 to go ahead and make them host transport nodes 114 04:12.120 --> 04:13.620 as part of NSX? 115 04:13.620 --> 04:16.890 And so the NSX Manager communicates with vCenter 116 04:16.890 --> 04:20.550 to identify and determine which ESXi hosts are out there. 117 04:20.550 --> 04:22.050 Or if we want to deploy, for example, 118 04:22.050 --> 04:24.750 a second or a third NSX Manager, once again, 119 04:24.750 --> 04:26.580 we're gonna be leveraging the vCenter Server, 120 04:26.580 --> 04:29.460 which knows about which hosts are out there and reachable. 121 04:29.460 --> 04:31.860 Or if we wanna deploy an Edge node WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 121 04:29.460 --> 04:31.860 Or if we wanna deploy an Edge node 122 04:31.860 --> 04:34.800 to support our gateway services inside of NSX, 123 04:34.800 --> 04:36.990 once again, we'll rely on the vCenter. 124 04:36.990 --> 04:39.240 And the vCenter, once again, is gonna provide us information 125 04:39.240 --> 04:41.250 about which ESXi hosts are available 126 04:41.250 --> 04:44.970 that can be the home for that Edge transport node, 127 04:44.970 --> 04:48.840 that VM that we're gonna deploy as part of NSX. 128 04:48.840 --> 04:51.420 Because at the end of the day, if we're deploying a VM, 129 04:51.420 --> 04:52.890 it needs to run somewhere. 130 04:52.890 --> 04:55.770 And vCenter knows about all the compute resources 131 04:55.770 --> 04:56.610 that it's managing. 132 04:56.610 --> 04:57.750 And that's one of the other reasons 133 04:57.750 --> 04:59.160 why we're integrating the two together. 134 04:59.160 --> 05:02.400 Another reason why we're integrating the NSX Manager WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 134 04:59.160 --> 05:02.400 Another reason why we're integrating the NSX Manager 135 05:02.400 --> 05:05.580 with the vCenter is because we are gonna be leveraging 136 05:05.580 --> 05:07.410 a distributed switch, 137 05:07.410 --> 05:10.620 which is presided and controlled by vCenter. 138 05:10.620 --> 05:12.480 And as we add NSX to our environment, 139 05:12.480 --> 05:14.760 we're gonna be adding logical segments. 140 05:14.760 --> 05:17.130 Think of 'em like Layer 2 broadcast domains 141 05:17.130 --> 05:19.410 that are gonna look like port groups available 142 05:19.410 --> 05:20.760 under the distributed switch. 143 05:20.760 --> 05:24.240 So, once again, the NSX Manager, working with vCenter, 144 05:24.240 --> 05:28.260 can identify what those existing distributed switches are. 145 05:28.260 --> 05:29.410 And as we create additional overlay segments, 146 05:29.410 --> 05:31.140 and I think of an overlay segment WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 146 05:29.410 --> 05:31.140 and I think of an overlay segment 147 05:31.140 --> 05:33.240 like a Layer 2 broadcast domain, 148 05:33.240 --> 05:36.600 as we create additional Layer 2 overlay segments in NSX, 149 05:36.600 --> 05:38.640 those will be visible under our distributed switch 150 05:38.640 --> 05:41.430 as we look at that distributed switch via vCenter. 151 05:41.430 --> 05:45.030 So over here, let me draw a few NSX nodes. 152 05:45.030 --> 05:47.070 Now, these could be host transport nodes, 153 05:47.070 --> 05:50.580 which is an ESXi host, which has been enabled for NSX, 154 05:50.580 --> 05:51.930 or they could be an Edge node, 155 05:51.930 --> 05:53.640 whether it's a Bare Metal Edge node, 156 05:53.640 --> 05:56.460 or it's a VM acting as an Edge node. 157 05:56.460 --> 05:57.870 So for short, I'm gonna just refer to these 158 05:57.870 --> 05:59.640 as NSX nodes for a moment here. 159 05:59.640 --> 06:02.100 I'll label 'em 1, 2, 3, and 4. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 159 05:59.640 --> 06:02.100 I'll label 'em 1, 2, 3, and 4. 160 06:02.100 --> 06:04.080 And these are the objects that the NSX Manager 161 06:04.080 --> 06:06.120 would be responsible for interacting with. 162 06:06.120 --> 06:07.530 So once we have a cluster set up 163 06:07.530 --> 06:08.520 and a virtual IP address, 164 06:08.520 --> 06:10.740 effectively the NSX Manager Cluster 165 06:10.740 --> 06:13.890 is the NSX Manager service or function. 166 06:13.890 --> 06:15.990 And let's imagine we have this NSX Manager here, 167 06:15.990 --> 06:18.120 and it's at .10 on the management network, 168 06:18.120 --> 06:21.150 the 192.168.1.0 network here in my studio. 169 06:21.150 --> 06:23.730 So the NSX Manager VM or VMs 170 06:23.730 --> 06:26.400 are acting as a centralized control plane. 171 06:26.400 --> 06:27.630 And if you and I wanna manage 172 06:27.630 --> 06:30.300 or manipulate anything as far as NSX goes, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 172 06:27.630 --> 06:30.300 or manipulate anything as far as NSX goes, 173 06:30.300 --> 06:33.060 we are gonna log in to the NSX Manager, 174 06:33.060 --> 06:35.940 connecting to the virtual IP address of the cluster. 175 06:35.940 --> 06:38.820 And as NSX Manager works with the nodes it's managing, 176 06:38.820 --> 06:41.790 it's going to instruct them on how to behave effectively. 177 06:41.790 --> 06:45.060 It's a centralized control plane for NSX nodes. 178 06:45.060 --> 06:46.380 And then each of the NSX nodes, 179 06:46.380 --> 06:48.180 they're gonna keep a local copy 180 06:48.180 --> 06:49.560 regarding what they need to know about 181 06:49.560 --> 06:50.820 regarding the control plane. 182 06:50.820 --> 06:54.090 So there's a local control plane stored here on this node 183 06:54.090 --> 06:57.480 and on this node and on this one and on this one. 184 06:57.480 --> 06:59.520 And that way, if the centralized control plane, 185 06:59.520 --> 07:02.250 for example, all the NSX Managers are unavailable, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 06:59.520 --> 07:02.250 for example, all the NSX Managers are unavailable, 186 07:02.250 --> 07:04.080 these nodes can still operate and behave 187 07:04.080 --> 07:06.480 because they have a local copy of the information they need 188 07:06.480 --> 07:08.580 for the control plane to do their job. 189 07:08.580 --> 07:10.470 And when I refer to doing their jobs, 190 07:10.470 --> 07:12.510 one of the primary jobs of our NSX nodes, 191 07:12.510 --> 07:15.690 whether it's a ESXi-based host transport node, 192 07:15.690 --> 07:19.710 or if it's a VM-based or a Bare Metal Edge transport node, 193 07:19.710 --> 07:21.210 one of the main functions of those nodes 194 07:21.210 --> 07:22.890 is to actually move traffic. 195 07:22.890 --> 07:24.540 For example, a user's forwarding traffic, 196 07:24.540 --> 07:25.950 or a VM is forwarding traffic 197 07:25.950 --> 07:28.140 to another location or to another device. 198 07:28.140 --> 07:29.700 It's the transport node's responsibility, 199 07:29.700 --> 07:32.490 based on the control plane, to forward the data. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 199 07:29.700 --> 07:32.490 based on the control plane, to forward the data. 200 07:32.490 --> 07:34.500 And that's referred to as the data plane. 201 07:34.500 --> 07:37.470 So a centralized control plane is at the NSX Manager. 202 07:37.470 --> 07:38.700 Each of their respective nodes 203 07:38.700 --> 07:40.740 has their appropriate local control plane. 204 07:40.740 --> 07:42.660 And then each of the NSX nodes 205 07:42.660 --> 07:44.700 that are participating as part of NSX 206 07:44.700 --> 07:46.350 are gonna be involved in the data plane. 207 07:46.350 --> 07:47.700 And one great way to remember that 208 07:47.700 --> 07:50.640 is think of the word transport, like moving something. 209 07:50.640 --> 07:54.720 So if we have an ESXi host that's been enabled for NSX, 210 07:54.720 --> 07:57.330 that's referred to as a host transport node. 211 07:57.330 --> 07:59.370 And if we've deployed an Edge node 212 07:59.370 --> 08:02.430 that can provide the Layer 3 routing and gateway services, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 212 07:59.370 --> 08:02.430 that can provide the Layer 3 routing and gateway services, 213 08:02.430 --> 08:05.070 that'd be referred to as an Edge transport node. 214 08:05.070 --> 08:06.270 So when we think about the data plane, 215 08:06.270 --> 08:07.590 just think of the word transport, 216 08:07.590 --> 08:10.800 and it's the host transport nodes and Edge transport nodes 217 08:10.800 --> 08:11.910 that are doing that work. 218 08:11.910 --> 08:14.220 It's also the same nodes that have the ability 219 08:14.220 --> 08:17.340 to build the overlay tunnels using Geneve 220 08:17.340 --> 08:19.320 so they can forward through the tunnels 221 08:19.320 --> 08:21.210 wherever the traffic needs to be forwarded to. 222 08:21.210 --> 08:23.190 Now, when deploying and working with NSX, 223 08:23.190 --> 08:25.110 if we wanna have success, and I think we do, 224 08:25.110 --> 08:26.490 we wanna keep a few things in mind. 225 08:26.490 --> 08:30.180 One is latency, or the delay involved, between two points. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 225 08:26.490 --> 08:30.180 One is latency, or the delay involved, between two points. 226 08:30.180 --> 08:31.440 So if we have NSX Managers, 227 08:31.440 --> 08:32.310 let's go ahead and put a few here. 228 08:32.310 --> 08:36.480 We'll put NSX 11 and NSX 12 229 08:36.480 --> 08:40.740 and NSX 13 as managers, as part of a Management Cluster. 230 08:40.740 --> 08:43.440 We wanna make sure the latency between them 231 08:43.440 --> 08:44.610 is very, very low. 232 08:44.610 --> 08:47.910 We want the latency to be 10 milliseconds or less. 233 08:47.910 --> 08:50.700 So I'll put less than or equal to 10 milliseconds 234 08:50.700 --> 08:53.880 for the communications between those NSX Managers 235 08:53.880 --> 08:54.713 in the cluster. 236 08:54.713 --> 08:57.030 And that's they're using CorfuDB, 237 08:57.030 --> 08:59.370 and they're synchronizing that information near real time. 238 08:59.370 --> 09:00.203 So we wanna make sure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 238 08:59.370 --> 09:00.203 So we wanna make sure 239 09:00.203 --> 09:02.400 that they have high-speed connectivity to each other. 240 09:02.400 --> 09:05.430 Also, for those VMs for accessing their storage, 241 09:05.430 --> 09:07.620 we'd also wanna make sure the latency 242 09:07.620 --> 09:10.230 is 10 milliseconds or less. 243 09:10.230 --> 09:11.670 So that'd be traffic between these VMs 244 09:11.670 --> 09:14.340 and also for these VMs to their storage, 245 09:14.340 --> 09:16.650 whether that's local on an ESXi host 246 09:16.650 --> 09:19.770 or, more likely, on some shared network storage. 247 09:19.770 --> 09:21.870 The next part about latency else we need to be aware of 248 09:21.870 --> 09:24.180 is latency between the NSX Managers 249 09:24.180 --> 09:26.340 and the NSX nodes that they're managing. 250 09:26.340 --> 09:31.140 And that should be less than or equal to 150 milliseconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 250 09:26.340 --> 09:31.140 And that should be less than or equal to 150 milliseconds. 251 09:31.140 --> 09:33.600 So let's manage this as a host transport node, 252 09:33.600 --> 09:35.160 and this is a host transport node, 253 09:35.160 --> 09:37.080 and this is a Edge transport node, 254 09:37.080 --> 09:38.670 and this is an Edge transport node. 255 09:38.670 --> 09:40.050 In any case, we'd wanna make sure 256 09:40.050 --> 09:42.360 we don't have extreme latency or delay 257 09:42.360 --> 09:45.630 between the NSX Managers and those nodes. 258 09:45.630 --> 09:46.463 And when I mean extreme, 259 09:46.463 --> 09:49.530 we'd want it to be less than or equal to 150 milliseconds 260 09:49.530 --> 09:50.940 for that communication path. 261 09:50.940 --> 09:52.710 Also, as far as the protocols that are being used 262 09:52.710 --> 09:55.620 between the NSX Managers and the nodes, 263 09:55.620 --> 10:00.620 it is gonna be using TCP ports 1234 and 1235. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 263 09:55.620 --> 10:00.620 it is gonna be using TCP ports 1234 and 1235. 264 10:00.630 --> 10:01.980 So on our network infrastructures, 265 10:01.980 --> 10:05.760 if we're blocking TCP ports 1234 or 12345, 266 10:05.760 --> 10:08.820 that would also cause a problem between our NSX Managers 267 10:08.820 --> 10:11.520 and the NSX nodes they're trying to manage. 268 10:11.520 --> 10:13.320 Again, that includes host transport nodes 269 10:13.320 --> 10:14.880 or Edge transport nodes. 270 10:14.880 --> 10:18.510 We'd wanna make sure that TCP port 1234 and 1235 271 10:18.510 --> 10:22.200 are open and available between the manager and the nodes. 272 10:22.200 --> 10:24.270 Now, for the deployment of our NSX Managers, 273 10:24.270 --> 10:26.370 including the first one and the second and third one 274 10:26.370 --> 10:28.320 for fault tolerance here in our cluster, 275 10:28.320 --> 10:30.600 we have some options regarding what size WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 275 10:28.320 --> 10:30.600 we have some options regarding what size 276 10:30.600 --> 10:32.430 of VM do we want to deploy. 277 10:32.430 --> 10:36.000 And that's gonna boil down to how much CPU and RAM 278 10:36.000 --> 10:38.490 is going to be required based on our deployment. 279 10:38.490 --> 10:39.870 So there's four choices. 280 10:39.870 --> 10:42.390 We have, like, Goldilocks and the three bears plus one. 281 10:42.390 --> 10:45.300 So there's extra small, small, medium, and large. 282 10:45.300 --> 10:47.010 So based on the expected number 283 10:47.010 --> 10:48.780 of devices we're gonna be managing, 284 10:48.780 --> 10:51.240 we'd wanna choose the appropriate appliance size 285 10:51.240 --> 10:53.250 for the deployment of our NSX Manager. 286 10:53.250 --> 10:57.300 So if we deploy the first NSX Manager as size medium, 287 10:57.300 --> 11:00.420 then as we deploy our second and third in the cluster, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 287 10:57.300 --> 11:00.420 then as we deploy our second and third in the cluster, 288 11:00.420 --> 11:02.670 we'd wanna use medium there as well. 289 11:02.670 --> 11:04.980 And that way, we have a nice even balance of resources 290 11:04.980 --> 11:09.120 across each of the managers in our NSX Manager Cluster. 291 11:09.120 --> 11:11.250 And let's put a game plan together 292 11:11.250 --> 11:14.460 for what we want to configure and then verify together. 293 11:14.460 --> 11:16.470 So I'll label this as Game Plan. 294 11:16.470 --> 11:17.700 The first thing I think we ought to do 295 11:17.700 --> 11:19.920 before we start deploying an NSX Manager 296 11:19.920 --> 11:23.040 is let's just verify our current infrastructure. 297 11:23.040 --> 11:25.500 So as part of that, we'd wanna verify the port group 298 11:25.500 --> 11:29.580 that we're gonna be using on ESXi-C for the NSX Manager, 299 11:29.580 --> 11:31.650 for its management network connectivity. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 299 11:29.580 --> 11:31.650 for its management network connectivity. 300 11:31.650 --> 11:34.710 We'd also wanna verify things like NTP is available, 301 11:34.710 --> 11:37.650 and also DNS services are available. 302 11:37.650 --> 11:39.030 And to that end, I also have 303 11:39.030 --> 11:41.400 a little management server right here, 304 11:41.400 --> 11:45.930 and it's at 192.168.1.100. 305 11:45.930 --> 11:47.430 And that's the little Windows server 306 11:47.430 --> 11:51.390 that's providing NTP services and DNS services as well. 307 11:51.390 --> 11:54.210 So we wanna verify that for whatever NSX Managers 308 11:54.210 --> 11:55.470 we're gonna put in place, 309 11:55.470 --> 11:56.790 we're also gonna take another moment 310 11:56.790 --> 12:00.750 and just verify that we also have DNS resolution in place. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 310 11:56.790 --> 12:00.750 and just verify that we also have DNS resolution in place. 311 12:00.750 --> 12:02.250 And if we don't, we'd wanna fix that 312 12:02.250 --> 12:04.770 by adding the DNS resolution as A records 313 12:04.770 --> 12:07.050 or, in the case of IP.6, with AAAA records. 314 12:07.050 --> 12:09.900 I'd also recommend, beside the forward lookups, 315 12:09.900 --> 12:11.940 also to have pointer records set up 316 12:11.940 --> 12:13.770 for reverse lookups as well. 317 12:13.770 --> 12:16.890 We'd also wanna verify our current vCenter Server 318 12:16.890 --> 12:19.290 and verify what its IP address is. 319 12:19.290 --> 12:21.720 That IP address for our vCenter Server appliance, 320 12:21.720 --> 12:24.000 which is currently running on ESXi-D, 321 12:24.000 --> 12:28.560 it's at the IP address of 185 on the 192.168.1 subnet here 322 12:28.560 --> 12:29.790 in my home office. 323 12:29.790 --> 12:32.310 So once we've verified our current infrastructure, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 323 12:29.790 --> 12:32.310 So once we've verified our current infrastructure, 324 12:32.310 --> 12:34.980 the next step would be logically deploying 325 12:34.980 --> 12:38.400 the first NSX manager in our vSphere environment. 326 12:38.400 --> 12:40.560 So as a home for our first NSX Manager, 327 12:40.560 --> 12:42.990 let's go ahead and place it on ESXi-C. 328 12:42.990 --> 12:44.490 And for its name, let's go ahead 329 12:44.490 --> 12:49.170 and call it nsx-mgr-11. 330 12:49.170 --> 12:50.850 And I've also got DNS resolution 331 12:50.850 --> 12:54.630 for the domain of ogit.local. 332 12:54.630 --> 12:56.370 So that would be the fully qualified domain name 333 12:56.370 --> 12:58.350 for our first NSX Manager. 334 12:58.350 --> 13:01.092 And then we can put this manager at .11. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 334 12:58.350 --> 13:01.092 And then we can put this manager at .11. 335 13:01.092 --> 13:02.520 And then as a subsequent step, 336 13:02.520 --> 13:05.250 we can also go ahead and create a virtual IP address 337 13:05.250 --> 13:07.290 for the NSX Management Cluster. 338 13:07.290 --> 13:09.960 And for that virtual IP, let's use 10 for the cluster. 339 13:09.960 --> 13:12.180 Also, while we're talking about NSX Managers and planning, 340 13:12.180 --> 13:14.880 let's also plan for a second NSX Manager 341 13:14.880 --> 13:19.050 called NSX Manager 12, and it'll be at .12, 342 13:19.050 --> 13:23.310 and also NSX Manager 13, it'll be at .13. 343 13:23.310 --> 13:24.960 Then we can put them in the same cluster. 344 13:24.960 --> 13:26.160 Now, in a lab environment, 345 13:26.160 --> 13:29.040 you can get away with just one NSX Manager. 346 13:29.040 --> 13:31.230 However, in a production environment for fault tolerance, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 346 13:29.040 --> 13:31.230 However, in a production environment for fault tolerance, 347 13:31.230 --> 13:33.060 you'd wanna have three NSX Managers 348 13:33.060 --> 13:36.900 and have them across three different ESXi hosts 349 13:36.900 --> 13:38.970 for not only the compute and memory resources 350 13:38.970 --> 13:41.370 but also for the benefit of some fault tolerance. 351 13:41.370 --> 13:43.350 So once we deploy the NSX Manager, 352 13:43.350 --> 13:45.330 we'd also wanna go ahead and verify it. 353 13:45.330 --> 13:47.040 Additionally, we're gonna need licensing 354 13:47.040 --> 13:48.480 on the NSX managers. 355 13:48.480 --> 13:49.950 So we'll license them. 356 13:49.950 --> 13:51.240 And if you're building a home lab, 357 13:51.240 --> 13:54.150 one of the easiest and most effective ways of doing this 358 13:54.150 --> 13:56.970 is to join up with VMUG Advantage. 359 13:56.970 --> 14:00.480 As part of that, they'll give you a one-year eval license WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 359 13:56.970 --> 14:00.480 As part of that, they'll give you a one-year eval license 360 14:00.480 --> 14:04.170 that you can use for vSphere and vCenter and NSX Manager 361 14:04.170 --> 14:06.120 and load balancers and a lot more. 362 14:06.120 --> 14:07.350 And the cost of that currently, I think, 363 14:07.350 --> 14:10.950 is around $200 US a year and well worth the investment, 364 14:10.950 --> 14:13.560 'cause you can go ahead and play and use the features 365 14:13.560 --> 14:16.050 and not get stopped because there's no licensing available. 366 14:16.050 --> 14:18.990 So VMMUG Advantage will give you the licensing you need 367 14:18.990 --> 14:20.610 to implement the NSX. 368 14:20.610 --> 14:23.850 And the licensing available as part of VMUG Advantage 369 14:23.850 --> 14:27.360 are intended and specified for evaluation purposes, 370 14:27.360 --> 14:28.470 not for production. 371 14:28.470 --> 14:31.020 Then we wanna go ahead and link up the NSX Manager WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 371 14:28.470 --> 14:31.020 Then we wanna go ahead and link up the NSX Manager 372 14:31.020 --> 14:33.900 and tell it which vCenter to interact and work with. 373 14:33.900 --> 14:36.720 So we'll say right here, register with vCenter. 374 14:36.720 --> 14:39.390 And then if we do have three NSX Managers 375 14:39.390 --> 14:41.070 that are deployed as part of a cluster, 376 14:41.070 --> 14:44.070 we'd also want to set up some anti-affinity rules 377 14:44.070 --> 14:48.240 to cause them to not run on the same exact ESXi host. 378 14:48.240 --> 14:49.830 And that way, if we're using DRS, 379 14:49.830 --> 14:52.650 we can distribute the load for those NSX Managers 380 14:52.650 --> 14:55.320 across three separate ESXi hosts. 381 14:55.320 --> 14:56.640 So I'll make the last little note there, 382 14:56.640 --> 14:59.520 set up some anti-affinity rules for those three VMs 383 14:59.520 --> 15:00.970 that are part of our cluster. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 383 14:59.520 --> 15:00.970 that are part of our cluster.