How to deploy load balancing on Nginx Server?
6 min readHow to deploy load balancing on Nginx Server?
How to deploy load balancing on Nginx Server?
Load balancing
Load balancing can share requests from the front-end to multiple nodes in the back-end, improving the response and processing capabilities of the system.
Load balancing is an excellent way to scale an application and increase its performance and redundancy.
Nginx is a popular web server software that can be configured as a simple but powerful load balancer to increase the availability and efficiency of server resources.
In a load-balanced configuration, nginx acts as a single entry point for distributed web applications working on multiple separate servers.
For installations of nginx on CentOS/AlmaLinux/Rucky Linux, users can find their host configuration file under /etc/nginx/conf.d/ with any .conf type of virtual host file loaded.
Nginx load balancing strategy
Load balancing strategies can be roughly divided into two categories: built-in strategies and extended strategies
Built-in strategies: generally compiled directly into the Nginx kernel, commonly used polling, weighted polling, least connection balancing and ip_hash strategies.
By default, the built-in policy will be compiled into the nginx kernel, just specify the parameters in the nginx configuration.
Extension strategies: fair, url hash, Sticky strategy, etc., are not compiled into the nginx kernel by default.
Nginx configuration method and configuration template
1. Edit the configuration file: load-balancer.conf
sudo vi /etc/nginx/conf.d/load-balancer.conf
2. In load-balancer.conf you need to define the following two sections: upstream and server
#Define the servers to be included in the load balancing scheme.# It is better to use the server's private IP for better performance and security.http {upstream backend {server 10.1 . 0.101 ;server 10.1 . 0.102 ;server 10.1 . 0.103 ;}# This server accepts all traffic to port 80 and passes it upstream.# Note that upstream name and proxy_pass need to match.server { listen 80 ;location / {proxy_pass http: // backend; } }}
3. Then save the file, exit the editor and restart nginx again.
sudo systemctl restart nginx
Built-in strategy
(1) Round order strategy
This strategy is that the server assigns each front-end request to different back-end server nodes one by one in order (time order and arrangement order). If there is a problem with the backend server, that is, it goes down, it will be automatically eliminated.
http {
# … omit other configuration
upstream s_siat{
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
# … omit other configuration
}
(2) Weighted polling strategy
This strategy considers the weight of each back-end server node to accept the request based on the basic polling strategy, and specifies the probability of each back-end server node being polled.
It is mainly used in the performance of back-end server nodes. average situation.
For example: setting the access probability by directly configuring the weight, the size of the weight is proportional to the access ratio. The following three servers (if weight is not configured, the default configuration is weight=1), the weight of the first is 1, the weight of the second is 3, and the weight of the third is 2, then these three back-end servers The accessed ratio is 1:3:2, that is, server172.31.3.82:9171 has the highest probability of being accessed, followed by server172.31.3.82:9171, and server172.31.3.82:9170 has the lowest probability of being accessed.
http {
# … omit other configurations
upstream s_siat{
server 172.31.3.82:9170;
server 172.31.3.82:9171 weight=3;
server 172.31.3.82:9173 weight=2;
}
# … omit other configurations
}
(3) ip_hash strategy
The strategy is to hash the access IP of the front-end, and then distribute the request to different back-end server nodes according to the hash result. In this way, each front-end access IP will access a back-end server node fixedly.
The advantage is that the session of the front-end user is only on one back-end server node, and there is no need to consider the session contribution problem of multiple server nodes in one session.
For example: because weight is built-in, it can be used directly with other strategies.
This strategy uses the ip_hash strategy, and you need to add a line of ip_hash to the upstream configuration.
http {
# … omit other configurations
upstream s_siat{
ip_hash;
server 172.31.3.82:9170;
server 172.31.3.82:9171 weight=3;
server 172.31.3.82:9173 weight=2;
}
# … omit other configurations
}
Or
http {
# … omit other configuration
upstream s_siat{
ip_hash;
server 172.31.3.82:9170;
server 172.31.3.82:9171;
server 172.31.3.82:9173;
}
# … omit other configuration
}
Both are ip_hash strategies. Only the probability of the corresponding server being accessed has changed.
Note: The ip_hash module and the following Sticky module cannot be used at the same time.
(4) Least connection (least_conn)
Load balancing based on the least connection is another simple method.
As the name suggests, this method directs the request to the server with the fewest active connections at the time.
It is more efficient than round-robin for applications where requests may sometimes take longer to complete.
http {
# … omit other configuration
upstream s_siat {
least_conn;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
# … omit other configuration
}
Scaling strategy
(1) url_hash strategy
This strategy hashes the url address requested by the front-end, and directs the request to the same back-end server node according to the hash result.
It is more effective for the back-end server to cache. Generally, url_hash needs to be used with buffer hits.
http {
# … omit other configuration
upstream s_siat {
server 192.168.0.100:8080;
server 192.168.0.101:8080;
hash $request_uri;
hash_method crc32;
}
# … omit other configuration
}
(2) fair strategy
The policy request is forwarded to the backend server node with the least load. Nginx judges the load by the response time of the back-end server node.
The node with the shortest response time has a relatively light load, and Nginx will forward the front-end request to this back-end server node.
http {
# … omit other configuration
upstream s_siat{
server 172.31.3.82:9170;
server 172.31.3.82:9171;
server 172.31.3.82:9173;
fair;
# … omit other configuration
}
(3) Sticky strategy
In the environment of multiple servers, in order to ensure that a client communicates with only one server, it will maintain a long connection and select a server again after ending the session to ensure pressure balance.
http {
# … omit other configuration
upstream s_siat{
sticky;
server 172.31.3.82:9170;
server 172.31.3.82:9171;
server 172.31.3.82:9173;
# … omit other configurations
}
Note: If the browser does not support cookies, then sticky does not take effect, after all, the entire Modules are given cookie implementations. Sticky module and ip_hash module cannot be used at the same time.
Other configurations in upstream
Add to the server that needs to use load balancing:
proxy_passhttp://backserver/;
upstreambackserver{
ip_hash;
server127.0.0.1:9090 down; (down means that the server before the order does not participate in the load temporarily)
server127.0.0.1:8080 weight=2; (weight defaults to 1. The greater the weight, the greater the weight of the load)
server127.0.0.1:6060 max_fails=3 fail_timeout=30s; (max_fails allows the number of requests to fail by default to 1, and the number of allowed failures here is 3. The pause time after each failure is 30s)
server127.0.0.1:7070 backup; (when all other non-backup machines are down or busy, request the backup machine)
keepalive16; (maximum connected to nginx load balancer)
}
server{
location / { # (do url redirection or do a new proxy)
proxy_pass http://backend;
}
- down means that the server before the order does not participate in the load temporarily
- weight defaults to 1. The larger the weight, the greater the weight of the load.
- max_fails: The default number of allowed requests to fail is 1. When the maximum number of times is exceeded, the error defined by the proxy_next_upstream module is returned
- fail_timeout: The time to pause after max_fails failures.
- backup: When all other non-backup machines are down or busy, request the backup machine. So this machine will be the least stressful.
- keepalive: The number of connections (the value of keepalive) specifies the maximum number of persistent connections to the nginx load balancer cache that are kept in each worker process. If more idle processes than this setting want to connect to the nginx load balancer group, the first one to connect will be closed.
- The location matches the URL. It can be redirected or a new proxy load balancing can be performed
Note: nginx supports setting multiple groups of load balancing at the same time for use by different servers.
l client_body_in_file_only is set to On to record the data from clientpost to a file for debugging
l client_body_temp_path sets the directory of the record file and can set up to 3 levels of directories
