Introduction to Nginx basic Uptream load Balancer Common Configuration item description

Many large sites, ngixn often as a reverse proxy sever load upstream Web server with high availability mechanism to build a large Web cluster, and to build such a cluster through nginx, it is inevitable that the nginx a very important module: Load Balancer module ( Upstream), as shown below is an introduction to the Nginx Load balancer configuration.

1.1 Upstream block Configuration item description

Syntax: Upstream name {...} Specify load with name (name)

Configuration block: http

The upstream block defines a cluster of upstream servers to facilitate the use of proxy_pass in reverse proxies. For example:

Upstream backend {server backend1.example.com;           Server backend2.example.com;  Server backend3.example.com;    } server {location/{Proxy_pass http://backend; }  }

1.2 Server Block Configuration item description

Syntax: server name [parameters];

Configuration block: Upstream

The server configuration entry specifies the name of an upstream server, which can be a domain name, IP address port, UNIX handle , and so on, followed by the following parameters:

Weight=number: Sets the weight that is forwarded to this upstream server, which defaults to 1.

Max_fails=number: This option is used in conjunction with fail_timeout, meaning that in the fail_timeout time period, if the number of failed forwards to the current upstream server is exceeded, the current Fail_ This upstream server is not available during the timeout period. Max_fails defaults to 1, and if set to 0, the number of failures is not checked.

Fail_timeout=time:fail_timeout indicates that the upstream server is temporarily unavailable for optimization of the reverse proxy functionality after the number of failed forwards in that time period. It is completely unrelated to the time-out of establishing a connection to the upstream server, reading the response time-out of the upstream server, and so on. Fail_timeout default is 10 seconds.

Down: Indicates that the upstream server is permanently offline and is only useful when using Ip_hash configuration items.

Backup: It is not valid when you use the Ip_hash configuration item. It indicates that the upstream server is only a backup server, and only if all non-backup upstream servers are invalidated will the request be forwarded to the upstream server where it resides.

For example

Upstream Backend {server backend1.example.com weight=5;            Server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;  Server Unix:/tmp/backend3; }

1.3 Ip_hash Configuration Instructions

Syntax: Ip_hash;

Configuration block: Upstream

In some scenarios, we may want requests from one user to always fall into a fixed upstream server. For example, suppose the upstream server caches some information, and if the same user's request is arbitrarily forwarded to any of the upstream servers in the cluster, then each upstream server may cache the same information, which can be wasteful and difficult to manage cache information effectively. Ip_hash is to solve the above problem, it first calculates a key based on the IP address of the client, the key according to the number of upstream servers in the upstream cluster, and then the result of the results of the request forwarded to the corresponding upstream server. This ensures that requests from the same client are forwarded only to the specified upstream server.

Ip_hash and Weight (weight) configuration cannot be used simultaneously. If an upstream server in the upstream cluster is temporarily unavailable, the configuration cannot be deleted directly, but the down parameter is identified to ensure consistency of the forwarding policy. For example:

Upstream backend {ip_hash;           Server backend1.example.com;           Server backend2.example.com;           Server backend3.example.com down;  Server backend4.example.com; }

Note: The load balancing algorithm supported by upstream

Nginx Load Balancer module currently supports 4 scheduling algorithms, the following are described separately, of which the latter two are third-party scheduling algorithms.

• Polling (default). Each request is individually assigned to a different back-end server in chronological order, and if a server on the backend is down, the fault system is automatically rejected, leaving the user's access unaffected. Weight Specifies a polling weight value, the higher the Weight value, the higher the access probability assigned to it, which is primarily used in the case of uneven performance per server in the backend.

• Ip_hash. Each request is allocated according to the hash result of the access IP, so that visitors from the same IP have fixed access to a back-end server, which effectively solves the session sharing problem of dynamic Web pages.

• Fair This is a more intelligent load balancing algorithm than the two above. This algorithm can intelligently load balance according to the page size and the load time, that is, the response time of the backend server to allocate the request, the response time is short priority allocation. Nginx itself is not support fair, if you need to use this scheduling algorithm, you must download the Nginx Upstream_fair module.

• Url_ Hash. This method allocates requests according to the hash result of the access URL, directing each URL to the same back-end server, which can further improve the efficiency of the backend cache server. Nginx itself is not support url_hash, if you need to use this scheduling algorithm, you must install Nginx hash package.

1.4 Description of variable items supported when logging

If you need to log some information from load balancing to the Access_log log, you can use the variables provided by the load Balancing feature when you define the log format, as shown in the table

Variable name	Meaning
$upstream _addr	upstream address information for processing requests
$upstream _cache_status	Indicates whether to hit the save, the value of the Wai: Miss expired updating stale hit
$upstream _status	The upstream server returns a response code in response HTTP
$upstream _response_time	Upstream service response time in milliseconds
$upstrea M_http_$header	Header information in http: such as host information $upstream_http_host

For example

Log_format timing ' $remote _addr-$remote _user [$time _local] $request ' upstream_response_time $upstream _response_tim       E ' msec $msec request_time $request _time '; Log_format up_head ' $remote _addr-$remote _user [$time _local] $request ' Upstream_http_content_type $upstream _http_co Ntent_type ';

Here, about Nginx load Balancer related configuration item description will basically end, many configurations are combined, not hard sets can.

This article is from the "Rookie Growth" blog, please be sure to keep this source http://blief.blog.51cto.com/6170059/1740226

Introduction to Nginx basic Uptream load Balancer Common Configuration item description