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

This article mainly explains "how Nginx passively checks the survival status of the server". The content in the article is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "how Nginx passively checks the server's survival status".

Introduction

Monitor the health of HTTP servers in the upstream group by sending periodic health checks. Nginx can continuously test your upstream servers, avoid failed servers, and gracefully add recovered servers to the load balancing group.

Passive health examination

For passive health checks, Nginx monitors the transaction when it occurs and attempts to restore the failed connection. If the transaction still cannot be recovered, Nginx marks the server as unavailable and temporarily stops sending requests to it until it is marked as active again.

The conditions that upstream servers are marked as unavailable are defined for each upstream server through the parameters of the server directive in the upstream block:

Fail_timeout: sets the time that multiple failed attempts must be made to mark the server as unavailable, and the time the server is marked as unavailable (the default is 10 seconds).

Max_fails: sets the number of failed attempts that must occur during fail_timeout to mark the server as unavailable (the default is 1 attempt).

In the following example, if Nginx fails to send a request to the server 3 times within 30 seconds or does not receive a response from the server, the server is marked as unavailable within 30 seconds:

Upstream backend {server backend1.example.com; server backend2.example.com max_fails=3 fail_timeout=30s;}

Note: if there is only one server in the group, the fail_timeout and max_fails parameters are ignored and the server is never marked as unavailable.

The server starts slowly

Recently restored servers are easily flooded with connections, which may cause the server to be marked as unavailable again. Slow start allows the upstream server to gradually restore its weight from zero to its nominal value after recovery or availability. This can be done through the parameters of the slow_start upstream server instruction:

Upstream backend {server backend1.example.com slow_start=30s; server backend2.example.com; server 192.0.0.1 backup;}

Note: if there is only one server in the group, slow_start ignores this parameter and the server is never marked as unavailable. Slow start is unique to NGINX Plus (Business Edition).

Thank you for reading, the above is the content of "how Nginx passively checks the survival status of the server". After the study of this article, I believe you have a deeper understanding of how Nginx passively checks the survival status of the server, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.