ngnix的upstream模块配置详解

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.  

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

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

8. }

9.  

10. server {

11.     location / {

12.         proxy_pass http://backend;

13.     }

14. }

 

 

 

动态可配置组的按期健康检查能够做为咱们商业订阅的一部分：

 

1. resolver 10.0.0.1;

2.  

3. upstream dynamic {

4. zone upstream_dynamic 64k;

5.  

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

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

8. server 192.0.2.1 max_fails=3;

9. server backend3.example.com resolve;

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

11.  

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

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

14. }

15.  

16. server {

17. location / {

18. proxy_pass http://dynamic;

19. health_check;

20. }

21. }

指令集

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.  

6. server backup1.example.com backup;

7. }

一般, 请求被服务之间经过加权循环均衡负载方法分发。在上面的例子中， 每七次请求将被以下分发：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.  

4. upstream u {

5. zone ...;

6. ...

7. server example.com resolve;

8. }

9. }

 

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.  

5. server backend1.example.com;

6. server backend2.example.com;

7. server backend3.example.com down;

8. server backend4.example.com;

9. }

直到版本.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.  

5. keepalive 32;

6. }

7.  

8. server {

9. ...

10.  

11. location /memcached/ {

12. set $memcached_key $uri;

13. memcached_pass memcached_backend;

14. }

15.  

16. }

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

 

1. upstream http_backend {

2. server 127.0.0.1:8080;

3.  

4. keepalive 16;

5. }

6.  

7. server {

8. ...

9.  

10. location /http/ {

11. proxy_pass http://http_backend;

12. proxy_http_version 1.1;

13. proxy_set_header Connection "";

14. ...

15. }

16. }