WEBVTT 1 00:00.000 --> 00:03.920 To really appreciate the concept of a load balancer or sometimes called an 2 00:03.920 --> 00:06.000 application delivery controller, 3 00:06.000 --> 00:11.260 I'd like to take you back in time to the good old days, maybe 20 or 25 years 4 00:11.260 --> 00:11.600 ago. 5 00:11.600 --> 00:15.040 Back in those early days, if we wanted to put a server on the internet, we'd go 6 00:15.040 --> 00:16.640 ahead and get a physical server, 7 00:16.640 --> 00:20.080 we'd install some software and connect that to a network. 8 00:20.080 --> 00:24.230 So here's our server and here's our network segment and let's give the server 9 00:24.230 --> 00:28.480 an address of 10.101.0.5. 10 00:28.480 --> 00:31.500 And then for connectivity out to the internet, let's go ahead and put a simple WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:28.480 --> 00:31.500 And then for connectivity out to the internet, let's go ahead and put a simple 11 00:31.500 --> 00:33.360 firewall from a few decades ago, 12 00:33.360 --> 00:37.440 providing stateful firewall services. It's also connected to this network and 13 00:37.440 --> 00:39.520 let's imagine this is at .1. 14 00:39.520 --> 00:43.510 And then that firewall is connected to a service provider who is allowing 15 00:43.510 --> 00:45.440 further access into the internet. 16 00:45.440 --> 00:51.380 So we have a connection there as well. So maybe this is 23.1.2.9 or whatever 17 00:51.380 --> 00:52.320 its IP address is. 18 00:52.320 --> 00:54.960 And then this device we're doing network address translation. 19 00:54.960 --> 00:58.120 And specifically for customers out here on the internet, let's put a client out 20 00:58.120 --> 00:58.560 here. 21 00:58.560 --> 01:01.840 For this client right here, to get access to the server, we would use something WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 21 00:58.560 --> 01:01.840 For this client right here, to get access to the server, we would use something 22 01:01.840 --> 01:03.600 called destination NAT. 23 01:03.600 --> 01:09.520 So perhaps for the server, we have a reachable address of 23.1.2.5 on the 24 01:09.520 --> 01:10.400 public internet 25 01:10.400 --> 01:13.680 and that maps through the firewall to this server right here. 26 01:13.680 --> 01:17.440 So that way when the client does a DNS lookup and they go to this IP address, 27 01:17.440 --> 01:20.720 that traffic goes through the firewall with the station NAT down to the server, 28 01:20.720 --> 01:22.400 who can then go ahead and respond back. 29 01:22.400 --> 01:27.310 Now, one of the problems with the situation like this is what if this server is 30 01:27.310 --> 01:30.640 taken offline or crashes or simply goes down. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:27.310 --> 01:30.640 taken offline or crashes or simply goes down. 31 01:30.640 --> 01:33.550 The client who's trying to get to this address and as that address is going 32 01:33.550 --> 01:34.160 through the firewall, 33 01:34.160 --> 01:38.240 that server is no longer available to the client. We now have some downtime. 34 01:38.240 --> 01:42.640 We have an out-of-service issue where this server and its contents are no 35 01:42.640 --> 01:44.320 longer available to the clients. 36 01:44.320 --> 01:48.160 So what can we do to help with the fault tolerance and resilience in the world 37 01:48.160 --> 01:52.160 of having this server be available even in the event of a failure? 38 01:52.160 --> 01:55.200 Well, I'm glad you asked. What we can do for our servers instead of just having 39 01:55.200 --> 01:55.920 one server, 40 01:55.920 --> 01:59.520 we can have two or three servers. So let's imagine we have these three servers 41 01:59.520 --> 02:00.400 here connected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 01:59.520 --> 02:00.400 here connected 42 02:00.400 --> 02:05.520 and there's the 10.101.0.0 address space here in our private network. 43 02:05.520 --> 02:10.250 And let's imagine this guy is at .51 and this guy is at .52 and this one is at 44 02:10.250 --> 02:10.880 .53 45 02:10.880 --> 02:14.160 and they all have the same exact content available on them. 46 02:14.160 --> 02:17.220 Another way of saying that in current terms would be saying they all have the 47 02:17.220 --> 02:18.720 same application running. 48 02:18.720 --> 02:21.670 So no matter which server the client goes to, they're going to have the same 49 02:21.670 --> 02:22.240 experience. 50 02:22.240 --> 02:25.040 However, we don't just want to have the firewall do kind of a round-rod 51 02:25.040 --> 02:27.440 approach to the servers because we also want to make sure 52 02:27.440 --> 02:31.280 that the server that the firewall is forming the traffic to is really online. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 02:27.440 --> 02:31.280 that the server that the firewall is forming the traffic to is really online. 53 02:31.280 --> 02:33.680 So here's what we're going to do. We're going to make this network segment a 54 02:33.680 --> 02:34.880 little bit longer 55 02:34.880 --> 02:38.520 and we're going to go ahead and draw the icon that can represent a load bal 56 02:38.520 --> 02:39.120 ancer. 57 02:39.120 --> 02:43.440 So let's imagine this load balancer appliance is at the IP address, say .5. 58 02:43.440 --> 02:47.600 Then we have the firewall do the destination now so that 23.1.2.5 when 59 02:47.600 --> 02:51.610 clients go to that IP address, that global IP address, the firewall can net it 60 02:51.610 --> 02:52.000 over 61 02:52.000 --> 02:55.040 to this address right here of the load balancer. 62 02:55.040 --> 02:57.920 And then behind the scenes, this load balancer, it hasn't just been sitting 63 02:57.920 --> 02:58.080 there, 64 02:58.080 --> 03:01.280 it's also been checking on the health of these three servers to make sure they WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 02:58.080 --> 03:01.280 it's also been checking on the health of these three servers to make sure they 65 03:01.280 --> 03:02.960 are really up and ready for business. 66 03:02.960 --> 03:06.560 So as the first client request comes in, this load balancer can then proxy that 67 03:06.560 --> 03:09.440 and send the first one, for example, over to .53. 68 03:09.440 --> 03:12.320 And then if another client comes in, the load balancer can say, you know what, 69 03:12.320 --> 03:14.240 the next one is going to go to .52. 70 03:14.240 --> 03:18.400 And then the third client comes in and that third request can go over to .51. 71 03:18.400 --> 03:23.340 So the load balancer is acting as a proxy in between the clients and the actual 72 03:23.340 --> 03:23.840 services. 73 03:23.840 --> 03:27.520 So in the event that one of these services goes belly up, it's no longer 74 03:27.520 --> 03:27.920 available, 75 03:27.920 --> 03:30.640 it's not responding back to the load balancer for the health checks. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 75 03:27.920 --> 03:30.640 it's not responding back to the load balancer for the health checks. 76 03:30.640 --> 03:33.440 Let's go ahead and let's take this one out of commission. 77 03:33.440 --> 03:37.680 For future requests that come in, the load balancer, knowing that .53 is no 78 03:37.680 --> 03:39.120 longer up and available, 79 03:39.120 --> 03:43.760 can simply use the remaining two servers as part of this pool of servers. 80 03:43.760 --> 03:46.720 So if I clean this up a little bit, we could redraw it like this. 81 03:46.720 --> 03:50.480 The clients would connect to the load balancer and then the load balancer could 82 03:50.480 --> 03:51.600 go ahead and proxy 83 03:51.600 --> 03:54.960 those requests from the clients down to the servers that are available. 84 03:54.960 --> 03:56.960 And so there's actually two sessions in play. 85 03:56.960 --> 04:01.040 There's a session between the clients and the load balancer and another session WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 85 03:56.960 --> 04:01.040 There's a session between the clients and the load balancer and another session 86 04:01.040 --> 04:05.120 between the load balancer and the server that the client is being served from. 87 04:05.120 --> 04:09.190 Now there's lots of benefits of having a load balancer, including the fact of 88 04:09.190 --> 04:10.000 fault tolerance. 89 04:10.000 --> 04:14.320 We have multiple application servers serving up the same content and if one of 90 04:14.320 --> 04:14.800 those servers 91 04:14.800 --> 04:18.770 becomes unavailable, it won't be a big deal because for future clients coming 92 04:18.770 --> 04:18.960 in, 93 04:18.960 --> 04:22.160 they can still get to the remaining servers because the load balancer is 94 04:22.160 --> 04:22.800 intelligently 95 04:22.800 --> 04:25.760 checking in the background to make sure the servers are up and running. 96 04:25.760 --> 04:29.200 Another cool benefit of having a load balancer in the middle between the client 97 04:29.200 --> 04:30.000 and the servers WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:30.000 --> 04:34.830 is that because we are looking at all that traffic and in the path for all that 99 04:34.830 --> 04:35.280 traffic, 100 04:35.280 --> 04:39.730 there's a lot of opportunity to do things like web application firewall or to 101 04:39.730 --> 04:41.440 do protocol inspection 102 04:41.440 --> 04:45.200 to confirm that clients aren't trying to harm our systems or that their 103 04:45.200 --> 04:45.760 protocols are using 104 04:45.760 --> 04:49.360 are correct. We could at the load balancer decide on the method that we want to 105 04:49.360 --> 04:50.160 go back and forth 106 04:50.160 --> 04:53.520 between various servers, which could be based on least number of connections 107 04:53.520 --> 04:54.080 for any of these 108 04:54.080 --> 04:57.740 servers at the moment or we could do it on a round robin fashion or we could 109 04:57.740 --> 04:58.720 have based on the type 110 04:58.720 --> 05:02.590 of client and the browser type that's being used based on that directed to a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 110 04:58.720 --> 05:02.590 of client and the browser type that's being used based on that directed to a 111 05:02.590 --> 05:04.000 specific server or a 112 05:04.000 --> 05:08.360 specific pool of servers. So we can inspect that traffic and redirect that 113 05:08.360 --> 05:09.440 traffic based on a set 114 05:09.440 --> 05:14.230 of conditions. We can also do inspection and interception of SSL slash TLS. So 115 05:14.230 --> 05:14.800 as clients are 116 05:14.800 --> 05:19.310 coming in, for example, with HTTPS, we could go ahead on the back end and 117 05:19.310 --> 05:20.480 simply use HTTP. Now, 118 05:20.480 --> 05:25.110 there are pros and cons of using HTTP and our data paths because there's an 119 05:25.110 --> 05:25.920 opportunity for 120 05:25.920 --> 05:29.600 unencrypted traffic. And the cool thing is that because that load balancer is 121 05:29.600 --> 05:30.480 here in the middle, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 121 05:29.600 --> 05:30.480 here in the middle, 122 05:30.480 --> 05:34.640 depending on the licenses and the features that are supported, there's a lot of 123 05:34.640 --> 05:35.600 opportunity for 124 05:35.600 --> 05:40.480 analysis and control of the traffic as it goes from the clients to the servers. 125 05:40.480 --> 05:41.040 And this concept 126 05:41.040 --> 05:44.470 of a load balancer isn't just for clients to servers. We could also do it from, 127 05:44.470 --> 05:45.200 for example, 128 05:45.200 --> 05:49.060 web servers over to database servers or to some other application inside the 129 05:49.060 --> 05:49.920 data center. 130 05:49.920 --> 05:54.210 And as I mentioned on some vendors, they refer to it as an application delivery 131 05:54.210 --> 05:54.640 controller. For 132 05:54.640 --> 05:59.290 example, think of a web application or database application or DNS services 133 05:59.290 --> 06:00.400 application and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 133 05:59.290 --> 06:00.400 application and 134 06:00.400 --> 06:04.500 having the load balancer intelligently forward or control the traffic between 135 06:04.500 --> 06:05.680 the parties requesting 136 06:05.680 --> 06:10.360 the information and the systems providing the service. Now, inside the world of 137 06:10.360 --> 06:11.200 NSX, there is a 138 06:11.200 --> 06:16.410 built-in load balancer functionality that we can use. However, that is being 139 06:16.410 --> 06:17.440 phased out. And 140 06:17.440 --> 06:21.580 instead of using the load balancer is built into NSX, VMware is moving towards 141 06:21.580 --> 06:22.640 using the advanced 142 06:22.640 --> 06:26.570 load balancer for virtually everything that needs load balancing. And one of 143 06:26.570 --> 06:27.280 the reasons that they're 144 06:27.280 --> 06:30.990 moving to that is because the advanced load balancer besides its features, it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 06:27.280 --> 06:30.990 moving to that is because the advanced load balancer besides its features, it 145 06:30.990 --> 06:32.880 supports, is also able 146 06:32.880 --> 06:38.110 to do load balancing on lots of different environments, including NSX, Google 147 06:38.110 --> 06:39.680 Cloud, AWS, 148 06:39.680 --> 06:43.930 Microsoft Azure, and more. And it can do this with the concept of a cloud 149 06:43.930 --> 06:44.640 connector. 150 06:44.640 --> 06:48.230 And let me introduce you to a few of the pieces involved as part of the 151 06:48.230 --> 06:50.000 advanced load balancer. 152 06:50.000 --> 06:54.640 There's the brains of the operation, which is deployed as a VM. And that is the 153 06:54.640 --> 06:55.520 icon right here. 154 06:55.520 --> 06:59.360 And that is our controller for the advanced load balancer. And as the name 155 06:59.360 --> 07:00.400 implies, we can think of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 155 06:59.360 --> 07:00.400 implies, we can think of 156 07:00.400 --> 07:05.100 the controller as the control plane for our load balancer. And then on the data 157 07:05.100 --> 07:06.560 plane, the actual 158 07:06.560 --> 07:09.960 component that takes the request from the clients and forwards it to the 159 07:09.960 --> 07:11.040 appropriate server or to 160 07:11.040 --> 07:15.580 the appropriate application, that's performed by another set of VMs. And those 161 07:15.580 --> 07:17.280 are called SEs. 162 07:17.280 --> 07:21.280 And SE is an acronym for service engine. And one of the benefits of having 163 07:21.280 --> 07:22.240 these service engines 164 07:22.240 --> 07:25.570 for the data plane for the actual taking the request from the clients, then 165 07:25.570 --> 07:26.400 forward it to the 166 07:26.400 --> 07:30.840 right server is that these little service engines running as VMs can be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 166 07:26.400 --> 07:30.840 right server is that these little service engines running as VMs can be 167 07:30.840 --> 07:32.800 deployed on demand wherever 168 07:32.800 --> 07:37.320 they're needed. So if it's an NSX cloud environment, we can deploy them inside 169 07:37.320 --> 07:39.040 of vSphere. If it's a 170 07:39.040 --> 07:44.560 AWS or Google Cloud or Microsoft Azure, once again, we can deploy logical 171 07:44.560 --> 07:45.920 service engines 172 07:45.920 --> 07:49.870 wherever they're needed for the data plane. The key behind it is just use the 173 07:49.870 --> 07:50.400 correct cloud 174 07:50.400 --> 07:54.980 connector or cloud connectors plural to allow the controller where we have it 175 07:54.980 --> 07:56.560 deployed to interact 176 07:56.560 --> 08:01.280 with those various environments. Again, AWS Google Cloud, Microsoft Azure, or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 176 07:56.560 --> 08:01.280 with those various environments. Again, AWS Google Cloud, Microsoft Azure, or 177 08:01.280 --> 08:02.400 here in an NSX 178 08:02.400 --> 08:06.100 environment, there's also a cloud connector just for vSphere. So you can 179 08:06.100 --> 08:07.920 actually have a load balancer 180 08:07.920 --> 08:12.080 in vSphere that can interact with your standard industry, the switches inside 181 08:12.080 --> 08:12.960 of vSphere, 182 08:12.960 --> 08:17.420 even without NSX. So again, it's super flexible based on the concept of a cloud 183 08:17.420 --> 08:18.320 connector. 184 08:18.320 --> 08:21.440 So let's imagine one of these service engines is providing the data plane 185 08:21.440 --> 08:22.400 between the clients 186 08:22.400 --> 08:27.410 and these servers. Or another way of saying that is between these clients and 187 08:27.410 --> 08:28.800 these applications. 188 08:28.800 --> 08:32.320 Again, maybe it could be a web application or database application or DNS WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 188 08:28.800 --> 08:32.320 Again, maybe it could be a web application or database application or DNS 189 08:32.320 --> 08:33.760 application, etc. 190 08:33.760 --> 08:38.480 So a service engine would take the responsibility of that data plane. So one of 191 08:38.480 --> 08:39.200 these service engines 192 08:39.200 --> 08:43.200 or multiple service engines, depending on the load would be right here. So here 193 08:43.200 --> 08:44.800 is our service engine 194 08:44.800 --> 08:49.230 or SE for short. And what's exposed or available to the client is known as a 195 08:49.230 --> 08:50.320 virtual service. 196 08:50.320 --> 08:54.080 And associated with that virtual service would be an IP address, for example, 197 08:54.080 --> 08:54.880 that's reachable by 198 08:54.880 --> 08:58.730 the clients. And in combination with that IP address, there's going to be some 199 08:58.730 --> 08:59.440 profiles and 200 08:59.440 --> 09:03.770 details such as the ports involved. So that way when the client connects to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 200 08:59.440 --> 09:03.770 details such as the ports involved. So that way when the client connects to 201 09:03.770 --> 09:04.720 that IP address and to 202 09:04.720 --> 09:08.350 that respective set of ports, the service engine as part of the data plane for 203 09:08.350 --> 09:09.280 the advanced load 204 09:09.280 --> 09:13.350 balancer can then make its decisions about who to hand it off to. So also here 205 09:13.350 --> 09:13.920 in the service 206 09:13.920 --> 09:17.400 engine, we're going to have a pool or pools of resources, for example, these 207 09:17.400 --> 09:18.720 servers right here 208 09:18.720 --> 09:22.660 that we're not only aware of, but we can also do health checks against them. So 209 09:22.660 --> 09:23.360 if these three 210 09:23.360 --> 09:27.760 servers represent web services, we could in our health checks do a check to 211 09:27.760 --> 09:28.800 validate that the 212 09:28.800 --> 09:34.080 HTTP services up and running, for example, make a quick HTTP request and look WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 212 09:28.800 --> 09:34.080 HTTP services up and running, for example, make a quick HTTP request and look 213 09:34.080 --> 09:35.040 for a specific 214 09:35.040 --> 09:39.370 response in those requests to verify that they're up and able to serve up that 215 09:39.370 --> 09:40.640 application. So in 216 09:40.640 --> 09:44.460 the background, that's happening all the time. And that way the services engine 217 09:44.460 --> 09:45.600 knows exactly which 218 09:45.600 --> 09:49.670 of the servers in the pool are available when client requests come in so that 219 09:49.670 --> 09:50.320 the service's 220 09:50.320 --> 09:53.840 engine can proxy that request over to a server that is currently up and 221 09:53.840 --> 09:55.200 available. So once again, 222 09:55.200 --> 09:59.420 we have two sessions, one from the client to the virtual service, and then yet 223 09:59.420 --> 10:00.400 a second session WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 223 09:59.420 --> 10:00.400 a second session 224 10:00.400 --> 10:04.400 between the service engine and the server itself. So I put those in a slightly 225 10:04.400 --> 10:05.280 different color. So 226 10:05.280 --> 10:09.830 there is leg one of our journey. And here is leg two of our journey and the 227 10:09.830 --> 10:10.880 return path would go 228 10:10.880 --> 10:14.980 from the server back up to the services engine and then back out to the client. 229 10:14.980 --> 10:15.680 So here's what you 230 10:15.680 --> 10:18.270 and I get to do. This is super exciting. What we're going to do is put a plan 231 10:18.270 --> 10:19.120 together regarding 232 10:19.120 --> 10:23.030 what we want to implement regarding the advanced load balancer. And because 233 10:23.030 --> 10:23.920 this is part of a 234 10:23.920 --> 10:28.150 bigger NSX course, let's create the advanced load balancer will deploy the 235 10:28.150 --> 10:28.880 controller, 236 10:28.880 --> 10:32.630 and then we'll create a cloud connector that connects over to our NSX WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 236 10:28.880 --> 10:32.630 and then we'll create a cloud connector that connects over to our NSX 237 10:32.630 --> 10:34.240 environment. And that way 238 10:34.240 --> 10:38.770 you and I can actually implement the advanced load balancer as part of our NSX 239 10:38.770 --> 10:39.840 environment. 240 10:39.840 --> 10:49.840 [BLANK_AUDIO]