Shulou(Shulou.com)06/01 Report--

How do I configure upstream in nginx? In view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

Configuration example

Upstream backend {server backend1.example.com weight=5; server backend2.example.com:8080; server unix:/tmp/backend3; server backup1.example.com:8080 backup; server backup2.example.com:8080 backup;} server {location / {proxy_pass http://backend;}}

Instruction

Syntax: upstream name {...}

Default:-context: http

Define a set of servers. These servers can listen on different ports. Also, servers that listen on sockets in TCP and UNIX domains can be mixed.

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

By default, nginx distributes requests to each server in a weighted round robin. In the above example, every seven requests are distributed in the following ways: five requests are distributed to the backend1.example.com, one request to the second server, and one request to the third server. When communicating with the server, if an error occurs, the request is passed to the next server until all available servers have been tried. If all servers return failure, the client will get the (failed) response from the server that last communicated.

Syntax: server address [parameters]

Default:-context: upstream

Define the address of the server address and other parameters parameters. The address can be a domain name or an IP address, the port is optional, or the path to the UNIX domain socket that specifies the "unix:" prefix. If no port is specified, port 80 is used. If a domain name is resolved to multiple IP, it essentially defines multiple server.

You can define the following parameters: weight=number sets the weight of the server, which defaults to 1. Max_fails=number sets the number of failed attempts by Nginx to communicate with the server. Within the time period defined by the fail_timeout parameter, if the number of failures reaches this value, Nginx considers the server unavailable. In the next fail_timeout period, the server will not be tried again. The default number of failed attempts is 1. Setting it to 0 will stop counting attempts and assume that the server is always available. You can configure what is a failed attempt by instructing proxy_next_upstream, fastcgi_next_upstream, and memcached_next_upstream. When configured by default, the http_404 status is not considered a failed attempt. Fail_timeout=time Settin

The time period during which the number of failed attempts is counted. During this time, when the server fails a specified number of attempts, the server is considered unavailable.

The period of time during which the server is considered unavailable.

By default, the timeout is 10 seconds. Backup is marked as a standby server. When the primary server is unavailable, the request is sent to those servers. The down tag server is permanently unavailable and can be used with the ip_hash directive.

Example:

Upstream backend {server backend1.example.com weight=5; server 127.0.0.1 max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com:8080 backup; max_fails=3 fail_timeout=30s; server unix:/tmp/backend3; server backup1.example.com:8080 backup;} syntax: ip_hash

Default:-context: upstream

Specifies the load balancing method of the server group and requests distribution between servers based on the IP address of the client. The first three bytes of the IPv4 address or the entire address of the IPv6 will be used as a hash key. This approach ensures that requests from the same client are passed to the same server. Requests from these clients are sent to other servers, most likely the same server, except when the server is considered unavailable.

IPv6 addresses are supported starting with versions 1.3.2 and 1.2.2.

If one of the servers wants to remove it temporarily, you should add the down parameter. This preserves the current client IP address hash distribution.

Example:

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

Starting from versions 1.3.1 and 1.2.2, ip_hash 's load balancing method supports setting server weight values.

Syntax: keepalive connections

Default:-context: upstream

This directive appears in version 1.1.4.

Activate caching of connections to the upstream server.

The connections parameter sets the maximum number of connections each worker process can maintain with the back-end server. These held connections are cached. If the number of connections is greater than this value, the longest unused connections will be closed.

It is important to note that the keepalive directive does not limit the total number of connections between the Nginx process and the upstream server. New connections are always created on demand. The connections parameter should be set slightly lower so that the upstream server can also handle additional incoming connections.

An example of configuring a memcached upstream server to connect to keepalive:

Upstream memcached_backend {server 127.0.0.1 server 10.0.0.2 server 11211; keepalive 32;} server {... Location / memcached/ {set $memcached_key $uri; memcached_pass memcached_backend;}}

For HTTP proxies, the proxy_http_version directive should be set to "1.1" and the value of the" Connection "header should also be cleared.

Upstream http_backend {server 127.0.0.1 keepalive 8080; keepalive 16;} server {... Location / http/ {proxy_pass http://http_backend; proxy_http_version 1.1; proxy_set_header Connection ";...}}

Alternatively, persistent connections to the HTTP/1.0 protocol can also be achieved by sending the "Connection: Keep-Alive" header. However, this is not recommended.

For FastCGI servers, you need to set the fastcgi_keep_conn directive to make the connection keepalive work:

Upstream fastcgi_backend {server 127.0.0.1 keepalive 9000; keepalive 8;} server {... Location / fastcgi/ {fastcgi_pass fastcgi_backend; fastcgi_keep_conn on;...}}

When the load balancing method used is not the default rotation method, it must be configured before the keepalive instruction.

For the SCGI and uwsgi protocols, there is no plan to implement the keepalive connection.

Syntax: least_conn

Default:-context: upstream

This directive appears in versions 1.3.1 and 1.2.2.

Specify the load balancing method of the server group and send the request to the server with the least number of active connections according to its weight value. If there are more than one such server, try it with a weighted rotation.

Embedded variable

The ngx_http_upstream_module module supports the following embedded variables:

Upstream_addr holds the IP address and port of the server or the path of the UNIX domain socket. During request processing, if more than one server is tried, their addresses are concatenated and separated by commas, such as "192.168.1.1, 192.168.1.2, unix:/tmp/sock". If there is an internal jump between servers via the "X-Accel-Redirect" header or error_page, the server groups will be separated by colons, such as: "192.168.1.1 unix:/tmp/sock 80, 192.168.1.2 unix:/tmp/sock 80, 192.168.10.2 unix:/tmp/sock 80". Upstream_response_time retains the response time of the server in milliseconds, in seconds. When multiple responses occur, they are also separated by commas and colons. $upstream_status saves the response code of the server. When multiple responses occur, they are also separated by commas and colons. $upstream_http_... Save the value of the server's response header. For example, the value of the "Server" response header can be obtained through the $upstream_http_server variable. It is important to note that only the header of the last response is retained.

This is the answer to the question about how to configure upstream in nginx. I hope the above content can be of some help to you. If you still have a lot of doubts to solve, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.