WEBVTT 00:00.170 --> 00:01.750 Hi, everyone, and welcome back. 00:01.760 --> 00:05.810 Now, in today's video, we will be discussing about the load balancer health. 00:05.810 --> 00:07.790 Checking now at a high level overview. 00:07.820 --> 00:14.030 Health checks are used to monitor the health of a Http servers that are part of the Nginx upstream group. 00:14.030 --> 00:16.400 So let us quickly understand this with a diagram. 00:16.400 --> 00:20.000 So let's assume that you have a load balancer and there are two servers. 00:20.000 --> 00:25.370 So since there are two servers, 50% of the traffic will go to server one, 50% of the traffic will 00:25.370 --> 00:26.330 go to server two. 00:26.330 --> 00:31.280 Now, due to some reason, let's assume that the server one went down altogether. 00:31.280 --> 00:36.890 Now if the load balancer continues to send the traffic to the server one, then all of those requests 00:36.890 --> 00:37.640 will fail. 00:37.640 --> 00:40.280 And this is something that you do not really want. 00:40.280 --> 00:43.220 So what load Balancer does using health checks? 00:43.220 --> 00:46.940 It can determine whether the server is responding correctly or not. 00:46.940 --> 00:53.060 If it is not responding correctly, then this 50% of the traffic that was going to server one, this 00:53.060 --> 00:57.920 traffic will be blocked and instead 100% of the traffic will go to the server two. 00:57.950 --> 01:04.290 So this ensures that even if one server goes down, the healthy server is serving all of the production 01:04.290 --> 01:04.890 traffic. 01:04.890 --> 01:09.600 So this capability of a load balancer is referred to as a health checking. 01:09.600 --> 01:10.650 So let's do one thing. 01:10.650 --> 01:14.490 Let's go ahead and have a quick demo so that we understand it in a better way. 01:14.490 --> 01:20.580 So for today's video, again, we have two servers similar to the diagram that we have, and we have 01:20.580 --> 01:26.700 an additional component of a load balancer that will distribute the request across both of these instances. 01:26.700 --> 01:30.600 So similar to our setup within my terminal, I have three tabs available. 01:30.600 --> 01:35.700 First one for load balancer server, second one for server zero and third one for server zero two. 01:35.700 --> 01:39.660 So if you want to quickly verify if I do a curl on localhost. 01:39.660 --> 01:44.880 So this is basically the load balancer server first request is going to server two, second request 01:44.880 --> 01:45.870 is going to server one. 01:45.870 --> 01:50.370 So it is distributing the traffic across multiple instances equally. 01:50.370 --> 01:54.450 So now let's do one thing, let's go ahead and stop the server one. 01:54.450 --> 01:59.460 So within the server one, I'll go ahead and stop the Nginx process altogether. 01:59.820 --> 02:00.480 All right. 02:00.510 --> 02:06.000 Now, once the Nginx process is stopped, let's quickly do a ifconfig to verify the IP address. 02:06.000 --> 02:07.890 So this is the IP address here. 02:07.890 --> 02:08.850 Let's copy this up. 02:09.420 --> 02:15.210 And from the load balancer IP, if I'll do a curl on this IP address immediately, you see it states 02:15.210 --> 02:16.440 connection refused. 02:16.440 --> 02:18.150 So this is as expected. 02:18.180 --> 02:21.030 Now how will load Balancer behave now. 02:21.030 --> 02:22.470 So let's try it out. 02:22.500 --> 02:26.070 So I'll do a curl on localhost this time. 02:26.070 --> 02:27.750 The request went to server two. 02:28.290 --> 02:29.610 Let's do a curl again. 02:29.940 --> 02:31.830 Again request went to server two. 02:31.830 --> 02:33.090 Let's do a curl again. 02:33.090 --> 02:35.040 Again request went to server two. 02:35.040 --> 02:41.190 So even though one of the server is completely down, our production traffic is not really affected. 02:41.190 --> 02:45.300 Similarly, if you want to see it from the browser, let's try it out from a new tab. 02:45.300 --> 02:47.940 Let's copy the IP address of the load balancer. 02:47.940 --> 02:49.800 The request is going to server two. 02:50.340 --> 02:51.720 Let's refresh again. 02:51.720 --> 02:55.350 Server two again, server two again, server two and again server two. 02:55.350 --> 03:00.750 So now even though one server is down similar to the diagram, the production traffic does not really 03:00.750 --> 03:01.830 get affected here. 03:01.830 --> 03:07.080 So I hope with this you understood the basic capability of what health checks allows us to do. 03:07.110 --> 03:13.170 Now, also, one more important part to remember is that in case if the server one comes back online, 03:13.170 --> 03:14.670 then what will happen again? 03:14.670 --> 03:19.950 Load Balancer will go ahead and distribute 5,050% of the traffic to both of these instances. 03:19.950 --> 03:21.540 So let me also show you. 03:21.540 --> 03:29.850 So let's go ahead and start the Nginx again within the server zero one and now let's do a curl localhost 03:31.650 --> 03:33.330 request goes to server two. 03:33.720 --> 03:36.270 Now you see the second request went to server one. 03:36.270 --> 03:41.100 So again, now the load balancer is distributing the traffic across both of these instances. 03:41.130 --> 03:41.640 Great. 03:41.640 --> 03:47.550 So I hope with this you understood the basics of what health checks in Nginx allows us to do so. 03:47.550 --> 03:49.440 With this, we'll conclude today's video.