⼀.基于RR-DNS的解决⽅法
的可伸缩的WEB服务器系统就是最早基于（Round-Robin Domain Name System）的原型系统。它的结构和⼯作流程如下图所⽰： 基于RR-DNS的可伸缩WEB服务器
有⼀组服务器，他们通过 (Andrew File System)来共享所有的⽂档。这组服务器拥有相同的（如），当⽤户按照这个域名访问时,RR-DNS 服务器会把域名轮流解析到这组服务器的不同IP地址，从⽽将访问负载分到各台服务器上。
这种⽅法带来⼏个问题。第⼀，是⼀个分布式系统，是按照⼀定的层次结构组织的。当⽤户就域名解析请求提交给本地的域名服务器，它会因不能直接解析⽽向上⼀级域名服务器提交，上⼀级域名服务器再依次向上提交，直到RR-DNS域名服器把这个域名解析到其中⼀台服务器的IP地址。可见，从⽤户到RR-DNS间存在多台域名服器，⽽它们都会缓冲已解析的名字到IP地址的映射，这会导致该域名服器组下所有⽤户都会访问同⼀WEB服务器，出现不同WEB服务器间严重的负载不平衡。为了保证在域名服务器中域名到IP地址的映射不被长久缓冲，RR-DNS在域名到IP地址的映射上设置⼀个(TimeToLive)值，过了这 ⼀段时间，域名服务器将这个映射从缓冲中淘汰。当⽤户请求，它会再向上⼀级域名服器提交请求并进⾏重新影射。这就涉及到如何设置这个TTL值，若这个值太⼤，在这个TTL期间，很多请求会被映射到同⼀台WEB服务器上，同样会导致严重的负载不平衡。若这个值太⼩，例如是０，会导致本地域名服务器频繁地向RR-DNS提交请求，增加了域名解析的⽹络流量，同样会使RR-DNS服务器成为系统中⼀个新的瓶颈。
第⼆，⽤户机器会缓冲从名字到IP地址的映射，⽽不受TTL值的影响，⽤户的访问请求会被送到同⼀台WEB服务器上。由于⽤户访问请求的突发性和访问⽅式不同，例如有的⼈访问⼀下就离开了，⽽有的⼈访问可长达⼏个⼩时，所以各台服务器间的负载仍存在倾斜（Skew）⽽不能控制。假设⽤户在每个会话中平均请求数为20，负载最⼤的服务器获得的请求数额⾼于各服务器平均请求数的平均⽐率超过百分之三⼗。也就是说，当TTL值为0时，因为⽤户访问的突发性也会存在着较严重的负载不平衡。
第三，系统的可靠性和可维护性差。若⼀台服务器失效，会导致将域名解析到该服务器的⽤户看到服务中断，即使⽤户按“Reload”按钮，也⽆济于事。系统管理员也不能随时地将⼀台服务器切出服务进⾏系统维护，如进⾏操作系统和应⽤软件升级，这需要修改RR-DNS服务器中的IP地址列表，把该服务器的IP地址从中划掉，然后等上⼏天或者更长的时间，等所有域名服器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机不再使⽤该站点为⽌。
⼆.基于客户端的解决⽅法
基于客户端的解决⽅法需要每个客户程序都有⼀定的服务器集的知识，进⽽把以负载均衡的⽅式将请求发到不同的服务器。例如，浏览器访问的主页时，它会随机地从⼀百多台服务器中挑选第N台，最后将请求送往。然⽽，这不是很好的解决⽅
法，Netscape只是利⽤它的Navigator避免了RR-DNS解析的⿇烦，当使⽤IE等其他浏览器不可避免的要进⾏RR-DNS解析。挂包钩
是做的另⼀种基于客户端的解决⽅法。服务提供⼀个在客户⽅浏览器中运⾏，Applet向各个服务器发请求来收集服务器的负载等信息，再根据这些信息将客户的请求发到相应的服务器。⾼可⽤性也在Applet中实现，当服务器没有响应时，Applet向另⼀个服务器转发请求。这种⽅法的透明性不好，Applet向各服务器查询来收集信息会增加额外的⽹络流量，不具有普遍的适⽤性。
三.基于应⽤层负载均衡调度的解决⽅法
回收锡
多台服务器通过⾼速的互联⽹络连接成⼀个集系统，在前端有⼀个基于应⽤层的负载调度器。当⽤户访问请求到达调度器时，请求会提交给作负载均衡调度的应⽤程序，分析请求，根据各个服务器的负载情况，选出⼀台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给⽤户。
玄武岩纤维布应⽤层负载均衡调度的典型代表有、、和等。Zeus负载调度器是Zeus公司的商业产品，它是在Zeus
Web服务器程序改写⽽成的，采⽤单进程事件驱动的服务器结构。pWeb就是⼀个基于 1.1服务器程序改写⽽成的并⾏WEB调度程序，当⼀个HTTP请求到达时，pWeb会选出⼀个服务器，重写请求并向这个服务器发出改写后的请求，等结果返回后，再将结果转发给客户。Reverse-Proxy利⽤Apache 1.3.1中的Proxy模块和Rewrite模块实现⼀个可伸缩WEB服务器，它与pWeb的不同之处在于它要先从Proxy的cache中查后，若没有这个副本，再选⼀台服务器，向服务器发送请求，再将服务器返回的结果转发给客户。SWEB是利⽤HTTP中的redirect错误代码，将客户请求到达⼀台WEB服务器后，这个WEB服务器根据⾃⼰的负载情况，⾃⼰处理请求，或者通过redirect错误代码将客户引到另⼀台WEB服务器，以实现⼀个可伸缩的WEB服务器。
基于应⽤层负载均衡调度的多服务器解决⽅法也存在⼀些问题。第⼀，系统处理开销特别⼤，致使系统的伸缩性有限。当请求到达负载均衡调度器⾄处理结束时，调度器需要进⾏四次从核⼼到⽤户空间或从⽤户空间到核⼼空间的上下⽂切换和内存复制；需要进⾏⼆次TCP连接，⼀次是从⽤户到调度器，另⼀次是从调度器到真实服务器；需要对请求进⾏分析和重写。这些处理都需要不⼩的ＣＰＵ、内存和⽹络等资源开销，且处理时间长。所构成系统的性能不能接近线性增加的，⼀般服务器组增⾄3或4台时，调度器本⾝可能会成为新的瓶颈。所以，这种基于应⽤层负载均衡调度的⽅法的伸缩性极其有限。第⼆，基于应⽤层的负载均衡调度器对于不同的应⽤，需要写不同的调度器。以上⼏个系统都是基于HTTP协议，若对于FTP、Mail、POP3等应⽤，都需要重写调度器。
四.基于IP层负载均衡调度的解决⽅法
⽤户通过虚拟IP地址（Virtual IP Address）访问服务时，访问请求的报⽂会到达负载调度器，由它进⾏负载均衡调度，从⼀组真实服务器选出⼀个，将报⽂的⽬标地址Virtual IP Address改写成选定服务器的地址，报⽂的⽬标端⼝改写成选定服务器的相应端⼝，最后将报⽂发送给选定的服务器。真实服务器的回应报⽂经过负载调度器时，将报⽂的源地址和源端⼝改为Virtual IP Address和相应的端⼝，再把报⽂发给⽤户。Berkeley的、的、的和的Big/IP等都是使⽤⽹络地址转换⽅法。Magic Router是在Linux 1.3版本上应⽤快速报⽂插⼊技术，使得进⾏负载均衡调度的⽤户进程访问⽹络设备接近核⼼空间的速度，降低了上下⽂切换的处理开销，但并不彻底，它只是研究的原型系统，没有成为有⽤的系统存活下来。Cisco的Local Director、Alteon的ACE Director和F5的Big/IP是⾮常昂贵的商品化系统，它们⽀持部分TCP/UDP协议，有些在ICMP处理上存在问题。
的TCP Router使⽤修改过的⽹络地址转换⽅法在系统实现可伸缩的WEB服务器。TCP Router修改请求报⽂的⽬标地址并把它转发给选出的服务器，服务器能把响应报⽂的源地址置为TCP Router地址⽽⾮⾃⼰的地址。这种⽅法的好处是响应报⽂可以直接返回给客户，坏处是每台服务器的操作系统内核都需要修改。IBM的 NetDispatcher[10]是TCP Router的后继者，它将报⽂转发给服务器，⽽服务器在non-ARP的设备配置路由器的地址。这种⽅法与LVS集中的VS/DR类似，它具有很⾼的可伸缩性，但⼀套在IBM SP/2和Net Dispatcher需要上百万美⾦。总的来说，IBM的技术还挺不错的。
在的 中，每台服务器都独⽴的IP地址，但都⽤IP Alias配置上同⼀VIP地址，采⽤路由和⼴播两种⽅法分发请求，服务器收到请求后按VIP 地址处理请求，并以VIP为源地址返回结果。这种⽅法也是为了避免回应报⽂的重写，但是每台服务器⽤IP Alias配置上同⼀VIP地址，会导致地址冲突，有些操作系统会出现⽹络失效。通过⼴播分发请求，同样需要修改服务器操作系统的源码来过滤报⽂，使得只有⼀台服务器处理⼴播来的请求。
微软的负载均衡服务（Windows NT Load Balancing Service，WLBS）是1998年底收购公司获得的，它与ONE-IP中的基于本地过滤⽅法⼀样。WLBS作为过滤器运⾏在⽹卡驱动程序和TCP/IP协议栈之间，获得⽬标地址为VIP的报⽂，它的过滤算法检查报⽂的源IP地址和端⼝号，保证只有⼀台服务器将报⽂交给上⼀层处理。但是，当有新结点加⼊和有结点失效时，所有服务器需要协商⼀个新的过滤算法，这会导致所有有Session的连接中断。同时，WLBS需要所有的服务器有相同的配置，如⽹卡速度和处理能⼒。
五.LVS负载均衡
1.通过NAT实现虚拟服务器（VS/NAT）
由于中IP地址空间的⽇益紧张和安全⽅⾯的原因，很多⽹络使⽤保留IP地址（10.0.0.0/255.0.0.0、172.16.0.0/255.240.0.0和
192.168.0.0/255.255.0.0）。这些地址不在上使⽤，⽽是专门为内部⽹络预留的。当内部⽹络中的主机要访问Internet或被Internet访问时，就需要采⽤（Network Address Translation, 以下简称），将内部地址转化为Internets上可⽤的外部地址。NAT的⼯作原理是报⽂头（⽬标地址、源地址和端⼝等）被正确改写后，客户相信它们连接⼀个IP地址，⽽不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以⽤NAT⽅法将不同IP地址的并⾏⽹络服务变成在⼀个IP地址上的⼀个虚拟服务。
VS/NAT的体系结构如下图所⽰。在⼀组服务器前有⼀个调度器，它们是通过 / 相连接的。这些服务器提供相同的⽹络服务、相同的内容，即不管请求被发送到哪⼀台服务器，执⾏结果是⼀样的。服务的内容可以复制到每台服务器的本地硬盘上，可以通过⽹络⽂件系统（如）共享，也可以通过⼀个分布式⽂件系统来提供。
VS/NAT的体系结构
客户通过Virtual IP Address（虚拟服务的IP地址）访问⽹络服务时，请求报⽂到达调度器，调度器根据连接调度算法从⼀组真实服务器中选出⼀台服务器，将报⽂的⽬标地址Virtual IP Address改写成选定服务器的地址，报⽂的⽬标端⼝改写成选定服务器的相应端⼝，最后将修改后的报⽂发送给选出的服务器。同时，调度器在连接表中记录这个连接，当这个连接的下⼀个报⽂到达时，从连接Hash表中可以得到原选定服务器的地址和端⼝，进⾏同样的改写操作，并将报⽂传给原选定的服务器。当来⾃
真实服务器的响应报⽂经过调度器时，调度器将报⽂的源地址和源端⼝改为Virtual IP Address和相应的端⼝，再把报⽂发给⽤户。在连接上引⼊⼀个状态机，不同的报⽂会使得连接处于不同的状态，不同的状态有不同的超时值。在TCP连接中，根据标准的TCP有限状态机进⾏状态迁移，这⾥不⼀⼀叙述，请参见的；在UDP中，只设置⼀个UDP状态。不同状态的超时值是可以设置的，在缺省情况下，状态的超时为1分钟，状态的超时为15分钟，状态的超时为1分钟；UDP状态的超时为5分钟。当连接终⽌或超时，调度器将这个连接从连接Hash表中删除。
这样，客户所看到的只是在Virtual IP Address上提供的服务，⽽服务器集的结构对⽤户是透明的。对改写后的报⽂，应⽤增量调整Checksum的算法调整TCP Checksum的值，避免了扫描整个报⽂来计算Checksum的开销。
在⼀些⽹络服务中，它们将IP地址或者端⼝号在报⽂的数据中传送，若只对报⽂头的IP地址和端⼝号作转换，这样就会出现不⼀致性，服务会中断。所以，针对这些服务，需要编写相应的应⽤模块来转换报⽂数据中的IP地址或者端⼝号。所知道有这个问题的⽹络服务有、、、、、、/、、、、、、、、、、、和。
下⾯，举个例⼦来进⼀步说明VS/NAT，如图所⽰：
VS/NAT的例⼦
VS/NAT的配置如下所⽰，所有到IP地址为202.103.106.5和端⼝为80的流量都被负载均衡地调度的真实服务器172.16.0.2:80和172.16.0.3:8000上。⽬标地址为202.103.106.5:21的报⽂被转移到172.16.0.3:21上。⽽到其他端⼝的报⽂将被拒绝。
Protocol Virtual IP Address Port Real IP Address Port Weight
TCP 202.103.106.5 80 172.16.0.2 80 1
172.16.0.3 8000 2
TCP 202.103.106.5 21 172.16.0.3 21 1
从以下的例⼦中，可以更详细地了解报⽂改写的流程。
访问Web服务的报⽂可能有以下的源地址和⽬标地址：
SOURCE 202.100.1.2:3456 DEST 202.103.106.5:80
调度器从调度列表中选出⼀台服务器，例如是172.16.0.3:8000。该报⽂会被改写为如下地址，并将它发送给选出的服务器。
SOURCE 202.100.1.2:3456 DEST 172.16.0.3:8000
从服务器返回到调度器的响应报⽂如下：
SOURCE 172.16.0.3:8000 DEST 202.100.1.2:3456
响应报⽂的源地址会被改写为虚拟服务的地址，再将报⽂发送给客户：
SOURCE 202.103.106.5:80 DEST 202.100.1.2:3456
这样，客户认为是从202.103.106.5:80服务得到正确的响应，⽽不会知道该请求是服务器172.16.0.2还是服务器172.16.0.3处理的。
2.通过IP隧道实现虚拟服务器（VS/TUN）
在VS/NAT的集系统中，请求和响应的数据报⽂都需要通过负载调度器，当真实服务器的数⽬在10台和20台之间时，负载调度器将成为整个集系统的新瓶颈。⼤多数Internet服务都有这样的特点：请求报⽂较短⽽响应报⽂往往包含⼤量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求⽽响应直接返回给客户，将极⼤地提⾼整个集系统的吞吐量。
IP隧道（IP tunneling）是将⼀个IP报⽂封装在另⼀个IP报⽂的技术，这可以使得⽬标为⼀个IP地址的数据报⽂能被封装和转发到另⼀个IP地址。亦称为技术（IPencapsulation）。IP隧道主要⽤于移动主机和虚拟私有⽹络（Virtua lP rivate Network），在其中隧道都是静态建⽴的，隧道⼀端有⼀个IP地址，另⼀端也有唯⼀的IP地址。
利⽤IP隧道技术将请求报⽂封装转发给后端服务器，响应报⽂能从后端服务器直接返回给客户。但在这⾥，后端服务器有⼀组⽽⾮⼀个，所以不可能静态地建⽴⼀⼀对应的隧道，⽽是动态地选择⼀台服务器，将请求报⽂封装和转发给选出的服务器。这样，可以利⽤IP隧道的原理将⼀组服务器上的⽹络服务组成在⼀个IP地址上的虚拟⽹络服务。VS/TUN的体系结构如图所⽰，各个服务器将VIP地址配置在⾃⼰的IP隧道设备上。
镀铬工艺VS/TUN的体系结构
VS/TUN 的⼯作流程如上图所⽰：它的连接调度和管理与VS/NAT中的⼀样，只是它的报⽂转发⽅法不同。调度器根据各个服务器的负载情况，动态地选择⼀台服务器，将请求报⽂封装在另⼀个IP报⽂中，再将封装后的IP报⽂转发给选出的服务器；服务器收到报⽂后，先将报⽂解封获得原来⽬标地址为VIP的报⽂，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报⽂直接返回给客户。
VS/TUN的⼯作流程
需要指出，根据缺省的TCP/IP协议栈处理，请求报⽂的⽬标地址为VIP，响应报⽂的源地址肯定也为VIP，所以响应报⽂不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，⽽不会知道究竟是哪⼀台服务器处理的。
半连接的TCP有限状态机
3.通过直接路由实现虚拟服务器（VS/DR）
跟VS/TUN⽅法相同，VS/DR利⽤⼤多数Internet服务的⾮对称特点，负载调度器中只负责调度请求，⽽服务器直接将响应返回给客户，可以极⼤地提⾼整个集系统的吞吐量。该⽅法与的产品中使⽤的⽅法类似（其中服务器上的IP地址配置⽅法是相似的），但IBM的Net Dispatcher是⾮常昂贵的商品化产品，也不清楚它内部所使⽤的机制，其中有些是IBM的专利。
VS/DR的体系结构如图所⽰：调度器和服务器组都必须在物理上有⼀个⽹卡通过不分断的局域⽹相连，如通过⾼速的或者相连。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，⽤于接收虚拟服务的请求报⽂；所有的服务器把VIP地址配置在各⾃的⽹络设备上，它对外⾯是不可见的，只是⽤于处理⽬标地址为VIP的⽹络请求。
VS/DR的体系结构
VS/DR的⼯作流程如上图所⽰：它的连接调度和管理与VS/NAT和VS/TUN中的⼀样，它的报⽂转发⽅法⼜有不同，将报⽂直接路由给⽬标服务器。在VS/DR中，调度器根据各个服务器的负载情况，动态地选择⼀台服务器，不修改也不封装IP报⽂，⽽是将数据帧的改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域⽹上发送。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报⽂。当服务器发现报⽂的⽬标地址VIP是在本地的⽹络设备上，服务器处理这个报⽂，然后根据路由表将响应报⽂直接返回给客户。加热平台
VS/DR的⼯作流程
在VS/DR中，根据缺省的TCP/IP协议栈处理，请求报⽂的⽬标地址为VIP，响应报⽂的源地址肯定也为VIP，所以响应报⽂不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，⽽不会知道是哪⼀台服务器处理的。
VS/DR负载调度器跟VS/TUN⼀样只处于从客户到服务器的半连接中，按照半连接的TCP有限状态机进⾏状态迁移。
LVS负载均衡 - 三种⽅法的优缺点⽐较
三种IP负载均衡技术的优缺点归纳在下表中：
VS/NAT VS/TUN VS/DR
server any Tunneling Non-arp device
server network private LAN/WAN LAN
server number low(10~20)High(100)High(100)
server gateway load balancer own router own router
注：以上三种⽅法所能⽀持最⼤服务器数⽬的估计是假设调度器使⽤100M⽹卡，调度器的硬件配置与后端服务器的硬件配置相同，⽽且是对⼀般Web服务。使⽤更⾼的硬件配置（如和更快的）作为调度器，调度器所能调度的服务器数量会相应增加。当应⽤不同时，服务器的数⽬也会相应地改变。所以，以上数据估计主要是为三种⽅法的伸缩性进⾏量化⽐较。
Virtual Server via NAT抛光毛刷
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议