负载均衡介绍（DNS负载均衡技术、IP负载均衡技术）

 

负载均衡介绍（DNS负载均衡技术、IP负载均衡技术）

 

前言：

集群、分布式、负载均衡概念的不同

1、Linux集群主要分成三大类( 高可用集群， 负载均衡集群，科学计算集群)（下面只介绍负载均衡集群） 
负载均衡集群(Load Balance Cluster) 
负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。 

负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。 


2、负载均衡系统： 负载均衡又有DNS负载均衡（比较常用）、IP负载均衡、反向代理负载均衡等，也就是在集群中有服务器A、B、C，它们都是互不影响，互不相干的，任何一台的机器宕了，都不会影响其他机器的运行，当用户来一个请求，有负载均衡器的算法决定由哪台机器来处理，假如你的算法是采用round算法，有用户a、b、c，那么分别由服务器A、B、C来处理； 


3、分布式是指将不同的业务分布在不同的地方。 
而集群指的是将几台服务器集中在一起，实现同一业务。 
分布式中的每一个节点，都可以做集群。 
而集群并不一定就是分布式的。 
举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。 
而分布式，从窄意上理解，也跟集群差不多， 但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。 

分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。

 

一、DNS负载均衡技术

 

　　负载均衡技术能够平衡服务器集群中所有的服务器和请求应用之间的通信负载，根据实时响应时间进行判断，将任务交由负载最轻的服务器来处理，以实现真正的智能通信管理和最佳的服务器群性能，从而使网站始终保持运行和保证其可访问性。

　　为了充分利用现有服务器软件的种种优势，负载均衡最好是在服务器软件之外来完成。而最早使用的负载均衡技术是通过DNS服务中的随机名字解析来实现的。这就是通常所说的DNS负载均衡技术。

　　DNS负载均衡技术的实现原理是在DNS服务器中为同一个主机名配置多个IP地址，在应答DNS查询时，DNS服务器对每个查询将以DNS文件中主机记录的IP地址按顺序返回不同的解析结果，将客户端的访问引导到不同的机器上去，使得不同的客户端访问不同的服务器，从而达到负载均衡的目的。

　　直到现在，很多网站仍然使用DNS负载均衡来保证网站的运行和可访问性。从其实现和效果来看，主要有以下优缺点：

　　主要优点

　　这种技术的主要缺点如下：

　　第一，技术实现比较灵活、方便，简单易行，成本低，适用于大多数TCP/IP应用。不需要网络专家来对之进行设定，或在出现问题时对之进行维护。

　　第二，对于Web应用来说，不需要对代码作任何的修改。事实上，Web应用本身并不会意识到负载均衡配置，即使在它面前。

　　第三，Web服务器可以位于互联网的任意位置上。

　　主要缺点

　　DNS负载均衡技术在具有以上优点的时候，其缺点也非常明显，主要表现在：

　　第一，不能够按照Web服务器的处理能力分配负载。DNS负载均衡采用的是简单的轮循负载算法，不能区分服务器之间的差异，不能反映服务器的当前运行状态。所以DNS服务器将Http请求平均地分配到后台的Web服务器上，而不考虑每个Web服务器当前的负载情况。如果后台的Web服务器的配置和处理能力不同，最慢的 Web服务器将成为系统的瓶颈，处理能力强的服务器不能充分发挥作用。不能做到为性能较好的服务器多分配请求，甚至会出现客户请求集中在某一台服务器上的情况。

　　第二，不支持高可靠性，DNS负载均衡技术没有考虑容错。如果后台的某台Web服务器出现故障，DNS服务器仍然会把DNS 请求分配到这台故障服务器上，导致不能响应客户端。

　　第三，可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。

　　第四，一旦某个服务器出现故障，即使及时修改了DNS设置，还是要等待足够的时间(刷新时间)才能发挥作用，在此期间，保存了故障服务器地址的客户计算机将不能正常访问服务器。

　　总结

　　从上面的总结我们可以看出，总体来说，DNS负载均衡技术方案不应该算是真正意义上的负载均衡，不能够稳定、可靠、高效地满足企业对Web服务器的需求，也不能满足网络用户对网站访问的及时响应和可用性，所以现在很多Web站点方案中，已经很少采用这种方案了。

 

 

 

二、IP负载均衡技术

 

首先让我们来看看下面这张大家都非常熟悉的TCP/IP协议族的分层图：

                  

关于每层在网络数据包传输过程中所起到的作用不是本文的重点，本文主要是讲解如何在网络层中使用IP来做服务器集群的负载均衡，为什么可以在这一层来做负载均衡。下面在来看IP协议的报头格式：

                

内红色框内的源地址和目的地址是IP负载均衡功能的关键所在，IP负载均衡又可以称之为网络层负载均衡，其核心原理就是通过内核驱动更改IP的目的地址来完成数据负载均衡的，如下图：

                   

    如上图所示，用户请求数据包（源地址为200.110.50.1）到达负载均衡服务器114.100.20.200后，负载均衡服务器在内核进程获取网络数据包，根据一定的负载均衡算法得到一台内部的真实服务器192.168.1.1，然后将数据包的目的IP修改为192.168.1.1，此后数据包将会被发往192.168.1.1的服务器上，服务器处理完后，将向负载均衡服务器返回相应的数据包，负载均衡服务器在把源地址修改为114.100.20.200后将数据包传输给用户浏览器。在这一整个过程中，数据包没有通过用户的应用进程，因此该负载均衡的性能是非常之高的。

    根据以上的图和上文的讲解，大家可能会觉得这很容易实现，其实不然，在这里需要处理关键的地方就是如何将集群内部服务器处理完后的数据返回给负载均衡服务器。因为，用户请求的数据包到达负载均衡服务器前的目的地址是114.100.20.200，源地址是200.110.50.1，通过负载均衡服务器修改后的目的地址是192.168.1.1，源地址还是200.110.50.1，所以处理后返回的数据包目的地址将是200.110.50.1，源地址是192.168.1.1，最终返回的数据包要回到负载均衡服务器就成了问题。解决的办法大概有如下两种：一、负载均衡服务器使用双网卡，一个对内一个对外，在修改请求数据包的目的IP的同时也修改源地址，将源地址设为自身的IP，即源地址转换（SNAT），这样内部集群服务器响应会再回到负载均衡服务器；二、将负载均衡服务器作为真实物理服务器集群的网关服务器，这样所有的响应都将通过负载均衡服务器。

    IP负载均衡在内核进程完成数据分发，处理性能得到了很好的提高。但是由于所有请求和响应都要经过负载均衡服务器，集群的最大响应数据吞吐量将受到负载均衡服务器网卡带宽的限制，对于提供下载服务或者视频服务等需要大量传输数据的站点而言，这是难以满足需求的。要是能让响应数据包绕过负载均衡服务器直接发往用户机器上就好了，有什么办法可以做到呢？当然有，那就是链路层的负载均衡，这将在下一博文中讲解。

IP负载均衡技术

上一章节讲述了可伸缩网络服务的几种结构，它们都需要一个前端调度器。在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN（Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。

本章节将描述三种IP负载均衡技术VS/NAT、VS/TUN和VS/DR的工作原理，以及它们的优缺点。在以下描述中，我们称客户的socket和服务器的socket之间的数据通讯为连接，无论它们是使用TCP还是UDP协议。

一、通过NAT实现虚拟服务器（VS/NAT）

由于IPv4中IP地址空间的日益紧张和安全方面的原因，很多网络使用保留IP地址（10.0.0.0/255.0.0.0、172.16.0.0/255.128.0.0和192.168.0.0/255.255.0.0）[64, 65, 66]。这些地址不在Internet上使用，而是专门为内部网络预留的。当内部网络中的主机要访问Internet或被Internet访问时，就需要采用网络地址转换（Network Address Translation, 以下简称NAT），将内部地址转化为Internets上可用的外部地址。NAT的工作原理是报文头（目标地址、源地址和端口等）被正确改写后，客户相信它们连接一个IP地址，而不同IP地址的服务器组也认为它们是与客户直接相连的。由此，可以用NAT方法将不同IP地址的并行网络服务变成在一个IP地址上的一个虚拟服务。

VS/NAT的体系结构如图3.1所示。在一组服务器前有一个调度器，它们是通过Switch/HUB相连接的。这些服务器提供相同的网络服务、相同的内容，即不管请求被发送到哪一台服务器，执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上，可以通过网络文件系统（如NFS）共享，也可以通过一个分布式文件系统来提供。

图3.1：VS/NAT的体系结构

客户通过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器，调度器根据连接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度器在连接Hash表中记录这个连接，当这个连接的下一个报文到达时，从连接Hash表中可以得到原选定服务器的地址和端口，进行同样的改写操作，并将报文传给原选定的服务器。当来自真实服务器的响应报文经过调度器时，调度器将报文的源地址和源端口改为Virtual IP Address和相应的端口，再把报文发给用户。我们在连接上引入一个状态机，不同的报文会使得连接处于不同的状态，不同的状态有不同的超时值。在TCP连接中，根据标准的TCP有限状态机进行状态迁移；在UDP中，我们只设置一个UDP状态。不同状态的超时值是可以设置的，在缺省情况下，SYN状态的超时为1分钟，ESTABLISHED状态的超时为15分钟，FIN状态的超时为1分钟；UDP状态的超时为5分钟。当连接终止或超时，调度器将这个连接从连接Hash表中删除。

这样，客户所看到的只是在Virtual IP Address上提供的服务，而服务器集群的结构对用户是透明的。对改写后的报文，应用增量调整Checksum的算法调整TCP Checksum的值，避免了扫描整个报文来计算Checksum的开销。

在一些网络服务中，它们将IP地址或者端口号在报文的数据中传送，若我们只对报文头的IP地址和端口号作转换，这样就会出现不一致性，服务会中断。所以，针对这些服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。我们所知道有这个问题的网络服务有FTP、IRC、H.323、CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。

下面，举个例子来进一步说明VS/NAT，如图3.2所示：

图3.2：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处理的。

二、通过IP隧道实现虚拟服务器（VS/TUN）

在VS/NAT的集群系统中，请求和响应的数据报文都需要通过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特点：请求报文较短而响应报文往往包含大量的数据。如果能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提高整个集群系统的吞吐量。

IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文的技术，这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态建立的，隧道一端有一个IP地址，另一端也有唯一的IP地址。

我们利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，所以我们不可能静态地建立一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图3.3所示，各个服务器将VIP地址配置在自己的IP隧道设备上。

图3.3：VS/TUN的体系结构

VS/TUN的工作流程如图3.4所示：它的连接调度和管理与VS/NAT中的一样，只是它的报文转发方法不同。调度器根据各个服务器的负载情况，动态地选择一台服务器，将请求报文封装在另一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封获得原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，所以就处理这个请求，然后根据路由表将响应报文直接返回给客户。

图3.4：VS/TUN的工作流程

在这里，请求报文的目标地址为VIP，响应报文的源地址也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

在VS/TUN中，响应报文根据服务器的路由表直接返回给客户，而不经过负载调度器，所以负载调度器只处于从客户到服务器的半连接中，VS/TUN的TCP状态迁移与VS/NAT的不同。我们给出半连接的TCP有限状态机，如图3.5所示，圈表示状态，箭头表示状态间的转换，箭头上的标识表示在当前状态上收到该标识的输入，迁移到下一个状态。VS/TUN的TCP状态迁移是按照半连接的TCP有限状态机进行的。

图3.5：半连接的TCP有限状态机

三、通过直接路由实现虚拟服务器（VS/DR）

跟VS/TUN方法相同，VS/DR利用大多数Internet服务的非对称特点，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，可以极大地提高整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法类似，但IBM的NetDispatcher是非常昂贵的商品化产品，我们也不知道它内部所使用的机制，其中有些是IBM的专利。

VS/DR的体系结构如图3.6所示：调度器和服务器组都必须在物理上有一个网卡通过不分断的局域网相连，如通过交换机或者高速的HUB相连。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。

图3.6：VS/DR的体系结构

VS/DR的工作流程如图3.7所示：它的连接调度和管理与VS/NAT和VS/TUN中的一样，它的报文转发方法又有不同，将报文直接路由给目标服务器。在VS/DR中，调度器根据各个服务器的负载情况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改为选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。因为数据帧的MAC地址是选出的服务器，所以服务器肯定可以收到这个数据帧，从中可以获得该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，然后根据路由表将响应报文直接返回给客户。

图3.7：VS/DR的工作流程

在VS/DR中，请求报文的目标地址为VIP，响应报文的源地址也为VIP，所以响应报文不需要作任何修改，可以直接返回给客户，客户认为得到正常的服务，而不会知道是哪一台服务器处理的。

VS/DR负载调度器也只处于从客户到服务器的半连接中，按照半连接的TCP有限状态机进行状态迁移。

四、三种方法的优缺点比较三种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服务。使用更高的硬件配置（如千兆网卡和更快的处理器）作为调度器，调度器所能调度的服务器数量会相应增加。当应用不同时，服务器的数目也会相应地改变。所以，以上数据估计主要是为三种方法的伸缩性进行量化比较。

4.1、Virtual Server via NAT

VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统，它只需要一个IP地址配置在调度器上，服务器组可以用私有的IP地址。缺点是它的伸缩能力有限，当服务器结点数目升到20时，调度器本身有可能成为系统的新瓶颈，因为在VS/NAT中请求和响应报文都需要通过负载调度器。 我们在Pentium 166 处理器的主机上测得重写报文的平均延时为60us，性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes，则调度器的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s，这样一个调度器可以带动10台服务器。（注：这是很早以前测得的数据）

基于 VS/NAT的的集群系统可以适合许多服务器的性能要求。如果负载调度器成为系统新的瓶颈，可以有三种方法解决这个问题：混合方法、VS/TUN和 VS/DR。在DNS混合集群系统中，有若干个VS/NAT负载调度器，每个负载调度器带自己的服务器集群，同时这些负载调度器又通过RR-DNS组成简单的域名。但VS/TUN和VS/DR是提高系统吞吐量的更好方法。

对于那些将IP地址或者端口号在报文数据中传送的网络服务，需要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工作量，同时应用模块检查报文的开销会降低系统的吞吐率。

4.2、Virtual Server via IP Tunneling在VS/TUN 的集群系统中，负载调度器只将请求调度到不同的后端服务器，后端服务器将应答的数据直接返回给用户。这样，负载调度器就可以处理大量的请求，它甚至可以调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。即使负载调度器只有100Mbps的全双工网卡，整个系统的最大吞吐量可超过 1Gbps。所以，VS/TUN可以极大地增加负载调度器调度的服务器数量。VS/TUN调度器可以调度上百台服务器，而它本身不会成为系统的瓶颈，可以用来构建高性能的超级服务器。

VS/TUN技术对服务器有要求，即所有的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前，VS/TUN的后端服务器主要运行Linux操作系统，我们没对其他操作系统进行测试。因为“IP Tunneling”正成为各个操作系统的标准协议，所以VS/TUN应该会适用运行其他操作系统的后端服务器。

4.3、Virtual Server via Direct Routing

跟VS/TUN方法一样，VS/DR调度器只处理客户到服务器端的连接，响应数据可以直接从独立的网络路由返回给客户。这可以极大地提高LVS集群系统的伸缩性。

跟VS/TUN相比，这种方法没有IP隧道的开销，但是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不作ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。

五、小结

 

本章主要讲述了可伸缩网络服务LVS框架中的三种IP负载均衡技术。在分析网络地址转换方法（VS/NAT）的缺点和网络服务的非对称性的基础上，我们给出了通过IP隧道实现虚拟服务器的方法VS/TUN，和通过直接路由实现虚拟服务器的方法VS/DR，极大地提高了系统的伸缩性。

 

NAT负载均衡技术详解：

 

首先让我们来看看下面这张大家都非常熟悉的TCP/IP协议族的分层图：

                  

关于每层在网络数据包传输过程中所起到的作用不是本文的重点，本文主要是讲解如何在网络层中使用IP来做服务器集群的负载均衡，为什么可以在这一层来做负载均衡。下面在来看IP协议的报头格式：

                

内红色框内的源地址和目的地址是IP负载均衡功能的关键所在，IP负载均衡又可以称之为网络层负载均衡，其核心原理就是通过内核驱动更改IP的目的地址来完成数据负载均衡的，如下图：

                   

    如上图所示，用户请求数据包（源地址为200.110.50.1）到达负载均衡服务器114.100.20.200后，负载均衡服务器在内核进程获取网络数据包，根据一定的负载均衡算法得到一台内部的真实服务器192.168.1.1，然后将数据包的目的IP修改为192.168.1.1，此后数据包将会被发往192.168.1.1的服务器上，服务器处理完后，将向负载均衡服务器返回相应的数据包，负载均衡服务器在把源地址修改为114.100.20.200后将数据包传输给用户浏览器。在这一整个过程中，数据包没有通过用户的应用进程，因此该负载均衡的性能是非常之高的。

    根据以上的图和上文的讲解，大家可能会觉得这很容易实现，其实不然，在这里需要处理关键的地方就是如何将集群内部服务器处理完后的数据返回给负载均衡服务器。因为，用户请求的数据包到达负载均衡服务器前的目的地址是114.100.20.200，源地址是200.110.50.1，通过负载均衡服务器修改后的目的地址是192.168.1.1，源地址还是200.110.50.1，所以处理后返回的数据包目的地址将是200.110.50.1，源地址是192.168.1.1，最终返回的数据包要回到负载均衡服务器就成了问题。解决的办法大概有如下两种：一、负载均衡服务器使用双网卡，一个对内一个对外，在修改请求数据包的目的IP的同时也修改源地址，将源地址设为自身的IP，即源地址转换（SNAT），这样内部集群服务器响应会再回到负载均衡服务器；二、将负载均衡服务器作为真实物理服务器集群的网关服务器，这样所有的响应都将通过负载均衡服务器。

    IP负载均衡在内核进程完成数据分发，处理性能得到了很好的提高。但是由于所有请求和响应都要经过负载均衡服务器，集群的最大响应数据吞吐量将受到负载均衡服务器网卡带宽的限制，对于提供下载服务或者视频服务等需要大量传输数据的站点而言，这是难以满足需求的。要是能让响应数据包绕过负载均衡服务器直接发往用户机器上就好了，有什么办法可以做到呢？当然有，那就是链路层的负载均衡，这将在下一博文中讲解。

 

 

三、反向代理负载均衡

 

 

       反向代理，是把一些静态资源存储在服务器上，当用户有请求的时候，就直接返回反向代理服务器上的资源给用户，而如果反向代理服务器上没有的资源，就转发给后面的负载均衡服务器，负载均衡服务器再将请求分发给后端的web服务器。        区别就是：反向代理服务器是需要存储资源的，让用户更快速的接收到资源    负载均衡就是，为了保证后端web服务器的高可用，高并发，是不需要要存储资源，只需要转发用户的请求。

 

反向代理负载均衡

 

向代理负载均衡是普通代理方式,是代理内部网络用户访问internet上服务器的连接请求，客户端必须指定代理服务器,并将本来要直接发送到internet上服务器的连接请求发送给代理服务器处理。

基本信息

• 中文名称

  反向代理负载均衡

 

• 外文名称

  reverse-proxyloadbalancing

目录

 

1概念

 

2nginx 实现反向代理负载均衡

使用代理服务器可以将请求转发给内部的Web服务器，使用这种加速模式显然可以提升静态网页的访问速度。因此也可以考虑使用这种技术，让代理服务器将请求 均匀转发给多台内部Web服务器之一上，从而达到负载均衡的目的。这种代理方式与普通的代理方式有所不同，标准代理方式是客户使用代理访问多个外部Web 服务器，而这种代理方式是多个客户使用它访问内部Web服务器，因此也被称为反向代理模式。

 

概念

实现这个反向代理能力并不能算是一个特别复杂的任务，但是在负载均衡中要求特别高的效率，这样实现起来就不是十分简单的了。每针对一次代理，代理服务器就 必须打开两个连接，一个为对外的连接，一个为对内的连接，因此对于连接请求数量非常大的时候，代理服务器的负载也就非常之大了，在最后反向代理服务器会成 为服务的瓶颈。例如，使用Apache的mod_rproxy模块来实现负载均衡功能时，提供的并发连接数量受Apache本身的并发连接数量的限制。一 般来讲，可以使用它来对连接数量不是特别大，但每次连接都需要消耗大量处理资源的站点进行负载均衡，例如搜寻。

使用反向代理的好处是，可以将负载均衡和代理服务器的高速缓存技术结合在一起，提供有益的性能，具备额外的安全性，外部客户不能直接访问真实的服务器。并 且实现起来可以实现较好的负载均衡策略，将负载可以非常均衡的分给内部服务器，不会出现负载集中到某个 服务器的偶然现象。

 

ginx实现反向代理负载均衡1)环境:

a. 本地使用Windows系统，然后使用VirutalBox安装一个虚拟的Linux系统。

在本地的Windows系统上分别安装nginx(侦听8080端口)和apache(侦听80端口)。在虚拟的Linux系统上安装apache(侦听80端口)。这样相当于拥有了1台nginx在前端作为反向代理服务器;后面有2台apache作为应用程序服务器(可以看作是小型的server cluster。;-));

b. nginx用来作为反向代理服务器，放置到两台apache之前，作为用户访问的入口;

nginx仅仅处理静态页面，动态的页面(php请求)统统都交付给后台的两台apache来处理。也就是说，可以把网站的静态页面或者文件放置到nginx的目录下;动态的页面和数据库访问都保留到后台的apache服务器上。

c. 如下两种方法实现server cluster的负载均衡。

假设前端nginx(为127.0.0.1:8080)仅仅包含一个静态页面index.html;后 台的两个apache服务器(分别为localhost:80和158.37.70.143:80)，一台根目录放置phpMyAdmin文件夹和 test.php(里面测试代码为print "server1";)，另一台根目录仅仅放置一个test.php(里面测试代码为print "server2";)。

2)针对不同请求的负载均衡:

a. 在最简单地构建反向代理的时候(nginx仅仅处理静态不处理动态内容，动态内容交给后台的apache server来处理)，具体的设置为:在nginx.conf中修改:

location ~ \.php$ {

proxy_pass 158.37.70.143:80;

}

>;这样当客户端访问localhost:8080/index.html的时候，前端的nginx会自动进行响应;

>;当用户访问localhost:8080/test.php的时候(这个时候nginx目录下根本就没有该文件)，但是通过上面的设置location ~ \.php$(表示正则表达式匹配以.php结尾的文件，详情参看location是如何定义和匹配的)，nginx服务器会自动pass给158.37.70.143的apache服务器了。该服务器下的test.php就会被自动解析，然后将html的 结果页面返回给nginx，然后nginx进行显示(如果nginx使用memcached模块或者squid还可以支持缓存)，输出结果为打印 server2。

如上是最为简单的使用nginx做为反向代理服务器的例子;

b. 我们现在对如上例子进行扩展，使其支持如上的两台服务器。

设置nginx.conf的server模块部分，将对应部分修改为:

location ^~ /phpMyAdmin/ {

proxy_pass 127.0.0.1:80;

}

location ~ \.php$ {

proxy_pass 158.37.70.143:80;

}

上面第一个部分location ^~ /phpMyAdmin/，表示不使用正则表达式匹配(^~)，而是直接匹配，也就是如果客户端访问的URL是以http://localhost:8080/phpMyAdmin/开头的话(本地的nginx目录下根本没有phpMyAdmin目录)，nginx会自动pass到127.0.0.1:80的Apache服务器，该服务器对phpMyAdmin目录下的页面进行解析，然后将结果发送给nginx，后者显示;

如果客户端访问URL是http://localhost/test.php的话，则会被pass到158.37.70.143:80的apache进行处理。

因此综上，实现了针对不同请求的负载均衡。

>;如果用户访问静态页面index.html，最前端的nginx直接进行响应;

>;如果用户访问test.php页面的话，158.37.70.143:80的Apache进行响应;

>;如果用户访问目录phpMyAdmin下的页面的话，127.0.0.1:80的Apache进行响应;

3)访问同一页面的负载均衡:

即用户访问http://localhost:8080/test.php这个同一页面的时候，实现了两台服务器的负载均衡(实际情况中，这两个服务器上的数据要求同步一致，这里我们分别定义了打印server1和server2是为了进行辨认区别)。

a. 现在的情况是在windows下nginx是localhost侦听8080端口;

两台apache，一台是127.0.0.1:80(包含test.php页面但是打印server1)，另一台是虚拟机的158.37.70.143:80(包含test.php页面但是打印server2)。

b. 因此重新配置nginx.conf为:

>;首先在nginx的配置文件nginx.conf的http模块中添加，服务器集群server cluster(我们这里是两台)的定义:

upstream myCluster {

server 127.0.0.1:80;

server 158.37.70.143:80;

}

表示这个server cluster包含2台服务器

>;然后在server模块中定义，负载均衡:

location ~ \.php$ {

proxy_passhttp://myCluster; #这里的名字和上面的cluster的名字相同

proxy_redirect off;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For$proxy_add_x_forwarded_for;

}

这样的话，如果访问http://localhost:8080/test.php页面的话，nginx目录下根本没有该文件，但是它会自动将其pass到myCluster定义的服务区机群中，分别由127.0.0.1:80;或者158.37.70.143:80;来做处理。上面在定义upstream的时候每个server之后没有定义权重，表示两者均衡;如果希望某个更多响应的话例如:

upstream myCluster {

server 127.0.0.1:80weight=5;

server 158.37.70.143:80;

}

 

综上，通过使用nginx的反向代理服务器reverse proxy server的功能，将其布置到多台apache server的前端。nginx仅仅用来处理静态页面响应和动态请求的代理pass，后台的apache server作为app server来对前台pass过来的动态页面进行处理并返回给nginx。

通过以上的架构，我们可以实现nginx和多台apache构成的机群cluster的负载均衡。

两种均衡:

1)可以在nginx中定义访问不同的内容，代理到不同的后台server;如上例子中的访问phpMyAdmin目录代理到第一台server上;访问test.php代理到第二台server上;

2)可以在nginx中定义访问同一页面，均衡(当然如果服务器性能不同可以定义权重来均衡)地代理到不同的后台server上。如上的例子访问test.php页面，会均衡地代理到server1或者server2上。

实际应用中，server1和server2上分别保留相同的app程序和数据，需要考虑两者的数据同步。

 

 

 

 

 

 

 

 

 

 

 

 

 

反向代理，是把一些静态资源存储在服务器上，当用户有请求的时候，就直接返回反向代理服务器上的资源给用户，而如果反向代理服务器上没有的资源，就转发给后面的负载均衡服务器，负载均衡服务器再将请求分发给后端的web服务器。        区别就是：反向代理服务器是需要存储资源的，让用户更快速的接收到资源    负载均衡就是，为了保证后端web服务器的高可用，高并发，是不需要要存储资源，只需要转发用户的请求。

 

反向代理，是把一些静态资源存储在服务器上，当用户有请求的时候，就直接返回反向代理服务器上的资源给用户，而如果反向代理服务器上没有的资源，就转发给后面的负载均衡服务器，负载均衡服务器再将请求分发给后端的web服务器。        区别就是：反向代理服务器是需要存储资源的，让用户更快速的接收到资源    负载均衡就是，为了保证后端web服务器的高可用，高并发，是不需要要存储资源，只需要转发用户的请求。