ngnix的upstream模块配置详解

2017年04月04日 13:10:03 阿里-橙鹰-潘民兰 阅读数：15409 标签： nginxupstream集群 负载均衡 更多

个人分类： nginx

ngx_http_upstream_module 模块是用来定义被proxy_pass,fastcgi_pass,uwsgi_pass,scgi_pass, and memcached_pass 指令引用的服务器组。

实例配置

1. upstream backend {

2.     server backend1.example.com       weight=5;

3.     server backend2.example.com:8080;

4.     server unix:/tmp/backend3;

5.     server backup1.example.com:8080   backup;

6.     server backup2.example.com:8080   backup;

7. }

8. server {

9.     location / {

10.         proxy_pass http://backend;

11.     }

12. }

动态可配置组的定期健康检查可以作为我们商业订阅的一部分：

1. resolver 10.0.0.1;

2. upstream dynamic {

3. zone upstream_dynamic 64k;

4. server backend1.example.com weight=5;

5. server backend2.example.com:8080 fail_timeout=5s slow_start=30s;

6. server 192.0.2.1 max_fails=3;

7. server backend3.example.com resolve;

8. server backend4.example.com service=http resolve;

9. server backup1.example.com:8080 backup;

10. server backup2.example.com:8080 backup;

11. }

12. server {

13. location / {

14. proxy_pass http://dynamic;

15. health_check;

16. }

17. }

指令集

1. Syntax:

2. upstream name { ... }

3. Default:

4. —

5. Context:

6. http

定义一组服务。服务可以监听在不同端口， 另外, 服务混合监听在 TCP and UNIX-domain sockets。

例如：

1. upstream backend {

2. server backend1.example.com weight=5;

3. server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;

4. server unix:/tmp/backend3;

5. server backup1.example.com backup;

6. }

通常, 请求被服务之间通过加权循环均衡负载方法分发。在上面的例子中， 每七次请求将被如下分发：5 次请求去 backend1.example.com然后第二和第三个服务分别获得一次。当和一个服务通信失败时, 请求将被传递给另一个服务,如果还是不行的话 会一直传递到所有的服务器，如果所有的服务都不不能成功处理该请求，客户端将接受到最后一个服务器的响应。

1. Syntax:

2. server address [parameters];

3. Default:

4. —

5. Context: upstream

定义一个服务的地址和其他参数， 该地址可以被定义为一个 域名或者IP地址,作为一个可选的端口, 或者是一个被"unixt:"前缀修饰的UNIX_domain socket 路径， 如果一个端口没有定义, 则使用80端口. 一个域名如果对应多个Ip地址，则同时定义多个服务地址。.
可以定义一下参数

weight=number 

设置定义的服务的权重，默认为1。

max_conns=number 

限制连接到代理服务器的并发连接数，版本(1.11.5). 默认值是0,意思是没有限制. 如果集群没有使用 共享内存, 则该限制对应的是每个工作进程。.

如果idle keepalive 连接,多workers, 和 shared memory是能够使用的 , 那么代理服务器的激活的和闲置的连接将超过max_conns的值。

版本1.5.9 到 1.11.5, max_conns是可用的作为我们商业订阅的一部分。

max_fails=number 

设置在被fail_timeout参数定义的时间内当和服务通信失败尝试的次数。默认的该值被设为1.如果为0表示不支持失败重试，什么被当作是不成功的尝试被这些指令定义：proxy_next_upstream,fastcgi_next_upstream, uwsgi_next_upstream, scgi_next_upstream, 和 memcached_next_upstream .

fail_timeout=time 

• 在该参数定义的时间范围内和服务器的通信失败尝试重连时间范围，如果超过则表示该服务器不可用。
• 在这个时间段服务被当作不可用

默认情况下, 该参数被设置成10秒.

backup 

标记该服务是一个热备服务. 当主服务不可用后才会把请求传递给它。

down 

标记该服务永久不可用。

另外，下面参数是做为我们商业订阅的一部分：

resolve 

监控绑定到一个服务的域名的ip地址的变化，然后自动修改upstream配置不需要重启nginx（1.5.12）.服务集群必须使用共享内存。

为了让该参数生效，resolver指令必须定义在http 模块，如：

1. http {

2. resolver 10.0.0.1;

3. upstream u {

4. zone ...;

5. ...

6. server example.com resolve;

7. }

8. }

route=string 

设置服务路由的名称

service=name

启用DNS SRV记录解析和设置服务的名称（1.9.13）.为了让该参数生效，需要定义resolve参数和指定一个不需要端口的hostname.

如果该服务名称不包含(".")号，那么RFC-compliant名称将被构造以及TCP协议被添加到服务的前缀。例如，去查找_http._tcp.backend.example.com SRV记录，是有必要定义该指令：

server backend.example.com service=http resolve;

如果该服务名称包含一个或者多个点号, 那么该服务名称将通过结合服务前缀和服务名称构造。例如。

1. server backend.example.com service=_http._tcp resolve;

2. server example.com service=server1.backend resolve;

最高优先级SRV记录（同样最低数字的优先级值）将被当作主服务解析，剩下的SRV记录被当作备份服务。如果backup参数在有定义在该服务商，高优先级SRV 记录将被当作备份服务，剩下的SRV记录被忽略。

slow_start=time 

设置服务从权重0到正常值的一个时间期限，当不健康的服务变成健康的，或者当服务从不可用到可用，默认值是0，意思slow start不可用。

该参数不能和hash 以及ip_hash 负载均衡方法一起使用。

如果在集群中只有一个服务 max_fails, fail_timeout and slow_start 参数将被忽略，然后这样的服务将被永久当作可用。

1. Syntax:

2. zone name [size];

3. Default:

4. —

5. Context:

6. upstream

7. This directive appeared in version 1.9.0.

定义集群的配置和工作进程共享运行时状态的共享内存区域的name 和size ，几个集群会共享同样的区域，所以可以定义zone的大小一次就可。

另外，作为我们商业订阅的一部分，集群运行改变集群成员和修改一些服务的配置不需要重启nginx。那配置是可以见的在指定的位置被upstream_conf管理。

1. Syntax:

2. state file;

3. Default:

4. —

5. Context:

6. upstream

7. This directive appeared in version 1.9.7.

制定一个文件保存动态可配置集群的状态。

例如：

1. state /var/lib/nginx/state/servers.conf; # path for Linux

2. state /var/db/nginx/state/servers.conf; # path for FreeBSD

集群的状态目前被限制在一系列的服务里。当解析配置或者更新配置时该文件将被读取。直接改变该文件的内容应该要避免，该指令不能和server指令一起使用。
在configuration_reload或者binary_upgrade期间对该文件的修改将可能丢失修改。

这个指令是我们商业订阅的一部分。

Syntax:	hash key [consistent];
Default:	—
Context:	upstream

This directive appeared in version 1.7.2.

指定集群负载均衡的方法基于hash key的值。key可以保护文本，变量，和它们的组合。注意，从集群添加或者删除服务都会导致请求映射到其他服务商。这个方法可以和Cache::Memcached Perl 库兼容。

如果consistent参数被定义，一致性哈希算法将被使用，该方法保证一小部分的请求被重新映射到其他服务当集群的服务添加或者删除时，这帮助缓存服务器提高缓存命中率。IThe method is compatible with the Cache::Memcached::Fast Perl library with the ketama_points parameter set to 160.

Syntax: ip_hash; 

1. Default:

2. —

3. Context:

4. upstream

指定集群服务应该根据客户端ip来进行负载均衡。IPV4地址的前三个字节，或者整个IPV6的地址，将被当作哈希值。这个方法保证来自哦同一个客户端的请求映射到同一个服务器上除掉该服务部可用。

IPV6地址将从1.3.2和1.2.2版本开始支持。

如果集群中的一个服务被暂时的移除，该服务应用用 down参数定义，以防当前客户的ip地址哈希映射过去。

例如：

1. Example:

2. upstream backend {

3. ip_hash;

4. server backend1.example.com;

5. server backend2.example.com;

6. server backend3.example.com down;

7. server backend4.example.com;

8. }

直到版本.32和1.2.2，都不能够用过ip_hash进行负载均衡时指定权重。

1. Syntax:

2. keepalive connections;

3. Default:

4. —

5. Context:

6. upstream

7. This directive appeared in version 1.1.4.

激活连接到上游服务器的缓存。

connections参数设置连接到上游服务的最大空闲连接数--被保存在每个工作进程的缓存里。当连接数超过该connections时最近最少使用的连接将被关闭。

使用keepalive connections的上游服务的缓存配置实例：

1. upstream memcached_backend {

2. server 127.0.0.1:11211;

3. server 10.0.0.2:11211;

4. keepalive 32;

5. }

6. server {

7. ...

8. location /memcached/ {

9. set $memcached_key $uri;

10. memcached_pass memcached_backend;

11. }

12. }

对于HTTP，proxy_http_version应该设置为'1.1'然后"Connection"header 字段应该被清空：

1. upstream http_backend {

2. server 127.0.0.1:8080;

3. keepalive 16;

4. }

5. server {

6. ...

7. location /http/ {

8. proxy_pass http://http_backend;

9. proxy_http_version 1.1;

10. proxy_set_header Connection "";

11. ...

12. }

13. }