How Nginx uses ngx_http_upstream_module to implement load balancing function

Introduction to load balancing

What is load balancing

Load balancing (Load Balance) means to load (work tasks, access Requests) are balanced and distributed to multiple operating units (servers, components) for execution.

Why load balancing is needed

When a single web server faces users directly, it may carry a large number of concurrent requests. A single server may be difficult to load. We need to use multiple web servers to form a The cluster uses the Nginx load balancing function to distribute requests to different back-end servers to achieve load traffic distribution, improve overall performance, and the system's disaster recovery capability.

• What is the difference between load balancing and proxy

A proxy is a proxy for a server to be scheduled based on URI and dispatched to application nodes with different functions

Load balancing is to proxy client requests to a set of upstream resource pools through proxy_pass

• To achieve load balancing scenarios

To achieve load The balancing function requires the use of two modules:

• proxy_pass: proxy module

• upstream: virtual resource pool

Example: An official load balancing display

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Example: Complete a small example by yourself

upstream node {
    server 192.168.10.3:80;
    server 192.168.10.4:80;
}
server {
    listen 80;
    server_name www.yyang.com;
    location / {
        proxy_pass http://node;
        include prxoy_params;
    }
}

Load balancing scheduling algorithm

Polling scheduling

Assigned to different backend nodes one by one in order, which is also the default algorithm. (Simply speaking, it is 1:1:1)

Weighted polling
Considering the different performance of different servers, different weights are given to the nodes so that they can receive the corresponding Number of weighted requests

server 192.168.10.3:80 weight=3;
server 192.168.10.4:80 weight=1;

The above example means that every 4 requests will be allocated to three requests for 10.3 and one for 10.4, and so on.

ip_hash

According to the IP requested by the user, perform a hash operation on the IP, and assign the request to a specific node on the backend for processing based on the calculated value.

The value range is the first three 8 bits of the ipv4 address or the entire address of ipv6 as the hash key, ensuring that the IP from one client is always passed to the same server, unless the secondary server is unavailable. To put it simply, the first three sets of numbers of 172.16.20.1 and 172.16.20.2 are the same (all 172.16.20)

ip_hash operation formula: hash (ip) %node_counts=index

Problems caused by ip_hash:
A large number of requests for the same IP will cause excessive traffic on a node
If a node is temporarily offline, the hash value will be recalculated. It is recommended to use the down state

Example : Note that ip_hash and weight cannot be used at the same time

ip_hash;
server 192.168.10.3:80;
server 192.168.10.4:80;

Consistency hash

In order to avoid the above problems, consistent hash was born, using the modulo method, but it is not correct The number of server nodes is modulo, but modulo 2 raised to the 32nd power. The hash function value is 0~2^32-1. (Forming a virtual ring, user requests will be sent to clockwise adjacent nodes)
There is a problem: if there are fewer back-end nodes, it may cause data skew, so consistent hash introduces a virtual node mechanism, that is, for Each server computes multiple hashes and places a virtual node at each computed result location.
What should we do if we want to use ip_hash, but the calculation formula uses consistent hash?

hash $remote_addr consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

url_hash

Carry out hash modulo based on the user's url, and assign the request to a specific back-end server based on the operation value.

1. The user requests nginx load balancing, and the request is scheduled to cache1 through the url algorithm
2. If cache1 has no data, it will obtain the data from the backend, return the data, and cache the data
3. When When other users access the same URL, the scheduler will still schedule to the cache1 node
4.cache1 will directly return the data to

hash $request_uri consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

least_conn

which server If the number of connections is the least, the request will be dispatched to this server

least_conn;
server 192.168.10.3:80;
server 192.168.10.4:80;

Load balancing backend node status

down

Mark the server node as unavailable status, generally used for shutdown maintenance.

server 192.168.10.3:80 down;
server 192.168.10.4:80;

backup

Standby node, this node will not be scheduled under normal circumstances; when all normal working nodes are unavailable, this node will be enabled; when the node recovers, this node The node will continue to return to standby status.

server 192.168.10.3:80;
server 192.168.10.4:80;
server 192.168.10.5:80 backup;

max_conns

is used to limit the maximum number of TCP connections received by each backend node. If the limit is exceeded, an error will be thrown.

server 192.168.10.3:80 max_conns=10;
server 192.168.10.4:80 max_conns=10;

One can connect 10. Two can connect 20. If it exceeds 20, an error will occur.

keepalived

Activate caching with the back-end server, that is, long links, to improve website throughput.
This function is not enabled by default. When there is a request, a connection will be established, maintained, and closed, so there will be network consumption; but if all connections are cached, other system resources will be occupied when the connection is idle, so The keepalived parameter can be used.

server 192.168.10.3:80;
server 192.168.10.4:80;

keepalived 32;   # 最大空闲连接数的个数
keepalived_timeout 100s; # 空闲连接的超时时间

# 需要配合以下两个参数使用

proxy_http_version 1.1;
proxy_set_header connection "";

max_fails and fail_timeout

max_fails=2：服务器通信失败两次，认为服务器不可用
fail_timeout=5s：服务器通信失败后，每5秒探测一次服务器是否恢复正常。
在fail_timeout设定时间内，与服务器连接失败次数达到max_fails数量，则认为服务器不可用。
如果不设置的话默认是探测一次，间隔10s。

server 192.168.10.3:80 max_fails=2 fail_timeout=5s;
server 192.168.10.4:80 max_fails=2 fail_timeout=5s;

The above is the detailed content of How Nginx uses ngx_http_upstream_module to implement load balancing function. For more information, please follow other related articles on the PHP Chinese website!