Nginx负载均衡组件模块

Posted 2020-08-21

nginx负载均衡组件模块

  实现Nginx负载均衡的组件主要有两个：

n  ngx_http_proxy_module proxy代理模块，用于把请求后抛给服务器节点或upstream服务器池

n  ngx_http_upstream_module 负载均衡模块，可以实现网站的负载均衡功能及节点的健康检查

1、upstream模块

  upstream模块允许Nginx定义一组或多组节点服务器组，使用时可以通过proxy_pass代理方式把网站的请求发送到事先定义好的对应upstream组的名字上，具体写法为：

proxy_pass http://www_server_pools

其中www_server_pools就是一个upstream节点服务器组名字，例如：

upstream www_server_pools {
server 10.0.0.17:80 weight=5;
server 10.0.0.17:80 weight=1max_fails=1 fail_timeout=10s;#默认参数
server 10.0.0.18:80 weight=10max_fails=2 fail_timeout=20s backup;
server 10.0.0.19:82 weight=15;
server unix:/tmp/backend3;
}

  配置说明：

n  upstream模块的内容应放于nginx.conf配置的http标签内，默认调度节点算法是wrr（权重轮询，weighted round-robin）

n  server：负载均衡后面的rs配置，可以是ip或域名

n  weight：服务器的权重，默认值为1，越大表示接受的请求比例越大

n  max_fails：nginx尝试连接后端主机失败的次数，这个数值是配合proxy_net_upstream，fastcgi_next_upstream和memcached_next_upstream这三个参数来使用的，当nginx接收后端服务器返回这三个参数定义的状态码时，会将这个请求转发给正常工作的后端服务器，例如404，502，503

n  backup：热备配置（rs节点的高可用），当前面激活的rs都失败后会自动启动用热备rs，这标志着这个服务器作为备份服务器，若主服务器全部宕机了，就会向它转发请求；当负载调度算法为ip_hash时，后端服务器在负载均衡调度中的状态不能是weight和backup

n  fail_timeout：在max_fails定义的失败次数后，距离下次检查的时间间隔，默认10s

n  down：表示服务器永远不可用，可配合ip_hash使用

  对比haproxy的配置参数

server php_server_1 10.12.25.68:80 cookie 1 checkinter 2000 rise 3 fall 3 weight 2

server php_server_2 10.12.25.72:80 cookie 2 checkinter 2000 rise 3 fall 3 weight 1

server php_server_bak 10.12.25.79:80 cookie 3 checkinter 1500 rise 3 fall 3 backup

n  weight：权重，同nginx

n  check：开启对该服务器健康检查

n  inter：设置连续两次的健康检查间隔时间，单位毫秒，默认值2000

n  rise：指定多少次连续成功的健康检查后，即可认定该服务器处于可用状态

n  fall：指定多少次不成功的健康检查后，即认为服务器为宕机状态，默认值为3

n  maxconn：指定可并发送到该服务器的最大并发连接数

1.1 upstream模块调度算法

  调度算法一般分为两类：

n  第一类为静态调度算法，即负载均衡器根据自身设定的规则进行分配，不需要考虑后端节点服务器的情况，例如rr,wrr,ip_hash等

n  第二类为动态调度算法，即负载均衡器会根据后端节点的当前状态来决定是否分发请求，例如：连接数少的优先获的请求，响应时间短的优先获得请求，例如：least_conn，fair等

  常见的调度算法

n  rr轮询：round-robin，默认调度算法，静态调度算法，按照客户端请求顺序逐一分配到不同的后端节点服务器，宕机的服务器会被自动从节点服务器池中剔除。

n  wrr权重轮询：静态调度算法，在rr轮询算法的基础上加上权重，权重和用户访问成正比，权重值越大，被转发的请求也就越多

n  ip_hash：静态调度算法，每个请求按客户端IP的Hash值分配，当新的请求到达时，先将其客户端IP通过哈希算法计算出一个值，在随后的客户端请求中，客户端IP的哈希值只要相同，就会被分配到同一台服务器，可以解决动态网页的session共享问题，但也会引起分配不均的弊端

n  fair：动态调度算法，此算法会根据后端节点服务器的响应时间来分配请求，响应时间短的优先分配，可以依据页面大小和加载时间舱段智能地进行负载均衡，也就是根据后端服务器的响应时间来分配请求，响应时间短的优先分配。需要下载Nginx的相关模块upstream_fair

n  least_conn：根据后端节点的连接数来决定分配情况，哪个机器连接数少就分发

n  url_hash：根据访问URL的hash结果来分配请求的，让每个URL定向到同一个后端服务器，后端服务器为缓存服务器时效果显著，如果需要使用这种调度算法，必须安装Nginx的hash模块软件包

n  一致性hash：一般用于代理后端业务为缓存服务（squid，memcached）的场景，通过将用户请求的uri或者指定字符串进行计算，然后调度到后端的服务器上，此后任何用户查找同一个uri或者指定字符串都会被调度到这一台服务器上，因此后端的每个节点缓存的内容都是不同的，一致性hash算法可以解决后端某个或者几个节点宕机后，缓存的数据动荡最小

1.2 一致性hash简介

  在分布式集群中，对机器的添加删除，或者机器故障后自动脱离集群这些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法，那么在有机器添加或者删除后，很多原有的数据就无法找到了，这样严重的违反了单调性原则

  按照常用的hash算法来将对应的key哈希到一个具有2^32次方个桶的空间中，即0~(2^32)-1的数字空间中，将这些数字头尾相连，想象成一个闭合的环形，如图2-1

  将所要存储的资源和服务器经过hash映射到哈希环上，然后以顺时针的方向计算，将所有资源存储到离自己最近的机器中。

  删除一个节点时，如图2-1右下部分，原本该节点上存储的资源将会被迁移到顺时针方向的下一个节点中，这样仅仅是该节点上的资源的映射位置发生了变化，其它的对象没有任何的改动

  新增一个节点时，如图2-1左下部分，在新增节点之前的资源，通过按顺时针迁移的规则，被保存迁移到新节点中，其它对象还保持这原有的存储位置。

  通过对节点的添加和删除的分析，一致性哈希算法在保持了单调性的同时，还是数据的迁移达到了最小，这样的算法对分布式集群来说是非常合适的，避免了大量数据迁移，减小了服务器的压力。

图2-1 一致性hash算法示意图

2、http_proxy_module模块

  proxy_pass指令属于ngx_http_proxy_module模块，此模块可以将请求转发到另一台服务器，在实际的反向代理工作中，会通过location功能匹配指定的uri，然后把接收到的符合匹配URI的请求通过proxy_pass抛给定义好的upstream节点池

  简单配置实例

location /name/ {
    proxy_passhttp://127.0.0.1/remote/;
}

  模块参数

n  proxy_set_header：设置http请求header项传给后端服务器节点，例如，可以实现让代理后端的服务器节点获取访问客户端用户真实的IP地址

n  client_body_buffer_size：用于指定客户端请求主题缓冲区大小

n  proxy_connect_timeout：表示反向代理与后端节点服务器连接的超时时间，即发起握手等候响应的超时时间

n  proxy_send_timeout：表示代理后端服务器的数据回传时间，即在规定时间之内，后端服务器必须传完所有的数据，否则，nginx将断开这个连接

n  proxy_read_timeout：设置nginx从代理的后端服务器获取信息的时间，表示连接建立成功后，Nginx等待后端服务器的响应时间，其实是nginx已经后端的排队之中等候处理的时间

n  proxy_buffer_size：设置缓冲区大小，默认该缓冲区大小等于指令proxy_buffers设置的大小

n  proxy_buffers：设置缓冲区的数量和大小，nginx从代理的后端服务器获取的响应信息，会放置在缓冲区

n  proxy_busy_buffers_size：用于设置系统很忙时可以使用的proxy_buffers大小，官方推荐的大小为proxy_bufer*2

n  proxy_temp_file_write_size：指定proxy缓存临时文件的大小

2.1 多虚拟机主机代理

  在多虚拟主机的环境下，当用户访问域名时，反向代理向下面节点重新发起请求时，默认并没有在请求头里告诉节诶点服务器要找哪台虚拟主机，所以web节点服务器接收到请求后发现没有主机头信息，因此，就把节点服务器上配置的第一个虚拟主机发给了反向代理。

  解决方案：在Nginx代理虚拟主机配置里增加如下内容：

worker_processes 1;
events {
   worker_connections  1024;
}
http {
   include       mime.types;
   default_type application/octet-stream;
   sendfile        on;
    keepalive_timeout  65;
    upstreamwww_server_pools {
    server 10.0.0.7:80 weight=1;
    server 10.0.0.8:80 weight=1;
}
    server {
       listen       80;
       server_name  www.etiantian.org;
       location / {
           proxy_pass http://www_server_pools;
           proxy_set_header Host $host;
        }
    }
｝

2.2 反向代理记录用户IP

  默认情况，节点服务器对应的www虚拟主机的访问日志的第一个字段记录的并不是客户达un的IP，而是反向代理服务器的IP

  解析方案，在Nginx代理虚拟主机配置中增加如下内容

worker_processes 1;
events {
   worker_connections  1024;
}
http {
   include       mime.types;
   default_type application/octet-stream;
   sendfile        on;
   keepalive_timeout  65;
    upstreamwww_server_pools {
    server10.0.0.7:80 weight=1;
    server10.0.0.8:80 weight=1;
}
    server {
        listen       80;
       server_name  www.etiantian.org;
       location / {
           proxy_pass http://www_server_pools;
           proxy_set_header Host $host;
                      proxy_set_header X-Forwarded-For$remote_addr;
        }
    }
｝

#www节点服务器配置文件在http模块下增加如下内容
   log_format main ‘$remote_addr - $remote_user [$time_local]"$request" ‘
                   ‘$status $body_bytes_sent "$http_referer" ‘
                   ‘"$http_user_agent" "$http_x_forwarded_for" ‘

;

  如果是apache作为反向代理节点，则配置文件作如下修改：

LogFormat "\"%{X-Forwarded-For}i\ %l %u%t \"%r\" %>s %b \"%{Referer}i\"\"%{User-Agent}i\"" common
#LogFormat "%h %l %u %t \"%r\" %>s %b" common

本文出自 “宋某人c” 博客，请务必保留此出处http://syaving.blog.51cto.com/5614476/1878731