2023年6月25日发(作者:)
nginx如何做到TCP的负载均衡原⽂:
TCP 的 负载均衡
这个⽚段描述了如何通过nginx plus进⾏负载均衡
在版本5中,nginx plus 能够代理和负载均衡通过TCP路径,TCP对于⼀些流⾏应⽤和服务是⼀个协议:LDAP、MYSQL、RTMP
stream 模块
TCP 负载均衡被nginx的三个模块所实现,⽽且这些模块被嵌⼊在nginx plus中。它们定义的命令是在stream配置块中: :定义基本的命令来激活这个TCP通信过程 :定义这个命令是为了进⾏TCP代理通信 :定义这个命令是为了TCP的负载均衡的先决条件nginx plus 版本5(具备基本功能)或者版本6(在这个⽂章有描述的功能)⼀个应⽤、数据库、服务进⾏通信都是通过TCP的⽅式负载均衡服务中的每个服务都需要运⾏⼀个实例配置TCP负载均衡
负载均衡涉及到了⾼效的分发⽹络到后台服务,要配置负载均衡,需要执⾏下⾯的技术:1.
2.
3.
4.
创建最⾼级别的stream(与http同⼀级别)上下⽂在nginx plus配置当中。定义⼀个upstream组,由多个服务组成达到负载均衡定义⼀个服务⽤来监听TCP连接,并且把他们代理到⼀个upstream组中配置负载均衡的⽅法和参数为每个server;配置些如:连接数、权重、等等创建⼀个upstream组
⾸先创建⼀个server组,⽤来作为TCP负载均衡组。定义⼀个upstream块在stream上下⽂中在这个块⾥⾯添加由server命令定义的server,指定他的IP地址和主机名(能够被解析成多地址的主机名),和端⼝号。注意:你不能为每个server定义协议,因为这个stream命令建⽴TCP作为整个server的协议了。下⾯的例⼦是建⽴⼀个被称之为stream_backend组,两个监听12345端⼝的server,⼀个监听12346端⼝。
stream { upstream stream_backend { server :12345 weight=5; server :12345; server :12346; }}
下⾯的⽚段中,你定义每个server为单独的组中。然后你能⾃定义upstream组的配置,⽽这些组是通过负载均衡的算法来进⾏分组的,或者是能健康的管理。. See 和后续的⽚段.
TCP的代理通信
配置反向代理使nginx plus能够把TCP请求从⼀个客户端转发到负载均衡组中。在每个server配置块中通过每个虚拟server的server的配置信息和在每个server中定义的监听端⼝的配置信息和proxy_passs命令把TCP通信发送到哪个server中去。
stream { server { listen 12345; proxy_pass stream_backend; }}
⼀个另类的⽅式是代理TCP通信到单⼀的server中⽽不是server组中。假如你的server的唯⼀标识是通过主机,⽽且你的主机名是可以解析成多个IP地址的话,然⽽nginx的负载均衡通信通过使⽤round-robin算法得到的IP⽅式。在这种情况下,你必须还要附加端⼝号来标识到底哪个server来处理的。
stream { server { listen 12345; proxy_pass :12345; }}
改变负载均衡的⽅法
默认nginx plus是通过轮询算法来进⾏负载均衡的通信的。引导这个请求循环的到配置在upstream组中server端⼝上去。因为他是默认的⽅法,这⾥没有轮询命令,只是简单的创建⼀个upstream配置组在这⼉stream⼭下⽂中,⽽且在其中添加server。
upstream backend { server :12345 weight; server :12345; server :12345;}
配置不同的负载均衡的算法,囊括在upstream配置块中。1. :对于每个请求,nginx plus选择当前连接数最少的server来处理upstream stream_backend { least_conn;
server :12345 weight=5; server :12345; server :12346;}
2. :对于每个链接,nginx pluns 通过⼏点来选择server的:最底平均延时:通过包含在least_time命令中指定的参数计算出来的:1. connect:连接到⼀个server所花的时间2. first_byte:接收到第⼀个字节的时间3. last_byte:全部接收完了的时间最少活跃的连接数
upstream stream_backend { least_time first_byte;
server :12345 weight=5; server :12345; server :12346;}
3. 普通的hash算法:nginx plus选择这个server是通过user_defined 关键字,就是IP地址:$remote_addr;
upstream stream_backend { hash $remote_addr consistent;
server :12345 weight=5;server :12345;server :12346;}这个可选的consistent参数应⽤这个⼀致性hash算法,这种⽅法能减少使由于server添加或者删除导致的关键字映射到其他服务器上的可能性。
配置session的持久化
配置session的持久化使⽤hash负载均衡的⽅式在前⾯已经描述了。因为hash函数是建⽴在客户端的IP地址上的,所以TCP请求从⼀个到同样⼀个server是⾮常可能的,除⾮这个server不可⽤了
限制连接数
可以设置nginx plus与server所建⽴的连接数:server max_conns=?upstream stream_backend { server :12345 weight=5; server :12345; server :12346 max_conns=4;}
不好的健康监测 假如连接⼀个server超市了或者导致⼀个错误,nginx plus标识这个server是⽆效的和阻⽌请求到那个server上去,在⼀段时间内。下⾯的参数是⽤来判断哪些server才算是不可达的: :在这个时间段中进⾏了多少次连接的尝试失败了,那么就认为是不可达了并标记不可达 :和上⾯是对应上的。默认是在10秒钟进⾏1次尝试。在10秒进⾏⾄少⼀次尝试是失败的,那么nginx则认为这个server是不可达的下⾯的例⼦中要求是:30s进⾏2次尝试失败认为server不可达upstream stream_backend { server :12345 weight=5; server :12345 max_fails=2 fail_timout=30; //当个server的不健康的监测 server :12346 max_conns=4;}
好的健康监测
当你进⾏健康监测的时,nginx plus平凡的进⾏TCPupstream的server的测试通过响应为了避免失败。健康监测可以配置成监测失败类型的范围。
how it works?nginx plus 发送⼀个健康监测请求到每个TCP upstream server中去,监测响应是否满⾜这个指定的条件,假如⼀个连接不能连接到某个server当中去,这个健康监测就会失败,这个server将会被考虑成不监控了。nginx plus就不会代理客户端连接到不健康的server中去,假如⼏个server被监测为健康的,那么相反的server就是不健康的了
先决条件:你已经定义了⼀组server在stream上下⽂中:例如:stream { upstream stream_backend { server :12345;
server :12345;
server :12345; }}
你也做好了定义⼀个TCP连接的代理serverserver { listen 12345; proxy_pass stream_backend;}
基本的配置1. 添加⼀个zone命令在upstream中,这个zone定义的⼤⼩是⽤来给worker processes存放connections和counters⽤的stream { upstream stream_backend { zone stream_backend 64k; server :12345; .......... }}2. 添加 and 命令到代理的server中去、server { listen 12345; proxy_pass strean_backend; health_check; health_check_timeout 5s;}这个health_check命令将会激活这个健康监测功能,当⼜health_check_timeout 将会覆盖掉这个proxy_timeout的值,作为健康监测超时时间应该是显著缩短。fine-tuning 健康监测
默认,nginx plus试着再每5s中连接每个server在upstream server组中。假如连接不能够被建⽴,nginx plus认为这个健康监测失败,标识他为不健康。停⽌连接该server。改变默认的⾏为,包括的参数如下:interval :多少秒会发送健康请求passses : 多少连续的响应才算被考虑为健康的fails :多少次连续的失败响应才考虑为不健康的server { listen 12345; proxy_pass stream_backend; health_check insterval=10 passes=2 fails=3; //整体server检测}在这个例⼦中这个时间周期变成了10s;三次连续⽆响应被考虑为不健康,假如连续两次检测正常可能为server正常
fine-tuning health check with the macth configuration block
定义⼀些测试的种类去验证server响应从⽽达到server是否健康,定义这些种类在⼀个match的配置块中这个match在stream上下⽂中;使⽤下⾯的参数在match块中是需要的⽬的为了health_check⽽定制的条件send :发送到server的字符创expect :返回的数据必须匹配这个正则表达式这些参数可以随意的组合,但是不会超过⼀个send或者⼀个expect参数同⼀时间内,下⾯是这两个参数的搭配:既没有send也没有expect参数被指定。连接server的能⼒是测试的指定了expect,然后server被期待⽆条件的发送⼀条数据过来match pop3 { expect ~*"+OK";}send被指定,然后期待连接将会成功的建⽴,指定的字符串会被发送到server端match pop_quit { send QUIT;}假如两个都有,那么这个发送参数返回的值必须匹配这个expect指定的正则stream { upstream stream_backend { zone upstream_backend 64k; server :12345; } match http { send "GET / HTTP/1.0rnHost:localhostrnrn" expect ~*"200 OK"; }
server { listen 12345; health_check match=http; proxy_pass stream_backend;
}
}
运⾏时的重新配置
upstream 服务组能够⾮常容易的重配在运⾏的时候通过⼀个简单的http接⼝,使⽤这个接⼝,你将会能够看到所有的服务,某个服务的详细信息,或者对server的增删。为了能够在运⾏时重配,你需要如下条件:
授予访问upstream_conf handler -a 特殊的handler权限;handler能够检查和重配upstream组在nginx plus中。作如上的操作需要在http 快中,使⽤upstream_conf命令 在⼀个分开的location中对于访问这个location需要限定。http { server { location /upstream_conf { upstream_conf;
allow 127.0.0.1; #permit access from localhost deny all;#deny; access from everywhere else } }}
在这个stream块中,指定zone对于这个server组来说需要;这个命令将会创建⼀个zone⼤⼩的在共享内存当中,在⾥⾯保存了server组的配置;这样所有的workprocesses就能够共享同⼀个配置了。
stream { ... #Configuration of an upstream server group upstream appservers { zone appservers 64k;
server :12345 weight=5; server :12345 fail_timeout=5s;
server :12345 backup; server :12345 backup; }
server { #server that proxies connections to the upstream proxy_pass appservers; lealth_check; }}
http {... server { #location for configuration requests
location /upstream_conf { upstream_conf; allow 127.0.0.1; deny all; } }
}
这⾥,想访问这个location只有是本地的IP才可以,⽽其他的IP都被屏蔽了。想发送⼀个配置命令到nginx中,发送⼀个http请求可以带很多配置信息。这个请求应该应该有⼀个适合的uri进⼊到包含了upstream_conf的location中,这个请求应该包括了设置server组的upstream的参数。
例如:查看所有的备份server,对于这server来说就是:127.0.0.1/upstream_conf?stream=&upstream=appservers&backp=
增加⼀个新的server到组中,发送⼀个请求携带了add和server参数:127.0.0.1/upstream_conf?stream=&add=&upstream=appservers&server=:12345&weight=2&max_fails=3
移除⼀个server,发送⼀个请求携带remove命令和server唯⼀标识的参数ID
去修改⼀个特定的server参数,发送⼀个请求携带ID和参数信息
tcp load balancing 配置例⼦
这个配置例⼦是TCP负载均衡的例⼦在nginx plus中的
stream {
upstream stream_backend { least_conn; server :12345 weight=5; server :12345 max_fail=2 fail_timeout=30s; server :12346 max_conns =3; }
server { listen 12345; proxy_connect_timeout 1s; proxy_timeout 3s; proxypass stream_backend ;
}
server { listen 12346; proxy_pass :12346; }}
在这个例⼦中,有两个servers 他们被定义在server块中。所有的TCP代理相关的函数都被定义在stream块中像http块⼀样对待http请求的处理。
这第⼀个server监听12345端⼝⽽且代理所有的TCP连接到这个被命令为backend组中server。注意这个proxy_pass命令定义这个stream模块的上下⽂必须不包含协议。这两个可选的timeout参数被指定如下含义:proxy_connect_timeout设置建⽴⼀个连接与某个server的请求的超时时间,⽽proxy_time是代理已经建⽴之后的超时时间。
这个backend组由三个运⾏同样内容的,每个server命令后缀⼀个固定的端⼝号。连接被分配到每个server中去,⽽这种分配⽅式是:最少连接数。
这第⼆个虚拟server监听在12346端⼝号上,并且代理TCP连接到backend4逻辑server上,这个server或许被解析到⼀个serverIP上,⽽且这个地址将会做轮询的⽅式负载均衡。
发布者:admin,转转请注明出处:http://www.yc00.com/web/1687691627a32092.html
评论列表(0条)