Hi, everyone, and welcome back.
Now, in today's video, we'll be discussing about some of the important parameters for passive health
check that allows us to achieve a certain degree of customization based on our use case.
Now, in the video associated with a passive health checks, we were discussing on how enginex once
it determines that the previous few requests have failed on the server one it can completely block the
connection to the server one so no new requests can go to the server one and it will start sending all
the new requests to the server.
Two.
So this specific configuration and how we can change the interval as well as the values associated with
the failed requests is something that we'll be looking practically in today's video.
Now, in order to customize this entire process, there are two important configuration parameters that
we need to use.
First one is Max Fields and second one is fail timeout.
Now, before we discuss about it, let me quickly show you how exactly it looks in the configuration
file.
So this is how exactly it looks.
So all you have to do along with the IP address of the server, you'll have to specify max field parameter
and the field timeout parameter.
So let's look into what exactly these two are.
So the max field basically sets the number of failed attempts that must occur during the failed timeout
period for the server to be marked unavailable.
So that basically means if you see the failed timeout is 30s and the max fails is two.
So if there are two attempts that are failed in this 30s, then this specific server will be blocked.
All right, So block basically means that it will be marked as unavailable, so no new requests will
be sent to this server.
And the second one is fail timeout.
It basically sets the time during which the number of failed attempts must happen for the server to
be marked unavailable.
So this is very similar to the first pointer that we were discussing and also the time for which the
server will be marked as unavailable.
So if to number of failed requests have been sent, then the server will be marked available for 30s.
So no new requests will be sent to this specific server for next 30s.
So this is what these two parameters are.
Now, depending upon your requirement and your use case, you can go ahead and customize this depending
on your needs.
Maybe you can set 30s.
Maybe you can set 60s.
Maybe you can set five minutes, ten minutes, one hour, etcetera.
So let's go ahead and look into it practically.
So currently I'm logged into the server where Nginx is acting as a load balancer.
So let's quickly go to Etsy, Nginx, Conf.d.
We have one file of load balancer dot conf.
Let's quickly open this up and within here, let's say Max Fields is equal to two and I'll say fail
timeout is equal to, let's say 60s.
Similarly, let's also go ahead and use the same parameters here.
I'll copy this up and let me paste it.
Let's also set the indentation correctly.
Perfect.
Now to verify if things are working as expected, let's do nginx hyphen T, so configuration syntax
is successful.
I'll go ahead and do a systemctl restart nginx.
Here now for today's video.
In order to test things out properly, what we'll be doing, we'll be installing a tool called as AB.
So AB by default is not available.
So let's go ahead and install the httpd tools from which the AB comes from.
All right.
So Abe is one of the great utilities which you can use for a wide variety of use cases, including load
testing.
So you can send thousands of requests to your Web server to see how well the web server behaves and
so on.
So if I just type Abe, you see we are getting the basic health details.
So now let's do one thing.
So currently I'm logged into server one.
Let's quickly do one thing.
I'll say systemctl status enginex and the Nginx is currently in the stopped state.
We do not really want it to run.
For today's demo I'll press Q to exit and let's do one thing.
Let's do a TCP dump i eth1 followed by the port of 80.
Now again, if you're using a different service provider like AWS, et cetera, the interface might
change, so you'll have to modify things accordingly.
All right, so this is the Tcpdump command.
So going back to the load balancer server, let's run a B, the number of requests is 500.
And where do we want?
We want to send it to the load balancer host itself.
So I'll run this.
So if you'll quickly see, in total there are 500 requests which were sent and these are all the details
associated with it.
Now at this stage, you'll also see that some of the requests were sent to the server one.
However, now we know that all of these requests would have failed and Nginx will not really send any
new requests for next 60s.
So now let's go ahead and run a B again.
We'll send new 500 requests.
All the 500 requests are sent and here you'll see not even a single request came to the server one.
Let's try once more.
Let's go ahead and run 1000 requests this time.
All right.
And here you see, not even a single request came to the server one, primarily because we have a configuration
of failed timeout associated here.
Now, depending upon the failed timeout, you can configure things accordingly.
60s one hour, 15 minutes, 30 minutes, etcetera based upon your application and your environment.
However, this is the basics on how you can go ahead and modify the passive health check to suit your
environment needs.
And with this, we'll conclude today's video.