Hi, everyone, and welcome back.
Now, in today's video, we'll be discussing about different type of health checks that are available
in Ninex.
Now, at a high level overview, there are two primary health check types available.
First one is referred to as an active health check, which is only available in Nginx plus, which is
the paid version of Nginx.
And the second one is the passive health check, which is also available in the free open source version
of Nginx.
So first let's go ahead and discuss the basics of active health check.
So basically in active health check Nginx plus periodically checks the health of an upstream server
by sending a special health check request to each server and verifies its associated response.
For example, let's say that you have a nginx working as a load balancer.
This nginx will periodically, after a certain amount of seconds, will continuously send a get request
to the backend server and it will look into the type of response that it receives.
For example, if it receives a Http response in either 2XX or 3XX range, then it will consider the
server to be healthy.
If it does not really receive a response or it receives a response.
Apart from this specific range, then it considers the server to be unhealthy.
So this is referred to as an active health check.
The second one is the passive health check.
So in passive health check, Nginx monitors the communication between the client and the upstream server.
Now, if the upstream server is not responding or rejecting the connection, the passive health check
will consider the server to be unhealthy.
So let's understand this with a specific diagram.
So let's assume that you have two servers that are available and you have a Nginx that is distributing
the requests equally across both of these servers here.
Now let's assume that the server one due to some reason went down and there are five requests that are
sent at a Nginx level.
So now what Nginx will do the request A it will first send to server one.
Now this server one is down and this request will fail.
So now what nginx will do?
Nginx will now send the request to the server two where the request is successfully completed.
Similarly, now is the time for request.
B request b again goes to the server one and server one since it is not working as expected, this request
fails.
Now Nginx realizes that the request which it sent to the server one failed, so now it will go ahead
and send the same request to the server two.
Now at this stage Nginx knows that there is something wrong with server one because multiple requests
are failing.
So now what it will do, it will go ahead and block the connection to the server one altogether.
So now the next request may be c d, e it will go ahead and send to the running server, which is server
two altogether.
So this is referred to as a passive health check.
So let's go ahead and look into it.
Now, currently I'm logged in to the server, which basically is acting as a load balancer here.
Now if you quickly look into the Nginx configuration here, let's open up the load balancer dot conf
here you only have a upstream log and you have a server block here.
Now do note that even if you do not really specify any configuration related to health check, by default,
a passive health check will be up and running.
So you do not really need to have an additional configuration here.
So at this stage we have server zero one and server zero two where Nginx is running as expected.
So if I do a curl on localhost here, first request goes to server two, second request goes to server
one.
So at this stage we know things are working as expected.
So now let's do one thing in the server.
One let me go ahead and stop the Nginx here.
All right.
Now whenever we go ahead and we'll make a curl request, this curl request will always go to server
two.
However, before the request goes to server two, Nginx will also send the request to server one in
case.
If Nginx does not get a successful response then it will send the same request to server two.
So let's go ahead and look into how we can see this in practical as well.
So within server one, let's go ahead and quickly install Tcpdump which will allow us to monitor the
network traffic of the server.
All right.
Now, if I quickly do an ifconfig here, there are two interfaces here.
First, interface has a public IP.
Second interface has a private IP.
Now, if you'll quickly look into the load balancer, if the traffic is sent to the private IP.
So we basically need to monitor this specific interface, basically the interface where the traffic
is being sent to.
So the interface in this case is Eth1.
So let's do a TCP dump with the eye of Eth1 and I'll say I want to monitor Port 80.
All right.
So at this stage you do not really have any traffic that is coming.
So now let's do a curl on localhost here.
So the request went to server two.
Let's verify if the request came to server one or not.
And at this stage the request did not really came to server one.
Let's do a curl again.
Again, the request went to server two.
So now at this stage you will see Nginx load Balancer has first sent his request to server one.
So this is the request that was sent over here.
Now, since this request was not successful in terms of response, Enginex sent the same request to
the server two and the response came from the server two over here.
So this is what is referred to as a passive health check, where the live request of the user is sent
to the servers and then depending upon the response, the server is considered to be failed or successful.
All right.
So this is the passive health check in active health check.
The live requests are not really sent.
Instead, Nginx will periodically send a get request to the upstream servers and it will look into the
response.
If the response is successful, it will consider the server to be up.
If the response is failed, it will consider the server to be down.
So this is a very high level overview about the health check types in Nginx.