马嘎尔尼拼音:关于负载均衡器：透明代理vs.会话保持、实现原理、代理vs透明模式...3_【虎.无名】摘...

【虎.无名】对于负载均衡器，实现透明代理比较简单，但是如果需要保持会话（即，有服务器粘连性）则比较困难了。是购买昂贵的硬件负载均衡器？自定义实现会话保持？还是消除服务器粘连性？。。。这是一个问题。
http://blog.chinaunix.net/u/15921/showart_1134278.html 负载均衡器;BIG-IP
发表于： 2008-08-19，修改于： 2008-08-19 23:30，已浏览153次，
负载均衡器是一种采用各种分配算法把网络请求分散到一个服务器集群中的可用服务器上去，通过管理进入的Web数据流量和增加有效的网络带宽，从而使网络访问者获得尽可能最佳的联网体验的硬件设备。
负载均衡器有多种多样的形式，除了作为独立意义上的负载均衡器外，有些负载均衡器集成在交换设备中，置于服务器与Internet链接之间，有些则以两块网络适配器将这一功能集成到PC中，一块连接到Internet上，一块连接到后端服务器群的内部网络上。
一般而言，硬件负载均衡在功能、性能上优于软件方式，不过成本昂贵。当Web服务器为图像服务、SSL（安全套接层）会话或数据库事务而进行优化时，负载均衡器可以体现特别的价值。
目前，许多厂商推出了专用于平衡服务器负载的负载均衡器，如F5 Network公司的BIG-IP，Citrix公司的NetScaler。F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。以下是F5 BIG-IP用作HTTP负载均衡器的主要功能：①、F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。②、F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。③、F5 BIG-IP具有动态Session的会话保持功能。④、F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
http://qzone.qq.com/blog/1663498-1223166548 F5负载均衡器会话保持技术及原理
发表时间： 2008年10月05日 08时29分
1．什么是会话保持？
在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。
而这一系列的相关的交互过程可能是由客户到服务器的一个连接的多次会话完成，也可能是在客户与服务器之间的多个不同连接里的多次会话完成。不同连接的多次会话，最典型的例子就是基于http的访问，一个客户完成一笔交易可能需多次点击，而一个新的点击产生的请求，可能会重用上一次点击建立起来的连接，也可能是一个新建的连接。
会话保持就是指在负载均衡器上有这么一种机制，可以识别做客户与服务器之间交互过程的关连性，在作负载均衡的同时，还保证一系列相关连的访问请求会保持分配到一台服务器上。
2． F5支持什么样的会话保持方法？
F5 BigIP支持多种的会话保持方法，其中包括：简单会话保持（源地址会话保持）、HTTP Header的会话保持，基于SSL Session ID的会话保持，I-Rules会话保持以及基于 HTTP Cookie的会话保持，此外还有基于SIP ID以及Cache设备的会话保持等，但常用的是简单会话保持，HTTP Header的会话保持以及 HTTP Cookie会话保持以及基于I-Rules的会话保持。
2.1 简单会话保持
简单会话保持也被称为基于源地址的会话保持，是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去。在BIGIP设备上可以为“同一IP地址”通过网络掩码进行区分，比如可以通过对IP地址192.168.1.1进行255.255.255.0的网络掩码，这样只要是来自于192.168.1.0/24这个网段的流量BIGIP都可以认为他们是来自于同一个用户，这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上。
简单会话保持里另外一个很重要的参数就是连接超时值，BIGIP会为每一个进行会话保持的会话设定一个时间值，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，BIGIP将会将新的连接进行会话保持，但如果这个间隔大于该超时值，BIGIP将会将新来的连接认为是新的会话然后进行负载平衡。
基于原地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些必发访问也要求通过负均均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。
2.2 基于Cookie的会话保持
2.2.1 cookie插入模式：
在Cookie插入模式下，BigIP将负责插入cookie，后端服务器无需作出任何修改.当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回BIGIP，然后BIGIP插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP插入的cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP回复将不带有cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后的会话保持cookie。
2.2.2 Cookie 重写模式
当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个空白的cookie并发回BIGIP，然后BIGIP重新在cookie里写入会话保持数值，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次BIGIP重写的cookie）进入BIGIP，然后BIGIP读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有空的cookie，恢复流量再次经过进入BIGIP时，BIGIP再次写入更新后会话保持数值到该cookie。
2.2.3 Passive Cookie 模式，服务器使用特定信息来设置cookie。
当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入BIGIP，然后BIGIP根据cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新的会话保持cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。
2.2.4 Cookie Hash模式：
当客户进行第一次请求时，客户HTTP请求（不带cookie）进入BIGIP， BIGIP根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复一个cookie并发回BIGIP，然后BIGIP将带有服务器写的cookie值的HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次服务器写的cookie）进入BIGIP，然后BIGIP根据cookie里的一定的某个字节的字节数来决定后台服务器接受请求，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，HTTP回复里又将带有更新后的cookie，恢复流量再次经过进入BIGIP时，BIGIP将带有该cookie的请求回复给客户端。
2.3 SSL Session ID会话保持
在用户的SSL访问系统的环境里，当SSL对话首次建立时，用户与服务器进行首次信息交换以：1}交换安全证书，2）商议加密和压缩方法，3）为每条对话建立Session ID。由于该Session ID在系统中是一个唯一数值，由此，BIGIP可以应用该数值来进行会话保持。当用户想与该服务器再次建立连接时，BIGIP可以通过会话中的 SSL Session ID识别该用户并进行会话保持。
基于SSL Session ID的会话保持就需要客户浏览器在进行会话的过程中始终保持其SSL　Session ID不变，但实际上，微软Internet Explorer被发现在经过特定一段时间后将主动改变SSL Session ID，这就使基于SSL Session ID的会话保持实际应用范围大大缩小。
http://www.wangchao.net.cn/bbsdetail_1768366.html 第七层负载均衡器配置模式
在内容网络中，负载均衡器或XML交换机根据从应用层获取的各类详尽信息在Web服务器间智能地分配流量。内容网络的思想一度曾显得有些奢侈，而现在，对于一个设计良好的Web基础设施而言，内容网络已经是不可或缺的重要组成部分了。从一般商业应用到多媒体应用，内容网络都能胜任。
·基于业务感知的下一代网络服务质量管
·打造可靠的IP城域核心网
·内嵌RPR的第三代MSTP要害技术分析
·MSTP技术在城域传输网中的应用
·支撑系统承载网的整合
·软交换网络用户故障集中测试系统研究
·城域传输网络结构与发展分析
·城域传输网络业务结构特点与发展分析
·城域MSTP综合接入技术应用
·以太网大规模应用突破VLAN划分瓶颈
代理模式和透明模式的比较
在内容网络中，负载均衡器或XML交换机根据从应用层获取的各类详尽信息在Web服务器间智能地分配流量。第7层负载均衡器与老式的第4层负载均衡器最本质的区别在于，直接利用HTTP头信息、SSL SESSION ID、cookie以及URI这些第7层（应用层）数据。尽管第4层负载均衡器也能像第7层负载均衡器一样在多个Web服务器间分配内容，但它基于端口的流量分配方式使服务器群中的每个Web服务器都必须再生全部网页内容，显得很不经济。
两种工作模式
第7层负载均衡器有2种配置模式：代理模式（Proxy）和透明模式（transparent）。代理模式是指负载均衡器作为两个或多个Web服务器间的服务中介，所有发向网站的服务请求首先来到负载均衡器，由负载均衡器决定如何分配这些请求。在透明模式下，负载均衡器不断侦听网络，只对事先指定的某些特定服务的请求做出处理。
单路并联和双路并联拓扑结构(图)
在代理模式下，负载均衡器是Web服务器群的唯一入口，集中进行安全治理、统一处理登录请求。负载均衡器能够始终对多个服务器开放多个TCP会话，这样，负载均衡器在与每个服务器第二次交换TCP握手信号时就不再有延迟，所以，代理模式比透明模式在性能上要略胜一筹。
大多数的负载均衡器和XML交换机都支持代理模式。Netscaler公司的Request Switch 9000系列交换机在代理模式下工作时，既能进行HTTP识别，又能进行TCP会话，因此，能够利用既有的TCP连接处理HTTP1.1类型的服务请求。
假如要处理运行在Web上的SSL加解密会话，负载均衡器一般来说必须工作在代理模式下。负载均衡器能够自行对数据解密，也可以使用第三方的相关产品，解密后负载均衡器对流量进行检测，并做出路由选择，最后，用SSL把自己对客户端的响应进行加密。有些负载均衡器也可在透明方式下进行上述工作，但那样会产生更多的延迟。
串联式拓扑结构(图)
代理模式和透明模式的最显著区别是：在代理模式下，由负载均衡器结束会话，而在透明模式下，则由Web服务器结束会话。无论是哪种模式，都由负载均衡器决定由哪一台服务器处理客户端的请求。
三种布局方式
负载均衡器在网络中有三种布局方式，即：串联式（INLINE）、单路并联式（ONE-ARM）和双路并联式（SIDE-ARM）。
串联式：负载均衡器位于路由器和交换机之间，路由器和交换机分别与服务器群相连。这种拓扑结构的缺点显而易见：不管负载均衡器是否需要对某些流量进行检测，所有流量都要流经负载均衡器。假如该负载均衡器吞吐量较低，整个网络的性能就会变差。在代理模式下，将负载均衡器进行串联配置是非常简单的，但在流量较大的网络中，这种配置需要另加一台负载均衡器作为备份，以防单点故障的发生。
单路并联和双路并联结构：负载均衡器配置在交换机的旁边，而不是夹在它们中间。单路并联和双路并联的区别在于负载均衡器和交换机的接口数不同。单路并联只有一个接口，双路并联则有两个。至于究竟采用单路并联还是双路并联，应该事先对通过交换机的流量进行评估。流量大，双路并联是最佳选择；流量小，单路并联也就够了。
负载均衡的备份问题
由于负载均衡器通常是Web服务器群的唯一入口，因此，部署负载均衡器之前，必须首先考虑好负载均衡器的备份问题。当主负载均衡器出现故障时，备份负载均衡器能立即接管工作。备份负载均衡器的配置方式有活动式（active-active）和旁路式(active-standby)两种。在活动式配置下，两台负载均衡器同时处理来自同一IP地址【同一IP？不同IP？后者可以用LVS来实现。】的服务请求，因此，除了在出现故障时响应延迟极短外，在平时，Web服务器还能够同时处理更多的客户请求。在旁路式配置下，主负载均衡器工作，备份负载均衡器仅在主负载均衡器出现故障时启动，启动时占用主负载均衡器的IP地址和MAC地址【典型的双机热备工作机制】。备份负载均衡器从故障发生开始到接管服务一般要有几秒钟的延迟，在这期间，客户的服务请求就会遭到拒绝。

负载均衡器硬件价格
http://product.it168.com/list/b/0462_1.shtml
http://product.enet.com.cn/price/productlist.jsp?categoryid=99384
http://www.myprice.com.cn/products/productlist287.html

http://blog.chinaunix.net/u1/55815/showart_1163222.html 使用squid实现按源ip选择分流
http://blog.chinaunix.net/u1/55815/showart_1151186.html squid做loadbalance并支持按源ip做会话保持保持
今天有时间研究squid的负载均衡，目前已经有了一定的进展，下面就把我的心得总结出来和大家分享一下
我的目标：1，使用squid进行负载均衡；2，做到会话保持。我使用的squid版本，SQUID 3.0.STABLE8 注：只有squid3.0stable8可以实现（SQUID 2.6.STABLE21也可以实现，2.7目前可以实现负载均衡，但无法实现会话保持）。实现使用参数cache_peer，其中的options ：sourcehash，这个参数是stable8新加入的，是按client的ip来进行loadbalance，配置参数如下
...
首先说明一点：为了防止公网使用我的squid当代理服务器上网，所以我去掉了dns，这样所有域名我都会通过hosts文件解析（见：http://blog.chinaunix.net/u1/55815/showart_1150158.html ）。1，如果配置文件中加上always_direct allow all,将会出现a.b.c域名因为找不到对应的ip而无法访问，但b.c.d可以正常访问；2，如果注释掉always_direct allow all，则相反，a.b.c可以正常访问，b.c.d会提示squid无法转发请求
由此我就想到了用第一个实现的办法来同时工作，需要走loadbalance的就用cache_peer，不需要loadbalance的就用hosts文件转发。
squid的loadbalance支持健康检测，如果后端RS服务停了，squid会自动判断，并不再把请求发给后方。以上配置已经在我的一台生产线环境的squid上应用，目前稳定性，性能还处于观察中。不过以上基于client的ip做的会话保持，我发现了一个问题，就是我不知道在哪里设置会话保持的过期时间，如果谁找到了，还望告知，以上描述性的话语过多，如有不明白的地方，我们一起交流
【此篇文章已经收录于我个人blog中，欢迎大家转载 http://mosquito.cublog.cn】
评论：我说两点：
1、你用的是sourcehash ，我理解是一个ip只会到一台后端的服务器上
2、关于后端健康检查，我没用过squid3.X， 不过在2.6上我是用它的monitorurl来实现的，
至于是否会基于tcp的健康检查，我记得是不能的
另外，squid的负载均衡的效率不知道比nginx、haproxy如何？我曾经在2.5上用过carp协议的
很耗cpu，不知道现在如何了:mrgreen: