Nginx server to do load balancing reverse proxy super strategy

When nginx is doing reverse proxy, there are multiple back-end hosts. You can use upstream to define a back-end host pool and directly use the name of the host pool in reverse proxy. In upstream, load balancing scheduling algorithm, weight, health status detection and other parameters can be defined.

Such as:

upstream backend {
  server 172.16.0.1:80 weight=1 max-fails=3 fail_timeout=10;
  server 172.16.0.2:80 weight=1max-fails=3 fail_timeout=10;;
}

By default, the round-robin scheduling algorithm is used with the ability to check the health status and restore the host.

ningx can also use these algorithms:

ip_hash: based on the source address hash, the primary purpose is session retention least_conn: scheduling based on minimal active connections sticky: session binding based on cookie. nginx will insert routing information into cookie at the first access of the client, or select the value of a field in cookie as the key, and each subsequent request will be scheduled based on this information

There are three types of session bindings based on cookie: cookie, route and learn.

For example, cookie name based scheduling:

upstream backend {
  server backend1.example.com;
  server backend2.example.com;

  sticky cookie srv_id expires=1h domain=.example.com path=/;
}

Use this main unit for reverse proxy:

location / {
  proxy_pass http://backend;
  proxy_set_header Host $host;
  proxy_set_haeder X-Forwared-For $proxy_add_x_forwarded_for;
}

proxy_pass URL specifies the back-end host of the agent. You can specify the "http" or "https" protocol, and the domain name can be either the ip address or the upstream pool name

If the agent is designated by the 1 URI address, such as http: / / 127.0.0.1 remote, then will be agent to specify URI directly, no matter what request URI is If one host specified by the agent does not have URI, such as http://127.0.0.1, URI requested by the client will be passed to the specified domain name If pattern matching url is used in location, then url is also passed to the end of the agent URL If URI overrides are used in location, then proxy_pass will process the overwritten results

proxy_set_header HEADER VALUE modifies the header of the forwarded message

Cache correlation Settings for reverse proxy

proxy_cache_path PATH [levels=levels] keys_zone=NAME:SIZE

Define the disk cache path, nignx's cache is stored as a key value, keys_zone specifies the name and size of the memory space where the key is stored, and the corresponding value is stored in the path specified by PATH. levels can specify the series and number of name characters for the cache location path. This setting can only be defined in the http segment.

Such as:

proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=one:10m;

proxy_cache_valid [code...]. time specifies the cache time for the contents of different response codes

Such as:

proxy_cache_valid 200 302 10m;
proxy_cache_valid 404   1m;
proxy_cache_valid any   1m;

proxy_cache_method METHOD defines which methods' request results can be cached, such as:

proxy_cache_method GET;
proxy_cache_method HEAD;

proxy_cache NAME specifies that a predefined cache space is used for caching

1 solutions to some problems

Here's a look at some of the problems with load balancing using Nginx:

Usually the problem of server load is solved by multi-server load sharing. Common solutions are:

Let's take a look at how Nginx implements load balancing. Nginx's upstream currently supports the following allocation methods
1. Polling (default)
Each request is assigned to a different backend server 1 by 1 in chronological order. If the backend server down is dropped, it can be automatically culled.
2, weight
Specify the polling probability, weight, which is proportional to the access ratio, for situations where the back-end server performance is uneven.
2, ip_hash
Each request is allocated according to the hash result of accessing ip, so that each visitor has a fixed access to one back-end server, which can solve the problem of session.
3. fair (third party)
Requests are allocated according to the response time of the back-end server, and priority is given to those with short response times.
4. url_hash (third party)
Requests are allocated according to the hash result of accessing url, so that each url is directed to the same one back-end server, which is more efficient when the back-end server is cached.

How does the Upstream configuration load

http {  
  
  upstream www.test1.com {
     ip_hash;
     server  172.16.125.76:8066 weight=10;
     server  172.16.125.76:8077 down;
     server  172.16.0.18:8066 max_fails=3 fail_timeout=30s;
     server  172.16.0.18:8077 backup;
   }
   
   upstream www.test2.com {
     server  172.16.0.21:8066;
     server  192.168.76.98:8066;     
   }


   server {
    listen    80;
    server_name www.test1.com;    
    
    location /{
      proxy_pass    http://www.test1.com;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    }   
   } 
   
   server {
    listen    80;
    server_name www.test2.com;    
    
    location /{
      proxy_pass    http://www.test2.com;
      proxy_set_header  Host       $host;
      proxy_set_header  X-Real-IP    $remote_addr;
      proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
   }
}

When there is a request to the www. test1. com/www test2. com requests will be distributed to the corresponding upstream Settings on the server list. Each request to test2 is distributed to a random server, as described in case 1. While test1 is just distributed to the specified server according to the hashid that comes to access ip, that is to say, the requests of IP are transferred to the specified server.

Depending on the performance and function of the server, different parameters can be set.

down means overloaded or not participating in the load

The heavy weight of weight means that the load is larger

The backup server is not requested until backup other servers or down

max_fails fails more than a specified number of times and suspends or requests to move to another server

fail_timeout pause time after a specified number of failures

The above is a simple configuration for load balancing Nginx. So let's continue our discussion in this section:

1. Session problem

When we identify the servers for the series 1 load, our WEB site will be distributed to those servers. At this point, if you use Test2 to randomly access any one server for every request, it will cause you to visit the A server, and the next request will suddenly go to the B server. At this time, Session was established with A server, and the server of B site was definitely unable to respond normally when it was transmitted to B server. Let's look at 1 common solutions:

Session or credentials are cached to a separate server Session or credentials are saved in the database nginx ip_hash requests to keep the same as 1IP are specified to a fixed 1 server

The first method of caching is ideal and efficient. But with every request server going to the Session session server, wouldn't that load the Session server over again?

The second method is saved to the database. Besides controlling the validity of Session, it also increases the burden on the database, so the final change is to SQL Server load balancing, which involves reading, writing, expiration and synchronization.

The third, which seems to be the most convenient and lightweight, keeps the session on the same server through the nginx ip_hash load.

Normally with a simple architecture, ip_hash would solve the Session problem, but let's look at the following case

At this time, the requests received by ip_hash are all requests from the fixed IP agent. If the load of agent IP is too high, the server corresponding to ip_hash will be under too much load pressure, thus ip_hash will lose the function of load balancing.

If the cache can be Shared synchronously, we can solve the single 1 overload problem by having multiple session servers. Can Memcached be the Session cache server? MemcachedProvider provides the functionality of Session, which saves Session to a database. So why not just save to the database, but save to the database via Memcached? Quite simply, if saved directly to the database, each request for Session must be validated back to the database 1 time. Second, even if we set up a layer 1 cache for the database, the cache would not be able to realize distributed sharing and would still be overloaded for the same cache server. Online also see useful Memcached implementation of Session cache successful cases, of course, the database implementation is still more common, such as the open source Disuz.net forum. Small scale distribution of cache implementations is also common, such as single sign-on is a special case.

2. Upload and download files

If load balancing is implemented, in addition to the Session problem, we will also encounter file upload and download problems. It is not possible to upload files to different servers, which can lead to the problem of not being able to download the corresponding files. Let's look at the following scenario

Standalone file server File compression database

Two kinds of schemes are commonly used, let's take 1 file compression database, the previous way is to compress the file 2 base to the relational database, but now the popularity of NOSQL, plus MongoDB file processing is more convenient, so file compression database has one more choice. After all, file servers are not as efficient, manageable, or secure as databases.

Just to talk about it, it's about the trend of some applications and the implementation of one more solution.