Interpretation of the module for load balancing using nginx

Two modules for using nginx for load balancing:

• upstream defines the load node pool.
• The location module performs URL matching.
• The proxy module sends requests to the node pool defined by upstream.

Interpretation of upstream module

The load balancing function of nginx depends on the ngx_http_upstream_module module. The supported proxy methods are proxy_pass (generally used for reverse proxy), fastcgi_pass (generally used for interaction with dynamic programs), memcached_pass, proxy_next_upstream, fastcgi_next_pass, memcached_next_pass.

The upstream module should be placed within the http{} tag.

Module writing:

upstream backend {
  ip_hash; 
  server backend1.example.com weight=5;
  server backend2.example.com:8080;
  server backup1.example.com:8080 backup;
  server backup2.example.com:8080 backup;
}

Example 1:

upstream dynamic
  zone upstream_dynamic 64k;

  server backend1.example.com weight=5;
  server backend2.example.com:8080 fail_timeout=5s slow_start=30s;
  server 192.0.2.1 max_fails=3;
  server backend3.example.com resolve;

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

Syntax explanation:

Nginx supports four scheduling algorithms by default

• Polling (rr), each request is assigned to different backend servers one by one in chronological order. If a backend server fails, the faulty system will automatically clear it so that user access is not affected.
• Polling weight (weight). The larger the weight value, the higher the probability of assigned access. It is mainly used in the case where the performance of each backend server is uneven.
• ip_hash, each request is assigned according to the hash result of the access IP, so that fixed access from the same IP address is to one backend server, which mainly solves the problem of session sharing for dynamic websites.
• url_hash, distributes requests according to the hash result of the visited URL, directs each URL to the same backend server, which can further improve the efficiency of the backend cache server. nginx itself does not support it. If you want to use it, you need to install the hash software package of nginx.
• fair, this algorithm can intelligently balance the load according to the page size and loading time, that is, it distributes requests according to the response time of the backend server, and prioritizes requests with shorter response times. It is not supported by default. If you want to use it, you need to install the upstream_fail module.
• least_conn The minimum number of connections. The machine with the least number of connections will be used for distribution.

How to write server module

Server IP scheduling status

The server directive specifies the backend server IP address and port, and can also set the status of each backend server in the load balancing scheduling.

• down means that the current server is not participating in load balancing temporarily.
• backup is a reserved backup server. When all other non-backup servers fail or are busy, the backup machine will be requested because this cluster has the least pressure.
• max_fails is the number of request failures allowed. The default value is 1. When the maximum number is exceeded, an error defined by the proxy_next_upstream module is returned. 0 means prohibiting failed attempts. Enterprise scenario: 2-3. JD.com 1 time, ChinaCache 10 times. Configure according to business needs.

fail_timeout, the time to suspend service after max_fails failures. JD.com is 3s, ChinaCache is 3s, configured according to business needs. 2-3 seconds is reasonable for routine business.
For example, if max_fails is 5, it will test 5 times. If the result is 502 all five times, it will wait 10 seconds according to the value of fail_timeout before testing again.

If server connects to a domain name, a DNS server is required on the intranet, or domain name resolution is performed in the hosts file of the load balancer. The server can also be directly connected to the IP or IP plus port.

Long connection keepalive

upstream backend {
  server backend2.example.com:8080;
  server backup1.example.com:8080 backup;
  keepalive 100;
}

This directive configures the maximum number of idle connections that each worker process can cache with the upstream server.
When this number is exceeded, the least recently used connection will be closed. The keepalive directive does not limit the total number of connections that a worker process can make to an upstream server.

location / {
  # Support keep-alive
  proxy_http_version 1.1;
  proxy_set_header Connection "";
  proxy_pass http://backup;
}

• If it is http/1.0, you need to configure to send the "Connection: Keep-Alive" request header.
  
• Don't forget to enable long connection support on the upstream server.
  

Connection pool configuration recommendations

• The total number of long connections is the total number of long connections in the "free connection pool" + "released connection pool".
• First, the long connection configuration does not limit the total number of connections that the worker process can open (the number of connections exceeding this limit will be treated as short connections). In addition, the connection pool must be set up reasonably according to the scenario.

The idle connection pool is too small, the connections are insufficient, and connections need to be continuously established.
The idle connection pool is too large, there are too many idle connections, and they time out before they are used.
It is recommended to enable long connections only for small messages.

Location Module Interpretation

Location function: Set the URI based on a directive.

Basic syntax:

Syntax: location [ = | ~ | ~* | ^~ ] uri { ... }
location @name { ... }
Default: —
Context: server, location

• = Exact match. If the content matching the = sign is found, the search will be stopped immediately and the request will be processed immediately (with the highest priority).
• ~ is case-sensitive
• ~* is case insensitive
• ^~ only matches strings, not regular expressions
• @ specifies a named location, generally used for internal redefinition requests, location @name {…}

The matching is based on priority and is not performed according to the nginx configuration file.

Official example:

location = / {
  [ configuration A ]
}
location / {
  [ configuration B ]
}
location /documents/ {
  [ configuration C ]
}
location ^~ /images/ {
  [ configuration D ]
}
location ~* \.(gif|jpg|jpeg)$ {
  [ configuration E ]
}

in conclusion:

• / matches A.
• /index.html matches B
• /documents/document.html matches C
• /images/1.gif matches D
• /documents/1.jpg matches E.

Test example:

location / {
      return 401;
    }
    location = / {
      return 402;
    }
    location /documents/ {
      return 403;
    }
    location ^~ /images/ {
      return 404;
    }
    location ~* \.(gif|jpg|jpeg)$ {
      return 500;
    }

Test results (focus on):

[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" http://10.0.0.7/
402
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" http://10.0.0.7/index.html
401
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" http://10.0.0.7/documents/document.html 
403
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" upload/2022/web/1.gif
404
[root@lb01 conf]# curl -I -s -o /dev/null -w "%{http_code}\n" upload/2022/web/1.gif 
500

Summary of results:

Matching priority order, =>^~ (matches a fixed string, ignoring regular expressions) > completely equal >~* > empty >/.

Try to put '=' in front when working

Proxy_pass module explanation

The proxy_pass directive belongs to the ngx_http_proxy_module module, which can forward requests to another server.

Writing method:

proxy_pass http://localhost:8000/uri/;

Example 1:

  upstream blog_real_servers {
     server 10.0.0.9:80 weight=5;
     server 10.0.0.10:80 weight=10;
     server 10.0.0.19:82 weight=15;
  }
  server {
    listen 80;
    server_name blog.etiantian.org;
    location / {
    proxy_pass http://blog_real_servers;
    proxy_set_header host $host;
    }
  }

• proxy_set_header: When multiple virtual hosts are configured on the backend Web server, this header is needed to distinguish the host name of the reverse proxy, proxy_set_header host $host;.
• proxy_set_header X-Forwarded-For: If the program on the backend web server needs to obtain the user's IP address, obtain it from this header. proxy_set_header X-Forwarded-For $remote_addr;

Configure the backend server to receive the real frontend IP

The configuration is as follows:

  log_format commonlog '$remote_addr - $remote_user [$time_local] "$request" '
           '$status $body_bytes_sent "$http_referer" '
           '"$http_user_agent" "$http_x_forwarded_for"';

httpd.conf configuration of rs_apache node

LogFormat "\"%{X-Forwarded-For}i\" %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{U
ser-Agent}i\"" combined modify logging apache
LogFormat "\"%{X-Forwarded-For}i\" %l %u %t \"%r\" %>s %b" common

Optimization parameters related to proxy_pass

• client_max_body_size 10m; The maximum number of bytes of a single file allowed to be requested by the client.
• client_body_buffer_size 128k; The maximum number of bytes that the buffer proxy buffers the client request can be understood as first saving it locally and then passing it to the user.
• proxy_connect_timeout 600; The timeout for connecting to the backend server and waiting for a response after initiating a handshake.
• proxy_read_timeout 600; After the connection is successful, the server has actually entered the backend queue waiting for processing.
• proxy_send_timeout 600; The time it takes for the backend server to send back data means that the backend server must send all data within the specified time.
• proxy_buffer_size 8k; Proxy request buffer. This cache interval will save the user's header information for Nginx to process rules. Generally, just set it to save the header information.
• proxy_buffers 4 32k; Same as above, tells Nginx how much space to use to store a single page, assuming that the average web page size is less than 32k.
• proxy_busy_buffers_size 64k; If the system is very busy, you can apply for a larger proxy_buffers. The official recommendation is (proxy_buffers*2).
• proxy_max_temp_file_size 1024m; When proxy_buffers cannot hold the response content from the backend server, part of it will be saved in a temporary file on the hard disk. This value is used to set the maximum temporary file size. The default value is 1024M. It has nothing to do with proxy_cache. If it is larger than this value, it will be sent back from the upstream server. Set to 0 to disable.
• proxy_temp_file_write_size 64k; proxy_temp_path (which can be used during compilation) specifies the directory where the proxy cache temporary file is written.

Health Check

Nginx provides the health_check statement to provide a key health check mechanism during load (upstream) (Note: this statement needs to be set in the location context).

Supported parameters are:

• interval=time: Set the interval between two health checks. The default value is 5 seconds.
• fails=number: Sets the number of consecutive checks before the server is considered unhealthy. The default is 1.
• passes=number: Sets the number of consecutive checks for a server to be considered healthy. The default is 1.
• uri=uri: defines the request URI for health check, the default is "/"
• match=name: Specifies the name of the matching configuration block, used to test whether the response passes the health check. The default test return status code is 2xx and 3xx

A simple setup is as follows, using the default values:

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

For the application, we can define a dedicated API for health check: /api/health_check, and only return the HTTP status code 200. And set the interval value between two checks to 1 second. Thus, the configuration of the health_check statement is as follows:

health_check uri="/api/health_check" interval;

Matching method

http {
  server {
  ...
    location / {
      proxy_pass http://backend;
      health_check match=welcome;
    }
  }

  match welcome {
    status 200;
    header Content-Type = text/html;
    body ~ "Welcome to nginx!";
  }
}

Match Example

• status 200;: status equals 200
• status ! 500;: status is not 500
• status 200 204;: status is 200 or 204
• status ! 301 302;: status is not 301 or 302.
• status 200-399;: status is between 200 and 399.
• status ! 400-599;: status is not between 400 and 599.
• status 301-303 307;: status is 301, 302, 303, or 307.
• header Content-Type = text/html;: The value of “Content-Type” is text/html.
• header Content-Type != text/html;: “Content-Type” is not text/html.
• header Connection ~ close;: “Connection” contains close.
• header Connection !~ close;: “Connection” does not include close.
• header Host;: The request header contains "Host".
• header !X-Accel-Redirect;: The request header does not contain "X-Accel-Redirect".
• body ~ "Welcome to nginx!";: body contains "Welcome to nginx!".
• body !~ "Welcome to nginx!";: body does not contain "Welcome to nginx!".

A complete nginx instance

[root@lb01 conf]# cat nginx.conf
worker_processes 1;
events {
  worker_connections 1024;
}
http {
  include mime.types;
  default_type application/octet-stream;
  sendfile on;
  keepalive_timeout 65;
  #blog lb by oldboy at 201303
  upstream blog_real_servers {
  server 10.0.0.9:80 weight=1 max_fails=1 fail_timeout=10s;
  server 10.0.0.10:80 weight=1 max_fails=2 fail_timeout=20s;

  }
  server {
    listen 80;
    server_name blog.etiantian.org;
    location / {
    proxy_pass http://blog_real_servers;
    include proxy.conf;
    }
  }
}
[root@lb01 conf]# cat proxy.conf 
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_connect_timeout 90;    
    proxy_send_timeout 90;
    proxy_read_timeout 90;
    proxy_buffer_size 4k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k;

Extensions

Only GET, HEAD, and POST methods are allowed to be used for requests

## Only allow these request methods ##
   if ($request_method !~ ^(GET|HEAD|POST)$ ) {
     return 444;
   }

Actual Combat

Separate static and dynamic data based on URI and location.

Final implementation:

• All URLs with the name /static/ go to 10.0.0.9.
• All URLs with the name /dynamic/ go to 10.0.0.10.
• These static files are accessed on 10.0.0.9.
• The URL /upload/ all access 10.0.0.10.

[root@lb01 conf]# cat nginx.conf
worker_processes 1;
events {
  worker_connections 1024;
}
http {
  include mime.types;
  default_type application/octet-stream;
  sendfile on;
  keepalive_timeout 65;
  #blog lb by oldboy at 201303

  upstream static_pools {
   server 10.0.0.9:80;
  }
  upstream dynamic_pools {
   server 10.0.0.10:80;
  }
   upstream upload_pools {
   server 10.0.0.9:80;
  }

  server {
    listen 80;
    server_name blog.biglittleant.cn;
    
    location / {
    proxy_pass http://static_pools;
    include proxy.conf;
    }

    location /static/ { 
    proxy_pass http://static_pools;
    include proxy.conf;
    }
    
    location ~* \.(gif|jpg|jpeg)$ {
     proxy_pass http://static_pools;
     include proxy.conf;
    }

    location /dynamic/ { 
    proxy_pass http://dynamic_pools;
    include proxy.conf;
    }
    location /upload/ {
    proxy_pass http://upload_pools;
    include proxy.conf;
    }
  }
}

Implement different addresses for Apple and Android phones

server {
    listen 80;
    server_name blog.etiantian.org;
    location / {
    if ($http_user_agent ~* "android")
     {
      proxy_pass http://android_pools;
     }
    if ($http_user_agent ~* "iphone")
     {
      proxy_pass http://iphone_pools;
      }
    proxy_pass http://pc_pools;
    include extra/proxy.conf;
    }
    access_log off;
   }

Reference Documentation

nginx-proxy_pass official website

This is the end of this article about using nginx for load balancing module interpretation. For more relevant nginx load balancing content, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope everyone will support 123WORDPRESS.COM in the future!