Nginx Load Balancing Health Testing: A Comprehensive Guide

Nginx Load Balancing Health Testing: A Comprehensive Guide

In the realm of Nginx load balancing, ensuring that every application server is operational is crucial for a seamless user experience. However, it’s not always possible to guarantee that every server is functioning normally. Fortunately, Nginx provides two methods to detect and address non-functional application servers: passive monitoring and active monitoring.

Passive Monitoring

Passive monitoring involves setting Nginx to detect application servers that cannot be accessed. When an application server is deemed inaccessible, Nginx temporarily stops distributing requests to it until it’s deemed operational again. This approach requires two key parameters: fail_timeout and max_fails.

fail_timeout

fail_timeout indicates the time period during which Nginx will stop distributing requests to an application server after it’s deemed inaccessible. This parameter is crucial in determining how long Nginx will wait for the server to become operational again.

max_fails

max_fails sets the maximum number of failed access attempts before Nginx considers an application server inaccessible. When the number of failed attempts reaches this threshold, Nginx will stop distributing requests to the server until it’s deemed operational again.

Example 1

http {
    upstream onmpw {
        server 192.168.144.128;
        server 192.168.144.132 max_fails = 3 fail_timeout = 30s;
        server 192.168.144.131 max_fails = 2;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://onmpw;
        }
    }
}

In this example, the fail_timeout and max_fails values are set to 30s and 3, respectively, for the application server at 192.168.144.132. If the number of failed access attempts reaches 3, Nginx will stop distributing requests to this server for 30s.

Active Monitoring

Active monitoring involves periodically sending special requests to each application server to monitor its accessibility. This approach is called active surveillance and is only available in the commercial version of Nginx.

Example 2

http {
    upstream onmpw {
        zone onmpw 64k;
        server 192.168.144.128;
        server 192.168.144.132;
        server 192.168.144.131;
    }
    server {
        listen 80;
        location / {
            proxy_pass http://onmpw;
            health_check;
        }
    }
}

In this example, a group of application servers is defined, and a health check is performed every 5s to ensure that each server is operational. If any server fails the health check, it’s considered unstable, and Nginx will stop distributing requests to it.

Health Check Configuration

The health check configuration can be customized using the health_check directive. This directive allows you to specify the interval between health checks, the number of failed checks, and the number of successful checks required before a server is considered operational.

Example 3

location / {
    proxy_pass http://onmpw;
    health_check interval = 10 fails = 3 passes = 2;
}

In this example, the health check interval is set to 10s, and the number of failed checks is set to 3. If the server fails 3 health checks, it’s considered inaccessible. The number of successful checks required before a server is considered operational is set to 2.

Customizing the Health Check URL

The health check URL can be customized using the uri parameter.

Example 4

location / {
    proxy_pass http://onmpw;
    health_check uri = /some/path;
}

In this example, the health check URL is set to /some/path, and the health check is performed on this URL.

In conclusion, Nginx load balancing health testing is a crucial aspect of ensuring a seamless user experience. By understanding and configuring passive and active monitoring, you can ensure that your application servers are operational and provide a high-quality user experience.