WEBVTT 00:05.890 --> 00:12.450 In this lesson we'll see how engine X makes it easy to configure a simple yet robust load balancer. 00:12.460 --> 00:16.580 Now first off let's understand what exactly a load balancer is. 00:16.660 --> 00:20.420 In short a load balances should achieve two main objectives. 00:20.530 --> 00:26.680 One the ability to distribute requests to multiple servers thus reducing the load on those individual 00:26.680 --> 00:33.790 servers and secondly to provide redundancy meaning when one or more of our load balanced servers fail 00:33.820 --> 00:36.580 for whichever reason the load balance in each. 00:36.580 --> 00:43.270 To recognize that and redirect requests to any of the remaining available servers. 00:43.360 --> 00:47.590 When I say distribute or redirect of course I mean proxy. 00:47.590 --> 00:54.760 So again using engine X as a reverse proxy and in doing so keeping the load balancing itself as transparent 00:54.760 --> 00:56.320 as possible. 00:56.380 --> 01:01.960 Taking this into account the first requirement for us to test this then is going to be having multiple 01:01.960 --> 01:06.380 servers to load balance using away in jinich server or load balancer. 01:06.650 --> 01:07.270 Do this. 01:07.270 --> 01:14.170 Are you some BHP servers again and this time I'll simply have them each return and identifying plain 01:14.200 --> 01:18.480 text message so I'll create these response files. 01:18.610 --> 01:26.880 Echo P HP server 1 being our first pitch to server right there to a file called a swan. 01:26.920 --> 01:28.920 No need for an extension here. 01:29.020 --> 01:32.880 Page P server doesn't care about the input file type. 01:32.890 --> 01:40.080 Another call server to s to server 3 file name. 01:40.150 --> 01:41.950 S 3. 01:41.980 --> 01:48.370 I list the contents of this directory where we see those files and when we check the contents of this 01:48.370 --> 01:52.010 one we see that string BHP serve one. 01:52.390 --> 01:55.130 So start the first pitch B server here. 01:55.180 --> 02:01.250 P S Flag local host and this time or have a listen on port. 02:01.270 --> 02:05.200 Ten thousand and one only to have it matched the server name. 02:05.200 --> 02:10.200 Were returning I'll create another terminal window and start the second server. 02:13.190 --> 02:13.570 Or. 02:13.610 --> 02:15.690 Ten thousand two this time. 02:15.810 --> 02:17.760 Worth the is to file. 02:20.490 --> 02:22.830 And finally our third server on port. 02:22.830 --> 02:25.620 Ten thousand three with this three. 02:28.250 --> 02:29.810 Test the first one. 02:32.240 --> 02:39.170 Works second serve on board ten thousand two works and the third. 02:39.170 --> 02:45.710 The HP server 3 so that works right we now have three servers running and we can easily identify which 02:45.710 --> 02:48.880 one have been proxy to by those responses. 02:48.980 --> 02:54.620 Of course in a real world example these servers would much more likely be serving the exact same data 02:55.010 --> 03:00.970 given the same requests but will have to distinguish them in order to test our load balancer. 03:01.010 --> 03:08.160 I'll start fresh by creating a new engine configuration file called this one load balancer dot com. 03:09.100 --> 03:13.530 Open that new file in the editor and start with an event block. 03:14.660 --> 03:16.200 H T T B. 03:18.480 --> 03:21.340 Listening on 8 8 8 8 again. 03:21.930 --> 03:23.730 And a root location block. 03:23.970 --> 03:29.100 There's load balancers simply accepting everything and prok seeing it in before setting up our load 03:29.100 --> 03:31.910 balancing worth with 3 HP servers. 03:31.920 --> 03:34.010 Let's test this with one of them. 03:34.080 --> 03:39.510 I'll use that first one so local host port 10000 and 1. 03:40.360 --> 03:41.920 Save and start. 03:41.920 --> 03:46.020 Engine X with the absolute path to that load balancer configuration file. 03:48.650 --> 03:50.620 Carlo engine X server. 03:54.820 --> 04:00.820 And we get the response from BHP serve a one as I expect it right now to monitor the load balancing 04:00.850 --> 04:06.670 I'm going to issue these cold commands to the engineer server using a simple while loop on the command 04:06.670 --> 04:12.100 line bearse will just allow us to monitor subsequent requests without having to run them individually 04:12.850 --> 04:24.940 say while sleep or zero point five or half a second do kearl HTC be local host a date a date. 04:25.540 --> 04:26.410 Done. 04:26.860 --> 04:33.190 So basically we are creating a loop which sleeps for half a second on every iteration and then performs 04:33.220 --> 04:36.040 the call command on our engine X load balancer. 04:36.100 --> 04:39.460 Feel free to run these manually or in any other way you prefer. 04:39.460 --> 04:41.590 This is just a quick way using what we have. 04:41.590 --> 04:48.520 Yeah I'll run that and we get that page piece server one response every half a second as we only proxy's 04:48.550 --> 04:50.710 to that first server at the moment. 04:50.710 --> 04:53.090 Let's implement the actual load balancing now. 04:53.260 --> 04:56.210 First we have to create what's called an upstream. 04:56.410 --> 05:02.800 This is a context or block in engine X that group several servers with the ability to add some options 05:02.830 --> 05:04.210 to the Upstream. 05:04.210 --> 05:09.200 Think of it as a named collection of servers that share somewhere the commonality. 05:09.400 --> 05:12.540 In most cases being that they serve the same content. 05:12.580 --> 05:18.820 This gets defined in our HTP context by saying upstream give it a name. 05:19.030 --> 05:26.320 I'll call this one patch P underscore servers and inside this block defined the individual servers by 05:26.320 --> 05:31.390 saying server with the value being the host name and port of the server. 05:31.390 --> 05:39.480 Like so the remaining to be HP servers 10 thousand to ten thousand three. 05:39.790 --> 05:45.860 And now to proxy this locations requests to the Upstream say proxy pass. 05:45.910 --> 05:48.880 So a standard reverse proxy directive. 05:49.060 --> 05:58.400 GDP p s p underscore servers that upstream pointing to our BHP service reload the configuration file. 05:59.270 --> 06:06.350 Run that loop again curling our engine next load balancer and this time we see a near perfectly distributed 06:06.350 --> 06:09.630 sequence of responses from our BHB service. 06:09.680 --> 06:15.240 So engine X is balancing our requests by sending them to each page piece server in turn. 06:16.000 --> 06:19.260 This default behaviour is referred to as round robin. 06:19.330 --> 06:23.780 Meaning to simply send the next request to the next server in the upstream. 06:23.810 --> 06:29.920 We had a slight variance here for whichever reason but when I slow this down to one second per request 06:29.980 --> 06:33.300 we see a perfect round drop and distribution of course. 06:33.310 --> 06:37.240 The second purpose of a low balances is to provide us with some redundancy. 06:37.300 --> 06:42.930 We can test this by killing one or two of our p p servers whilst the requests are going out. 06:43.180 --> 06:45.540 I'll clear this to make some space. 06:45.880 --> 06:48.150 Start again with one second. 06:49.310 --> 06:50.900 Kill server one. 06:52.320 --> 07:00.630 We see requests continue seamlessly with server 2 and 3 and when I kill server 2 also we see only server 07:00.630 --> 07:01.890 3 responding. 07:05.330 --> 07:07.210 Start server to back up. 07:13.620 --> 07:15.530 It returns in the requests. 07:17.080 --> 07:18.990 And server 1. 07:20.650 --> 07:26.020 And we're back to an even distribution of requests between all three of our upstream servers. 07:26.470 --> 07:33.170 So again an easy robust load balancer in only a few lines of configuration code in the next lesson will 07:33.190 --> 07:36.590 take a look at some different variants of load balancing.