目前有许多不同的负蝲均衡技术用以满不同的应用需求,如Y/g负蝲均衡、本?全局负蝲均衡、更高网l层负蝲均衡Q以及链路聚合技术?/p>
我们使用的是软负载均衡器Nginx,而农行用的是F5负载均衡器Q这里就单介l下q两U技术:
a.软g负蝲均衡解决Ҏ
在一台服务器的操作系l上Q安装一个附加Y件来实现负蝲均衡Q如Nginx负蝲均衡Q我们管理系l^C用的也是q款均衡器)。它的优ҎZ特定环境、配|简单、用灵zR成本低廉,可以满大部分的负蝲均衡需求?/p>
一、什么是Nginx
Nginx ("engine x") 是一个高性能?HTTP ?反向代理 服务器,也是一?IMAP/POP3/SMTP 代理服务器?可以说Nginx 是目前用最为广泛的HTTP软负载均衡器Q其源代码以类BSD许可证的形式发布Q商业友好)Q同时因高效的性能、稳定性、丰富的功能集、示例配|文件和低系l资源的消耗而闻名于业界。像腾讯、淘宝、新等大型门户及商业网站都采用Nginxq行HTTP|站的数据分?/p>
二、Nginx的功能特?/p>
1、工作在|络?层之上,可以针对http应用做一些分的{略Q比如针对域名、目录结构;
2、Nginx对网l的依赖比较;
3、Nginx安装和配|比较简单,试h比较方便Q?/p>
4、也可以承担高的负蝲压力且稳定,一般能支撑过1万次的ƈ发;
5、Nginx可以通过端口到服务器内部的故障Q比如根据服务器处理|页q回的状态码、超时等{,www.linuxidc.com q且会把q回错误的请求重新提交到另一个节点,不过其中~点是不支持url来检;
6、Nginx对请求的异步处理可以帮助节点服务器减轻负载;
7、Nginx能支持http和EmailQ这样就在适用范围上面很多;
8、不支持Session的保持、对Big request header的支持不是很好,另外默认的只有Round-robin和IP-hash两种负蝲均衡法?/p>
三、Nginx的原?/p>
Nginx采用的是反向代理技术,代理服务器来接受internet上的q接hQ然后将h转发l内部网l上的服务器Qƈ从服务器上得到的结果返回给internet上请求连接的客户端,此时代理服务器对外就表现Z个服务器。反向代理负载均衡技术是把将来自internet上的q接h以反向代理的方式动态地转发l内部网l上的多台服务器q行处理Q从而达到负载均衡的目的?/p>
b.g负蝲均衡解决Ҏ
直接在服务器和外部网l间安装负蝲均衡讑֤Q这U设备我们通常UC载均衡器。由于专门的讑֤完成专门的Q务,独立于操作系l,整体性能得到大量提高Q加上多样化的负载均衡策略,化的量理Q可辑ֈ最佳的负蝲均衡需求?一般而言Q硬件负载均衡在功能、性能上优于Y件方式,不过成本昂贵Q比如最常见的就是F5负蝲均衡器?/p>
什么是F5 BIG-IP
F5负蝲均衡器是应用交付|络的全球领DF5 Networks公司提供的一个负载均衡器专用讑֤QF5 BIG-IP LTM 的官方名U叫做本地流量管理器Q可以做4-7层负载均衡,h负蝲均衡、应用交换、会话交换、状态监控、智能网l地址转换、通用持箋性、响应错误处理、IPv6|关、高U\由、智能端口镜像、SSL加速、智能HTTP压羃、TCP优化、第7层速率整Ş、内容缓册Ӏ内容{换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒l服?DoS)d和SYN Flood保护、防火墙—包过滤、包消毒{功能?/p>
以下是F5 BIG-IP用作HTTP负蝲均衡器的主要功能Q?/p>
①、F5 BIG-IP提供12U灵zȝ法所有流量均衡的分配到各个服务器Q而面对用P只是一台虚拟服务器?/p>
②、F5 BIG-IP可以认应用E序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障QF5会检查出来ƈ该服务器标识ؓ宕机Q从而不用L讉Kh传送到该台发生故障的服务器上。这P只要其它的服务器正常Q用L讉K׃会受到媄响。宕Z旦修复,F5 BIG-IP׃自动查证应用已能对客戯求作出正响应ƈ恢复向该服务器传送?/p>
③、F5 BIG-IPh动态Session的会话保持功能?/p>
④、F5 BIG-IP的iRules功能可以做HTTP内容qoQ根据不同的域名、URLQ将讉Kh传送到不同的服务器?/p>
Ҏ优缺点对?/p>
Zg的方?F5)
优点Q能够直接通过交换机实?处理能力更强Q而且与系l无养I负蝲性能强更适用于一大堆讑֤、大讉K量、简单应?/p>
~点Q成本高Q除讑֤h高昂Q而且配置冗余Q很难想象后面服务器做一个集,但最关键的负载均衡设备却是单炚w|;无法有效掌握服务器及应用状?
g负蝲均衡Q一般都不管实际pȝ与应用的状态,而只是从|络层来判断Q所以有时候系l处理能力已l不行了Q但|络可能q来 得及反应Q这U情况非常典型,比如应用服务器后面内存已l占用很多,但还没有d不行Q如果网l传输量不大未必在|络层能反映出来Q?/p>
Z软g的方?Nginx)
优点Q基于系l与应用的负载均衡,能够更好地根据系l与应用的状冉|分配负蝲。这对于复杂应用是很重要的,性h比高Q实际上如果几台服务器,用F5之类的硬件品显得有些浪费,而用软gp合算得多Q因为服务器同时q可以跑应用做集等?/p>
~点Q负载能力受服务器本w性能的媄响,性能好Q负载能力越大?/p>
lDQ对我们理pȝ应用环境来说Q由于负载均衡器本n不需要对数据q行处理Q性能瓉更多的是在于后台服务器,通常采用软负载均衡器已非常够用且其商业友好的软g源码授权使得我们可以非常灉|的设计,无逢的和我们管理系l^台相l合?/p>
而这一pd的相关的交互q程可能是由客户到服务器的一个连接的多次会话完成Q也可能是在客户与服务器之间的多个不同连接里的多ơ会话完成。不同连接的多次会话Q最典型的例子就是基于http的访问,一个客户完成一W交易可能需多次点击Q而一个新的点M生的hQ可能会重用上一ơ点d立v来的q接Q也可能是一个新建的q接?/p>
会话保持是指在负蝲均衡器上有这么一U机Ӟ可以识别做客户与服务器之间交互过E的兌性,在作负蝲均衡的同Ӟq保证一pd相关q的讉Kh会保持分配到一台服务器上?/p>
2QF5支持什么样的会话保持方法?
F5 Big-IP支持多种的会话保持方法,其中包括Q简单会话保持(源地址会话保持Q、HTTP Header的会话保持,ZSSL Session ID的会话保持,i-Rules会话保持以及ZHTTP Cookie的会话保持,此外q有ZSIP ID以及Cache讑֤的会话保持等Q但常用的是单会话保持,HTTP Header的会话保持以?HTTP Cookie会话保持以及Zi-Rules的会话保持?/p>
2.1 单会话保?br /> 单会话保持也被称为基于源地址的会话保持,是指负蝲均衡器在作负载均衡时是根据访问请求的源地址作ؓ判断兌会话的依据。对来自同一IP地址的所有访?h在作负蝲均时都会被保持到一台服务器上去。在BIG-IP讑֤上可以ؓ“同一IP地址”通过|络掩码q行区分Q比如可以通过对IP地址 192.168.1.1q行255.255.255.0的网l掩码,q样只要是来自于192.168.1.0/24q个|段的流量BIGIP都可以认Z们是来自于同一个用Pq样将把来自于192.168.1.0/24|段的流量会话保持到特定的一台服务器上?/p>
单会话保持里另外一个很重要的参数就是连接超时|BIGIP会ؓ每一个进行会话保持的会话讑֮一个时间|当一个会话上一ơ完成到q个会话下次再来之前的间隔如果小于这个超时|BIGIP会新的连接进行会话保持,但如果这个间隔大于该时|BIGIP会新来的q接认ؓ是新的会话然后进行负载^衡?/p>
Z原地址的会话保持实现v来简单,只需要根据数据包三、四层的信息可以实玎ͼ效率也比较高。存在的问题在于当多个客户是通过代理或地址转换的方式来讉K服务器时Q由于都分配到同一台服务器上,会导致服务器之间的负载严重失衡。另外一U情况上客户机数量很,但每个客h都会产生多个q发讉KQ对q些q发讉K也要求通过负蝲均衡器分配到多个服器上,q时Z客户端源地址的会话保持方法也会导致负载均衡失效?/p>
2.2 ZCookie的会话保?br />2.2.1 Cookie插入模式Q?br /> 在Cookie插入模式下,Big-IP负责插入cookieQ后端服务器无需作出M修改
当客戯行第一ơ请求时Q客户HTTPhQ不带cookieQ进入BIG-IPQ?BIG-IPҎ负蝲q法{略选择后端一台服务器Qƈ请求发送至该服务器Q后端服务器q行HTTP回复Q不带cookieQ被发回BIGIPQ然?BIG-IP插入cookieQ将HTTP回复q回到客L。当客户h再次发生Ӟ客户HTTPhQ带有上ơBIGIP插入的cookieQ进?BIGIPQ然后BIGIPdcookie里的会话保持数|HTTPhQ带有与上面同样的cookieQ发到指定的服务器,然后后端服务器进行请求回复,׃服务器ƈ不写入cookieQHTTP回复不带有cookieQ恢复流量再ơ经q进入BIG-IPӞBIG-IP再次写入更新后的会话保持 cookie?/p>
2.2.2 Cookie 重写模式
当客戯行第一ơ请求时Q客户HTTPhQ不带cookieQ进入BIGIPQ?BIGIPҎ负蝲均衡法{略选择后端一台服务器Qƈ请求发送至该服务器Q后端服务器q行HTTP回复一个空白的cookieq发回BIGIPQ然后BIGIP重新在cookie里写入会话保持数|HTTP回复q回到客L。当客户h再次发生Ӟ客户HTTPhQ带有上ơBIGIP重写?cookieQ进入BIGIPQ然后BIGIPdcookie里的会话保持数|HTTPhQ带有与上面同样的cookieQ发到指定的服务器,然后后端服务器进行请求回复,HTTP回复里又带有空的cookieQ恢复流量再ơ经q进入BIGIPӞBIGIP再次写入更新后会话保持数值到?cookie?/p>
2.2.3 Passive Cookie 模式Q服务器使用特定信息来设|cookie?br /> 当客戯行第一ơ请求时Q客户HTTPhQ不带cookieQ进入BIGIPQ?BIGIPҎ负蝲q法{略选择后端一台服务器Qƈ请求发送至该服务器Q后端服务器q行HTTP回复一个cookieq发回BIGIPQ然?BIGIP带有服务器写的cookie值的HTTP回复q回到客L。当客户h再次发生Ӟ客户HTTPhQ带有上ơ服务器写的cookieQ进?BIGIPQ然后BIGIPҎcookie里的会话保持数|HTTPhQ带有与上面同样的cookieQ发到指定的服务器,然后后端服务器进行请 求回复,HTTP回复里又带有更新的会话保持cookieQ恢复流量再ơ经q进入BIGIPӞBIGIP带有该cookie的请求回复给客户端?/p>
2.2.4 Cookie Hash模式Q?br /> 当客戯行第一ơ请求时Q客户HTTPhQ不带cookieQ进入BIGIPQ?BIGIPҎ负蝲均衡法{略选择后端一台服务器Qƈ请求发送至该服务器Q后端服务器q行HTTP回复一个cookieq发回BIGIPQ然?BIGIP带有服务器写的cookie值的HTTP回复q回到客L。当客户h再次发生Ӟ客户HTTPhQ带有上ơ服务器写的cookieQ进?BIGIPQ然后BIGIPҎcookie里的一定的某个字节的字节数来决定后台服务器接受hQ将HTTPhQ带有与上面同样的cookieQ发到指定的服务器,然后后端服务器进行请求回复,HTTP回复里又带有更新后的cookieQ恢复流量再ơ经q进入BIGIPӞBIGIP带有该 cookie的请求回复给客户端?/p>
2.3 SSL Session ID会话保持
在用LSSL讉Kpȝ的环境里Q当SSL对话首次建立Ӟ用户与服务器q行首次信息交换以:1}交换安全证书Q?Q商议加密和压羃ҎQ?Qؓ每条对话 建立Session ID。由于该Session ID在系l中是一个唯一数|由此QBIGIP可以应用该数值来q行会话保持。当用户想与该服务器再次建立q接ӞBIGIP可以通过会话中的 SSL Session ID识别该用户ƈq行会话保持?/p>
ZSSL Session ID的会话保持就需要客h览器在进行会话的q程中始l保持其SSL Session ID不变Q但实际上,微YInternet Explorer被发现在l过特定一D|间后主动改变SSL Session IDQ这׃ZSSL Session ID的会话保持实际应用范围大大羃?/p>