Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the method of Nginx backend health check", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let Xiaobian take you to learn "What is the method of Nginx back-end health check"!

Strictly speaking, Nginx doesn't have its own health check function for Load Balancer backend nodes, but it can automatically switch to healthy nodes when backend nodes fail through the relevant instructions in the default ngx_http_proxy_module and ngx_http_upstream_module.

0x01: ngx_http_proxy_module module

proxy_connect_timeout directive

Language: proxy_connect_timeout time;

Default: proxy_connect_timeout 60s;

Context: http, server, location

The function of this directive is to set the timeout for establishing a connection to the backend server. It should be noted that timeouts generally cannot be greater than 75 seconds.

proxy_read_timeout directive

Language: proxy_read_timeout time;

Default: proxy_read_timeout 60s;

Context: http, server, location

Defines the timeout for reading responses from the backend server. This timeout refers to the maximum time interval between two consecutive read operations, not the maximum time for the entire response transmission to complete. If the backend server does not transmit any data within a timeout period, the connection is closed.

proxy_next_upstream directive

Language: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;

Default: proxy_next_upstream error timeout;

Context: http, server, location

Specifies under what circumstances a failed request should be sent to the next backend server node.

error: An error occurs when Nginx establishes a connection with the backend server, or sends a request to the backend server, or receives a response header from the backend server.

timeout: timeout occurs when establishing a connection with the backend server, or when sending a request to the backend server, or when receiving a response header from the backend server

invalid_header: The backend server returns an empty response or an invalid response header.

http_500: The response status code returned by the backend server is 500

http_502: Response status code returned by backend server is 502

http_503: The response status code returned by the backend server is 503

http_504: The response status code returned by the backend server is 504

http_404: The response status code returned by the backend server is 404.

off: Stop sending requests to the next backend server

One thing to understand is that it is only feasible to forward the request to the next backend server before sending any data to the client. That is, if an error or timeout occurs while transmitting the response to the client, such an error is impossible to recover from.

Examples:

http {

proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header;

}

0x02: ngx_http_upstream_module module

server command

Language: server address [parameters];

Default: -

Context: upstream

max_failures =number: Sets the number of failed attempts by Nginx to communicate with the server. If the number of failures reaches this value within the time period defined by the fail_timeout parameter, Nginx considers the server unavailable. During the next fail_timeout period, the server will not be tried again. The default number of failed attempts is 1. Set to 0 to stop counting attempts and assume the server is always available. You can configure what is a failed attempt by directing proxy_next_upstream, fastcgi_next_upstream, and memcached_next_upstream. By default, http_404 status is not considered a failed attempt.

fail_timeout=time: Sets the time period during which the server is considered unavailable and the time period during which the number of failed attempts is counted. During this period, the server fails a specified number of attempts and is considered unavailable. By default, this timeout is 10 seconds.

Examples:

upstream name {

server 192.168.1.110:8081 max_fails=3 fail_timeout=60s;

server 192.168.1.122:8082 max_fails=3 fail_timeout=60s;

}

One thing to note in this way is that if there is an unhealthy node on the backend, the Load Balancer will still forward the request to the unhealthy node first, and then forward it to other nodes, thus wasting a forwarding.

At this point, I believe that everyone has a deeper understanding of "what is the method of Nginx backend health check", so you may wish to actually operate it! Here is the website, more related content can enter the relevant channels for inquiry, pay attention to us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.