WEBVTT 00:00.230 --> 00:01.660 Hi, everyone, and welcome back. 00:01.670 --> 00:06.380 Now, in today's video, we'll be discussing about some of the important parameters for passive health 00:06.380 --> 00:11.630 check that allows us to achieve a certain degree of customization based on our use case. 00:11.630 --> 00:17.000 Now, in the video associated with a passive health checks, we were discussing on how enginex once 00:17.000 --> 00:23.390 it determines that the previous few requests have failed on the server one it can completely block the 00:23.390 --> 00:29.300 connection to the server one so no new requests can go to the server one and it will start sending all 00:29.300 --> 00:30.590 the new requests to the server. 00:30.590 --> 00:30.770 Two. 00:30.800 --> 00:38.930 So this specific configuration and how we can change the interval as well as the values associated with 00:38.930 --> 00:43.520 the failed requests is something that we'll be looking practically in today's video. 00:43.520 --> 00:49.430 Now, in order to customize this entire process, there are two important configuration parameters that 00:49.430 --> 00:50.360 we need to use. 00:50.360 --> 00:54.320 First one is Max Fields and second one is fail timeout. 00:54.350 --> 00:59.630 Now, before we discuss about it, let me quickly show you how exactly it looks in the configuration 00:59.630 --> 01:00.270 file. 01:00.270 --> 01:02.100 So this is how exactly it looks. 01:02.100 --> 01:08.190 So all you have to do along with the IP address of the server, you'll have to specify max field parameter 01:08.190 --> 01:10.050 and the field timeout parameter. 01:10.050 --> 01:12.660 So let's look into what exactly these two are. 01:12.690 --> 01:18.450 So the max field basically sets the number of failed attempts that must occur during the failed timeout 01:18.450 --> 01:21.480 period for the server to be marked unavailable. 01:21.480 --> 01:27.420 So that basically means if you see the failed timeout is 30s and the max fails is two. 01:27.450 --> 01:35.670 So if there are two attempts that are failed in this 30s, then this specific server will be blocked. 01:35.670 --> 01:41.490 All right, So block basically means that it will be marked as unavailable, so no new requests will 01:41.520 --> 01:43.140 be sent to this server. 01:43.140 --> 01:45.060 And the second one is fail timeout. 01:45.090 --> 01:50.430 It basically sets the time during which the number of failed attempts must happen for the server to 01:50.430 --> 01:51.570 be marked unavailable. 01:51.570 --> 01:56.670 So this is very similar to the first pointer that we were discussing and also the time for which the 01:56.670 --> 01:58.590 server will be marked as unavailable. 01:58.590 --> 02:05.880 So if to number of failed requests have been sent, then the server will be marked available for 30s. 02:05.880 --> 02:10.650 So no new requests will be sent to this specific server for next 30s. 02:10.650 --> 02:13.110 So this is what these two parameters are. 02:13.140 --> 02:19.200 Now, depending upon your requirement and your use case, you can go ahead and customize this depending 02:19.200 --> 02:19.830 on your needs. 02:19.830 --> 02:21.510 Maybe you can set 30s. 02:21.510 --> 02:23.250 Maybe you can set 60s. 02:23.250 --> 02:26.760 Maybe you can set five minutes, ten minutes, one hour, etcetera. 02:26.760 --> 02:29.640 So let's go ahead and look into it practically. 02:29.640 --> 02:33.960 So currently I'm logged into the server where Nginx is acting as a load balancer. 02:33.960 --> 02:37.380 So let's quickly go to Etsy, Nginx, Conf.d. 02:37.410 --> 02:40.050 We have one file of load balancer dot conf. 02:40.050 --> 02:46.980 Let's quickly open this up and within here, let's say Max Fields is equal to two and I'll say fail 02:47.010 --> 02:51.080 timeout is equal to, let's say 60s. 02:51.090 --> 02:55.320 Similarly, let's also go ahead and use the same parameters here. 02:55.320 --> 02:58.080 I'll copy this up and let me paste it. 02:58.080 --> 03:00.540 Let's also set the indentation correctly. 03:00.540 --> 03:01.820 Perfect. 03:01.820 --> 03:07.430 Now to verify if things are working as expected, let's do nginx hyphen T, so configuration syntax 03:07.430 --> 03:08.450 is successful. 03:08.540 --> 03:11.600 I'll go ahead and do a systemctl restart nginx. 03:11.600 --> 03:13.760 Here now for today's video. 03:13.760 --> 03:19.550 In order to test things out properly, what we'll be doing, we'll be installing a tool called as AB. 03:19.640 --> 03:22.070 So AB by default is not available. 03:22.070 --> 03:28.790 So let's go ahead and install the httpd tools from which the AB comes from. 03:30.260 --> 03:30.590 All right. 03:30.590 --> 03:36.320 So Abe is one of the great utilities which you can use for a wide variety of use cases, including load 03:36.350 --> 03:36.710 testing. 03:36.710 --> 03:42.860 So you can send thousands of requests to your Web server to see how well the web server behaves and 03:42.860 --> 03:43.340 so on. 03:43.340 --> 03:48.350 So if I just type Abe, you see we are getting the basic health details. 03:48.350 --> 03:49.820 So now let's do one thing. 03:49.820 --> 03:51.770 So currently I'm logged into server one. 03:51.770 --> 03:52.910 Let's quickly do one thing. 03:52.910 --> 03:58.670 I'll say systemctl status enginex and the Nginx is currently in the stopped state. 03:58.670 --> 04:00.290 We do not really want it to run. 04:00.290 --> 04:04.580 For today's demo I'll press Q to exit and let's do one thing. 04:04.580 --> 04:09.080 Let's do a TCP dump i eth1 followed by the port of 80. 04:09.080 --> 04:14.030 Now again, if you're using a different service provider like AWS, et cetera, the interface might 04:14.030 --> 04:16.610 change, so you'll have to modify things accordingly. 04:17.210 --> 04:20.120 All right, so this is the Tcpdump command. 04:20.120 --> 04:25.520 So going back to the load balancer server, let's run a B, the number of requests is 500. 04:25.520 --> 04:26.780 And where do we want? 04:26.810 --> 04:30.150 We want to send it to the load balancer host itself. 04:30.150 --> 04:31.350 So I'll run this. 04:31.350 --> 04:38.640 So if you'll quickly see, in total there are 500 requests which were sent and these are all the details 04:38.640 --> 04:39.810 associated with it. 04:39.810 --> 04:44.370 Now at this stage, you'll also see that some of the requests were sent to the server one. 04:44.400 --> 04:50.610 However, now we know that all of these requests would have failed and Nginx will not really send any 04:50.610 --> 04:52.890 new requests for next 60s. 04:52.890 --> 04:56.160 So now let's go ahead and run a B again. 04:56.160 --> 04:58.740 We'll send new 500 requests. 04:58.770 --> 05:05.460 All the 500 requests are sent and here you'll see not even a single request came to the server one. 05:05.460 --> 05:07.050 Let's try once more. 05:07.050 --> 05:11.100 Let's go ahead and run 1000 requests this time. 05:11.970 --> 05:12.600 All right. 05:12.600 --> 05:19.650 And here you see, not even a single request came to the server one, primarily because we have a configuration 05:19.650 --> 05:22.300 of failed timeout associated here. 05:22.320 --> 05:26.100 Now, depending upon the failed timeout, you can configure things accordingly. 05:26.100 --> 05:33.030 60s one hour, 15 minutes, 30 minutes, etcetera based upon your application and your environment. 05:33.060 --> 05:39.630 However, this is the basics on how you can go ahead and modify the passive health check to suit your 05:39.630 --> 05:40.920 environment needs. 05:40.920 --> 05:43.230 And with this, we'll conclude today's video.