Nginx server to do load balancing reverse proxy Super Raiders _nginx

Nginx do reverse proxy, the back-end host has more than one, you can use upstream to define a back-end host pool, in the reverse proxy directly using the host pool name. In upstream, we can define load balancing scheduling algorithm, weight, health status detection and other parameters.

For example:

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;;
}

Under the default request, the Round-robin scheduling algorithm is used, and the ability to check and recover the host is in a healthy state.

Ningx can also use these algorithms:

• Ip_hash: Based on source address hashes, the primary purpose is to maintain session
• Least_conn: Scheduling based on least active connections
• Sticky: Session binding based on cookies, Nginx inserts routing information into the cookie on the first visit of the client, or selects the value of a field in the cookie as the key, and each request is then scheduled based on this information

A cookie-based session binding has a total of three cookie,route and learn.

For example, a dispatch based on cookie name:

Upstream backend {
  server backend1.example.com;
  Server backend2.example.com;

  Sticky Cookie srv_id expires=1h domain=.example.com path=/;
}

Use this host group to reverse the proxy:

Location/{
  Proxy_pass http://backend;
  Proxy_set_header Host $host;
  Proxy_set_haeder x-forwared-for $proxy _add_x_forwarded_for;
}

The Proxy_pass URL specifies the proxy's backend host, which can specify an "http" or "https" protocol, the domain name can be an IP address, or it can be a upstream pool name

• If the proxy specifies a URI address, such as http://127.0.0.1/remote, it is directly delegated to the specified URI, regardless of the URI of the request
• If the proxy specifies a host that does not have a URI, such as http://127.0.0.1, the URI requested by the client is passed to the specified domain name
• If a pattern-matching URL is used in location, the URL is also passed to the end of the proxy URL
• If URI overrides are used in location, then Proxy_pass will use the overridden result to process

Proxy_set_header Header VALUE modifies the forwarded message header

Cache-Related Settings when reverse proxy

Proxy_cache_path path [Levels=levels] Keys_zone=name:size

Defines the disk cache path, where the NIGNX cache is stored as a key value, Keys_zone is used to specify the name and size of the memory space that the key holds, and the corresponding value is stored in the path specified by your path. Levels can specify the number of series and name characters for the cache-store 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 to specify how long to cache the contents of different response codes

Such as:

Proxy_cache_valid 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 use of predefined cache space for caching

Some solutions to the problem

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

Typically, server load problems are resolved through multiple server distribution. Common solutions are:

So let's look at how nginx is load-balanced, and Nginx's upstream currently supports the allocation of the following several ways
1. Polling (default)
Each request is assigned to a different back-end server in chronological order, and can be automatically removed if the backend server is down.
2, Weight
Specifies the polling probability, proportional to the weight and the access ratio, for the performance of the backend server.
2, Ip_hash
Each request is allocated according to the hash result of the access IP, so that each visitor has a fixed access to a back-end server that resolves the session's problem.
3, Fair (third party)
The response time of the backend server is allocated to the request, and the response time is short for priority assignment.
4, Url_hash (third party)
The request is allocated by the hash result of the access URL, which directs each URL to the same back-end server, which is more efficient when cached.

How the upstream configuration implements the 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 a request is sent to www.test1.com/www.test2.com, the request is distributed to the server list of the corresponding upstream settings. Test2 each request to distribute the server is random, is the first case listed. The test1 is distributed to the specified server based on the Hashid to access the IP, which means the IP request is transferred to the specified server.

Depending on the performance differences and functions of the server itself, different parameter controls can be set.

Down indicates that the load is too heavy or not involved

The greater the weight of the weight, the heavier the load.

Backup server is not requested for backup other servers or down

Max_fails or request to another server if the failure exceeds a specified number of times

Pause time after fail_timeout failure exceeds a specified number of times

The above is a simple configuration of nginx load balancing. Then continue our discussion in this section:

First, the session question

When we identify a range of servers, our web sites are distributed to these servers. This time, if the use of Test2 every request random access to any server, so that you access to a server, the next request suddenly go to the B server. This time with a server established session, to the B site server is certainly not the normal response. Let's take a look at the common solutions:

• Session or credential caching to a separate server
• Session or credential Save database
• Nginx Ip_hash the request to maintain the same IP is specified to a fixed server

The first method of caching is ideal, and the efficiency of caching is relatively high. However, each request server to access the session sessions server, it is not the load of the server load it?

The second save to the database, in addition to controlling the duration of the session, while increasing the burden on the database, so the final transition to SQL Server load balancing, involving reading, writing, expiration, synchronization.

The third is to maintain a session on the same server through the Nginx ip_hash load, which looks most convenient and lightweight.

Normally, if the architecture is simple, Ip_hash can solve the session problem, but let's look at the following

This time Ip_hash received requests are from the fixed IP proxy request, if the agent IP overload will lead to ip_hash corresponding server load pressure is too large, so ip_hash lost the role of load balancing.

If the cache can be shared synchronously, we can solve a single overload problem through a multiple session server. Can memcached do the session caching server? Memcachedprovider provides a session function to save the session to the database. Why not save it directly to the database and save it to the database via memcached? Quite simply, if you save it directly to the database, each request session validity is returned to the database for verification. Second, even if we create a layer of caching for the database, the cache cannot implement distributed sharing or overload the same cache server. Online also see useful memcached implementation Session cache success stories, of course, the database way to achieve or more commonly used, such as open source Disuz.net forum. Cache implementation of a small range of distributed is also more common, such as single sign-on is a special case.

Ii. File Upload and download

If the load balance is achieved, in addition to the session problem, we will also encounter file upload download problem. Files cannot be uploaded to different servers, which can cause problems with downloading files that are not available. Let's take a look at the following scenario

1. Standalone File server
2. File Compression Database

Both schemes are commonly used, we say that the file compression database, the previous way is the file binary compression to the relational database, and now NoSQL popular, plus mongodb processing files and more convenient, so file engross another option. After all, file servers are not as efficient and manageable and secure as databases.

Casually talk about this matter, in fact, some of the application trend and the realization of a number of solutions.