WEBVTT 00:00.140 --> 00:01.660 Hi, everyone, and welcome back. 00:01.670 --> 00:06.470 Now, in today's video, we'll be discussing about different type of health checks that are available 00:06.470 --> 00:07.490 in Ninex. 00:07.490 --> 00:11.120 Now, at a high level overview, there are two primary health check types available. 00:11.120 --> 00:16.220 First one is referred to as an active health check, which is only available in Nginx plus, which is 00:16.220 --> 00:17.780 the paid version of Nginx. 00:17.780 --> 00:22.670 And the second one is the passive health check, which is also available in the free open source version 00:22.700 --> 00:23.360 of Nginx. 00:23.360 --> 00:26.990 So first let's go ahead and discuss the basics of active health check. 00:26.990 --> 00:32.810 So basically in active health check Nginx plus periodically checks the health of an upstream server 00:32.810 --> 00:38.210 by sending a special health check request to each server and verifies its associated response. 00:38.210 --> 00:41.900 For example, let's say that you have a nginx working as a load balancer. 00:41.930 --> 00:48.200 This nginx will periodically, after a certain amount of seconds, will continuously send a get request 00:48.200 --> 00:53.300 to the backend server and it will look into the type of response that it receives. 00:53.300 --> 01:00.090 For example, if it receives a Http response in either 2XX or 3XX range, then it will consider the 01:00.090 --> 01:01.080 server to be healthy. 01:01.080 --> 01:05.500 If it does not really receive a response or it receives a response. 01:05.520 --> 01:09.870 Apart from this specific range, then it considers the server to be unhealthy. 01:09.870 --> 01:12.390 So this is referred to as an active health check. 01:12.420 --> 01:14.640 The second one is the passive health check. 01:14.640 --> 01:20.130 So in passive health check, Nginx monitors the communication between the client and the upstream server. 01:20.130 --> 01:25.140 Now, if the upstream server is not responding or rejecting the connection, the passive health check 01:25.140 --> 01:27.170 will consider the server to be unhealthy. 01:27.180 --> 01:29.910 So let's understand this with a specific diagram. 01:29.910 --> 01:35.760 So let's assume that you have two servers that are available and you have a Nginx that is distributing 01:35.760 --> 01:39.000 the requests equally across both of these servers here. 01:39.030 --> 01:45.210 Now let's assume that the server one due to some reason went down and there are five requests that are 01:45.210 --> 01:46.830 sent at a Nginx level. 01:46.830 --> 01:52.110 So now what Nginx will do the request A it will first send to server one. 01:52.110 --> 01:56.310 Now this server one is down and this request will fail. 01:56.310 --> 01:58.110 So now what nginx will do? 01:58.110 --> 02:03.930 Nginx will now send the request to the server two where the request is successfully completed. 02:03.930 --> 02:06.690 Similarly, now is the time for request. 02:06.720 --> 02:13.800 B request b again goes to the server one and server one since it is not working as expected, this request 02:13.800 --> 02:14.700 fails. 02:14.790 --> 02:21.060 Now Nginx realizes that the request which it sent to the server one failed, so now it will go ahead 02:21.060 --> 02:23.130 and send the same request to the server two. 02:23.130 --> 02:29.280 Now at this stage Nginx knows that there is something wrong with server one because multiple requests 02:29.280 --> 02:29.880 are failing. 02:29.880 --> 02:34.590 So now what it will do, it will go ahead and block the connection to the server one altogether. 02:34.590 --> 02:41.250 So now the next request may be c d, e it will go ahead and send to the running server, which is server 02:41.250 --> 02:42.330 two altogether. 02:42.330 --> 02:45.210 So this is referred to as a passive health check. 02:45.210 --> 02:47.280 So let's go ahead and look into it. 02:47.310 --> 02:51.990 Now, currently I'm logged in to the server, which basically is acting as a load balancer here. 02:52.020 --> 02:58.080 Now if you quickly look into the Nginx configuration here, let's open up the load balancer dot conf 02:58.110 --> 03:02.370 here you only have a upstream log and you have a server block here. 03:02.370 --> 03:08.520 Now do note that even if you do not really specify any configuration related to health check, by default, 03:08.520 --> 03:10.950 a passive health check will be up and running. 03:10.950 --> 03:14.370 So you do not really need to have an additional configuration here. 03:14.370 --> 03:20.340 So at this stage we have server zero one and server zero two where Nginx is running as expected. 03:20.340 --> 03:26.880 So if I do a curl on localhost here, first request goes to server two, second request goes to server 03:26.880 --> 03:27.090 one. 03:27.090 --> 03:29.940 So at this stage we know things are working as expected. 03:29.940 --> 03:32.100 So now let's do one thing in the server. 03:32.100 --> 03:35.430 One let me go ahead and stop the Nginx here. 03:35.850 --> 03:36.570 All right. 03:36.750 --> 03:43.740 Now whenever we go ahead and we'll make a curl request, this curl request will always go to server 03:43.740 --> 03:44.130 two. 03:44.160 --> 03:50.430 However, before the request goes to server two, Nginx will also send the request to server one in 03:50.430 --> 03:50.760 case. 03:50.760 --> 03:56.220 If Nginx does not get a successful response then it will send the same request to server two. 03:56.250 --> 04:00.780 So let's go ahead and look into how we can see this in practical as well. 04:00.780 --> 04:07.110 So within server one, let's go ahead and quickly install Tcpdump which will allow us to monitor the 04:07.110 --> 04:09.120 network traffic of the server. 04:10.510 --> 04:10.900 All right. 04:11.050 --> 04:15.010 Now, if I quickly do an ifconfig here, there are two interfaces here. 04:15.040 --> 04:17.170 First, interface has a public IP. 04:17.200 --> 04:19.030 Second interface has a private IP. 04:19.480 --> 04:25.900 Now, if you'll quickly look into the load balancer, if the traffic is sent to the private IP. 04:25.900 --> 04:31.900 So we basically need to monitor this specific interface, basically the interface where the traffic 04:31.900 --> 04:33.050 is being sent to. 04:33.070 --> 04:36.610 So the interface in this case is Eth1. 04:36.610 --> 04:43.330 So let's do a TCP dump with the eye of Eth1 and I'll say I want to monitor Port 80. 04:43.630 --> 04:44.020 All right. 04:44.020 --> 04:47.320 So at this stage you do not really have any traffic that is coming. 04:47.620 --> 04:50.530 So now let's do a curl on localhost here. 04:51.280 --> 04:53.540 So the request went to server two. 04:53.560 --> 04:56.710 Let's verify if the request came to server one or not. 04:56.710 --> 04:59.980 And at this stage the request did not really came to server one. 05:00.010 --> 05:01.930 Let's do a curl again. 05:02.080 --> 05:04.270 Again, the request went to server two. 05:04.810 --> 05:10.940 So now at this stage you will see Nginx load Balancer has first sent his request to server one. 05:10.940 --> 05:13.700 So this is the request that was sent over here. 05:13.730 --> 05:20.690 Now, since this request was not successful in terms of response, Enginex sent the same request to 05:20.690 --> 05:25.070 the server two and the response came from the server two over here. 05:25.100 --> 05:31.670 So this is what is referred to as a passive health check, where the live request of the user is sent 05:31.670 --> 05:38.000 to the servers and then depending upon the response, the server is considered to be failed or successful. 05:38.030 --> 05:38.480 All right. 05:38.480 --> 05:41.610 So this is the passive health check in active health check. 05:41.630 --> 05:44.260 The live requests are not really sent. 05:44.270 --> 05:50.750 Instead, Nginx will periodically send a get request to the upstream servers and it will look into the 05:50.750 --> 05:51.330 response. 05:51.350 --> 05:54.750 If the response is successful, it will consider the server to be up. 05:54.770 --> 05:58.010 If the response is failed, it will consider the server to be down. 05:58.010 --> 06:02.150 So this is a very high level overview about the health check types in Nginx.