扩大web应用的规模最常用也是最简单的方式就是用负载均衡,下面看个最基础的负载均衡配置:
http {
upstream backend {
server 192.0.2.10; # server 1
server 192.0.2.11; # server 2
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
}
}
上面的配置中用到了两个关键的指令proxy_pass
和upstream
,定义了两个server,当请求过来时,就会被proxy_pass
分发到backend
这个upstream
,然后nginx通过Round-robin
算法来选择发送到哪一个server.
负载均衡与反向代理本质是一样的.
负载均衡有两大好处:
- 方便应用规模的扩大.
- 方便安全的处理server挂掉的问题.
DNS load balances to load balancers.
1. 使用Upstream指令配置
这是设置负载均衡最重要的一个指令,有必要把它搞清楚.
upstream中的server地址的设置有三种:
upstream backend {
# IP Address with Port
server 192.0.2.10:443;
# Hostname
server app1.example.com;
# Unix Socket
server unix:/u/apps/my_app/current/tmp/unicorn.sock
}
这些只是基础的地址配置,下面看下其他配置.
1.1 权重设置
默认每个server的权重都是1,可以通过调整weight
参数来实现:
upstream backend {
server app1.example.com weight=3;
server app2.example.com;
server app3.example.com;
}
这样第一个server会接收3/5的的请求.
1.2 健康检查
默认情况下的健康检查是:当一个server挂掉时,这个server会被从server池中移除10秒.
但是这种处理方式的缺点在于:
- 比较消极.只有请求过来时才检查.
- 未验证服务器响应结果. 只要server有返回就认为是健康的.
对于这些问题,可以通过相应设置来改变.
1.2.1 max_fails
max_fails
表示server在被移除upstream池之前允许被标记为unhealthy
的次数,默认为1.而对于unhealthy
的鉴定条件是由proxy_next_upstream
决定的.
upstream backend {
server app1.example.com max_fails=2;
server app2.example.com max_fails=100;
}
1.2.2 fail_timeout
这个参数表示两个设置:
- 当server被标记为
unhealthy
时被从upstream池中移出的总时间. -
max_fails
计数的有效时间.比如max_fails=2
和fail_timeout=10
的设置,这个server在10秒内fail两次会被标记为unhealthy
.
fail_timeout
默认值为10,设置如下:
upstream backend {
server app1.example.com max_fails=2 fail_timeout=5;
server app2.example.com max_fails=100 fail_timeout=50;
}
1.2.3 proxy_next_upstream 指令
这个指令控制着fail的条件,可设置的参数和默认的设置如下表:
Name | Meaning | Default? |
---|---|---|
error | An error occurred while communicating with an upstream server | Yes |
timeout | A timeout occurred while communicating with an upstream server | Yes |
invalid_header | A server returned an empty or invalid response | Yes |
http_500 | A server returned a 500 status code | No |
http_502 | A server returned a 502 status code | No |
http_503 | A server returned a 503 status code | No |
http_504 | A server returned a 504 status code | No |
error, timeout, 和invalid_header
这三个参数是默认配置的并且是不可更改的.
一般来说500是正常的,502,503还有504则可认为是server有问题,可以这样设置:
location / {
proxy_next_upstream http_502 http_503 http_504;
proxy_pass http://backend;
}
注意
proxy_next_upstream
的位置.
1.3 从池中移除server
使用down
参数:
upstream backend {
server app1.example.com;
server app2.example.com down;
server app3.example.com;
}
这样这个server就不会接收到请求了.
为什么不直接注释掉呢?
答: to preserve hashes when using a load balancing algorithm such as ip_hash.
1.4 Backup Servers
这些backup servers只有在所有池中的server都挂掉时才会启用,使用backup
参数设置如下:
upstream backend {
server app1.example.com;
server app2.example.com;
server app3.example.com;
server app4.example.com backup;
}
1.5 慢启动
使用slow_start
参数:
upstream backend {
server app1.example.com slow_start=60s;
server app2.example.com;
}
适用于一些程序启动慢但是后面很快的.
ip经常变更时的域名解析问题
分析: 在nginx upstream指令中,server指令后面跟的address参数可以是一个hostname,而对于这个hostname对于ip的解析,nginx在刚启动时会通过DNS查看到对于ip然后缓存起来直到该进程结束.
然而,对于ip地址频繁变更的主机来说就有问题了,因为缓存所以nginx就无法解析到正确的地址.
解决方案: 设置resolve
参数.
http {
resolver 8.8.8.8;
upstream backend {
server loadbalancer.east.elb.amazonaws.com resolve;
}
}