第二章 服务器负载均衡的基本概念

服务器负载均衡在服务器世界中并不是一个新的概念。我们已经发明了许多集群技术来实现联合计算，但是只在少数专有系统上得到应用。虽然如此，负载均衡已经成为许多领域的主流应用强有力的解决方案，包括服务器群的扩展能力，高可用性能力，安全性和可管理性。首先，负载均衡通过在多台服务器之间分发负载的方式显著地提高了应用和服务器群的可扩展能力。其次，负载均衡提高了应用系统的可用性因为它能够在一台服务器或者应用出现故障的时候把流量导向备用的服务器。第三，负载均衡可以通过多种方式提高可管理性。它可以让网络或系统管理员将应用轻松地从一台服务器迁移到另外一台服务器或增加更多的服务器来运行应用程序。最后，也是相当重要的，负载均衡通过保护服务器群免受多种类型的DOS攻击从而提高了应用和服务器系统的安全性。

互联网络的到来带来了很多新的应用和服务：Web，DNS，FTP，SMTP等等。幸运的是，区分并处理互联网络的流量是非常容易的。因为互联网络有大量的客户端请求特定的服务，而且每个客户端可以通过IP地址来识别，这样一来，就使分发负载到多台运行同样软件、提供同样服务的服务器的工作具备了可行性。

本章介绍服务器负载均衡的基本概念，并涵盖了便于读者理解负载均衡工作原理的基础知识。很多不同的应用系统都可以做负载均衡，通常采用负载均衡产品来管理Web服务器群。因此，我们就以Web服务器为例来讨论和理解负载均衡，所有这些概念也适用于其他的应用。

首先，我们来讨论一下二三层交换、TCP和Web服务器等负载均衡的基础知识。然后在介绍负载均衡之前我们先了解一下从Web服务器获取一个页面的请求和回应的过程。

现在简单介绍一下二层和三层交换的工作原理，为理解负载均衡概念提供必要的基础知识，关于这个话题详细的讨论不在本书所涵盖的范围之内。

MAC (介质访问控制)地址在以太网中定义了唯一一个网络硬件的实体，IP (互联网络协议)地址定义了互联网络中唯一一个主机。交换机接收数据包的端口称为入口，而交换机发送数据包的端口叫出口。交换机在其入口接收数据包，选择出口并转发数据包。不同的交换机的区别在于使用的用于选择出口的信息不同，并且有的交换机在数据包被发送出去之前会修改一些信息。 二层交换机接收到数据包之后，根据数据包的二层包头信息决定其目的地址，例如MAC地址，并转发数据包。相对的，三层交换基于第三层的包头信息，例如数据包中的IP地址。三层交换机在转发数据包之前根据数据包的目的IP地址，把目地MAC地址修改为下一跳或者目的IP地址的MAC地址。三层交换机也被称为路由器，三层交换也通常被称为路由。负载均衡器检查数据包第四层的信息甚至五至七层的信息来做交换决策，因此被称为四到七层交换机。作为负载均衡功能的一部分，负载均衡器也处理二三层交换的工作，所以有时也被称为二到七层交换机。

为了使网络更加易于管理，网络被细分为许多子网。子网通常是指在一栋楼或者一层楼内连接许多计算机或者是数据中心内连接一群服务器的网络。所有在一个子网内的通讯均可以由二层交换来实现。ARP协议(地址解析解析)，在RFC 826中定义，是一个非常重要的二层交换协议。所有的以太网络设备都是采用ARP协议来学习MAC地址与IP地址的对应关系。网络设备可以通过ARP协议广播它的MAC地址和IP地址，让同一个子网中的其他设备知道它的存在。广播消息会到达同一个子网内的所有设备，因此也被称为广播域。采用ARP协议，所有的设备都能够了解这一子网中其他设备的存在。至于子网之间的通讯，需要三层交换机或者路由器之类的网关(gateway)设备。任何一台计算机必须连接到一个子网并设置缺省的网关，才能与其他子网的计算机互相通讯。

传输控制协议(TCP)，在RFC 793中定义，是目前两个主机之间可靠地交换数据最常用的一种协议。TCP协议是一个有状态协议，也就是说必须经过建立TCP连接，交换数据和终止连接的过程。TCP保证了数据的有序发送，并且通过校验值保证数据的完整接收，运行在TCP协议之上的高层应用就不需要再考虑数据完整性的问题了。如图1.1中的OSI模型所示，TCP是四层协议。

TCP的工作方式如图2.1所示，建立TCP连接需要三次握手，在这一例子中，客户端想与服务器交换数据，客户端发送一个SYN数据包到服务器。SYN包中的重要信息包括源IP地址、源端口、目的IP地址、目的端口。源IP地址是客户端的IP地址，而源端口是由客户端随机生成的。目的IP地址是服务器的IP地址，而目的端口地址是服务器上应用的监听端口。标准应用如Web服务和文件传输协议(FTP)分别采用端口80和21。其他应用可能采用其他的端口，但是客户端必须知道应用的端口号码以便访问这一应用。SYN数据包还包含有一个起始的序列号。客户端到服务器每一个新的连接的起始序列号是逐次递增的。当服务器接收到SYN数据包时，它回应一个SYN ACK数据包，数据包中包含服务器自己的起始序列号码。客户端于是回应一个ACK数据包表示连接建立，之后客户端和服务器就可以在这个连接上交换数据了。每个TCP连接都由四个值唯一表示：源IP地址、源端口号码、目的IP地址和目的端口号码。每个给定TCP连接的数据包中这四个值是相同的。注意从客户端到服务器的数据包的源IP地址和客户端的源端口号码变成从服务器到客户端的数据包的目的IP地址和目的端口号码，源通常指的是发送数据包的主机。一旦客户端和服务器完成数据交换的工作，客户端就发送一个FIN数据包，而服务器发送一个FIN ACK数据包，这样就结束了一个TCP连接。当会话正在进行中的时候，客户端或者服务器发送一个TCP RESET给对方将中止一个TCP连接。在这种情况下，如果还需要交换数据则必须重新建立连接。

UDP协议是另外一个非常流行的四层协议，经常被流媒体之类的应用所采用。跟TCP不同，UDP是无状态协议，使用UDP交换数据时不需要建立或者结束一个会话，UDP不象TCP那样提供可靠的传输保证。在UDP上运行的应用必须自己保证数据的可靠传输。我们仍然认为两个主机间使用UDP交换数据是一个会话，但是我们无法确定UDP会话的起始和结束。一个UDP会话同样可以通过源IP地址，源端口号码，目的IP地址，目的端口号码来唯一标记。

当一个用户在其浏览器上输入URL (统一资源定位) HTTP://www.xyz.com后，在后台需要完成许多工作，才能看到网页。在我们介绍负载均衡内容之前有必要了解一下这些基本知识。

首先，浏览器通过本地DNS服务器(LDNS)把www.xyz.com解析成一个IP地址。网络管理员将部署一台本地DNS服务器，把这个DNS服务器的IP地址设置在客户端的计算机中。本地DNS服务器利用域名系统协议去查找www.xyz.com 授权的DNS服务器。一旦本地DNS服务器从授权的DNS服务器上面查到www.xyz.com的IP地址后，它会告诉客户端的浏览器。浏览器于是跟这个IP地址建立了一个TCP连接，然后发送HTTP (超文本传输协议) 请求获取HTTP://www.xyz.com 的Web页面，服务器返回一个页面，其中包含一些图片或者其他对象的链接，浏览器随后获取这些对象并组合成一个完整的页面显示给客户。

版本不同，HTTP请求和响应格式也不相同，详细内容可以参考RFC 1945（HTTP1.0）和RFC 2068（HTTP1.1）。

许多服务器管理员为了提高可用性和可扩展性，都会部署多台服务器。如果一台服务器出现故障，在对其进行维护的时候可以用其他的服务器提供服务。在负载均衡器出现之前，通常采用DNS轮循的方式在多台服务器之间分发负载。举例来讲，在www.xyz.com授权的DNS服务器上面可以为域名www.xyz.com设置两个或更多的IP地址。DNS服务器使用轮循的方式为每个DNS解析请求提供一个IP地址。这种方法提供了最基本的负载均衡，但是存在局限性。DNS服务器无法知道服务器的健康状态和负载压力，即使某台服务器出现故障，它也会继续解析这个服务器的IP地址。甚至在网络管理员手工修改DNS配置，移除这台失效的服务器的IP地址之后，很多本地DNS服务器和浏览器也会缓存第一次解析的结果，不会重新查询。发明DNS不是用来做负载均衡的，它最初的目的是为互联网提供域名到IP地址的转换。 下面我们讨论一个负载均衡器和服务器群的部署方式及其优缺点。如图2.2所示，负载均衡器部署在服务器群之前，所有的服务器直接连接在负载均衡器上或者通过交换机连接到负载均衡器。在客户端看来，负载均衡器与服务器群就象一个虚拟的服务器。真实服务器(Real Server)指的是连接在负载均衡器上真实的服务器。就象真实服务器一样，虚拟服务器必须有一个IP地址对客户端提供访问，称为虚拟IP (VIP)。VIP配置在负载均衡器上，代表后面的整个服务器群。

为了访问服务器上面的应用，客户端发出访问VIP的请求。在前面的例子中，需要配置授权的DNS服务器，把域名www.xyz.com解析成VIP的地址。这样所有的客户端浏览器发送请求到VIP而不是真实的服务器。负载均衡器上面配置了这个VIP，因此接收所有的客户请求，并将请求分发到可用的真实服务器上面。通过部署负载均衡器我们可以获取以下几点益处：

因为负载均衡器分发客户端的请求到所有可用的真实服务器上，虚拟服务器集群的处理能力大大超过了一台服务器的处理能力。负载均衡器采用负载均衡算法把客户端的请求分发到所有的真实服务器中。如果算法适当，虚拟服务器的处理能力将等于所有真实服务器处理能力的总和。但是由于各种各样的原因，比如负载均衡算法的效率等因素，这一点比较难实现。不管怎么样，即便虚拟服务器的处理能力只有所有服务器处理能力之和的80%到90%，也是非常优秀的可扩展能力。

负载均衡器实时地监控真实服务器上运行的应用系统的健康状况，如果检测出一个真实服务器或者应用出现故障，负载均衡器将不再把任何客户端的请求发送到该服务器。虽然此故障服务器上已经建立的连接和请求都会丢失，但是所有新进的请求都会被负载均衡器导向到其他可用的真实服务器上面。如果没有负载均衡器，我们就必须依赖于网络监控工具来检查服务器和应用的健康状态，并且手工的将客户端的请求导向到另外一台真实服务器。负载均衡器能够实时进行健康状态的检查，可以显著减少应用的停机时间。当有故障的服务器被修理好之后，负载均衡器会自动检测健康状态的变化并重新将请求发送到这台服务器上面。

如果一台服务器的硬件需要升级，或者它的操作系统及应用软件必须升级到一个新的版本，服务器必须下线。尽管升级的工作可以安排在非高峰时间以减小系统停机的影响，但还是会有停机时间，而有些商业应用无法接受这样的停机时间。有些应用也许就不存在真正的非高峰时间，特别是服务器对全球不同时区的用户提供访问的情况下。通过部署负载均衡器，我们能够透明地将服务器下线维护，并且不存在任何系统停机时间。负载均衡器能够无缝的关闭一台服务器，首先停止向这台服务器发送新的请求，并等待已经存在的连接正常结束，当所有的连接都结束之后，服务器可以被安全地下线维护了。负载均衡器继续把访问VIP的请求分发到其他正常工作的服务器上面，因此这个过程对于客户端来讲是完全透明的。

负载均衡器也能够把应用跟服务器分离，来帮助提高可管理性。举例来讲，我们假设有10台真实的服务器而且我们必须运行两个应用：Web(HTTP)和FTP。因为Web服务的访问压力较大，因此两台服务器运行FTP，剩下八台服务器作为Web服务器。在没有负载均衡器的时候，我们会采用DNS轮循的方式为两台FTP服务器、八台Web服务器进行简单的负载均衡。如果FTP的访问量突然增加，需要增加运行FTP的服务器，我们必须修改DNS的配置把新增服务器的IP地址加进来。这需要很长时间才能生效，不能立即解决性能瓶颈的问题。如果采用负载均衡器，我们只需要宣告一个VIP。我们可以配置负载均衡器，把服务器1和服务器2关联到FTP的VIP，而服务器3到服务器10关联到WEB应用的VIP，也称之为绑定。在FTP的知名端口21上接收所有的FTP请求，负载均衡器根据目的端口号确认请求类别并将其导向到对应的服务器。当FTP的访问量突然增加时，需要服务器3也运行FTP应用，就把服务器3绑定到FTP的VIP上。负载均衡器会知道有三台服务器运行FTP服务，而将请求在这三台服务器之间分发，这样一来立即增加了FTP的处理能力。将应用从一台服务器上移动到另外的服务器上或者针对给定的应有增加服务器而不中断客户的请求对于服务器管理员来说是一个强大的工具。

负载均衡器能够帮助管理大量的内容，我们称之为内容管理。有些Web服务器有太多的内容需要提供服务，以至于这些内容不适合只放在一台服务器上面。我们可以把服务器分成不同的组，每个组服务器负责一部分特定的内容，而负载均衡器根据HTTP请求内的URL选择对应的服务器组。

负载均衡并不需要了解服务器的操作系统，因为它们工作在标准的网络协议之上。负载均衡器能够将请求导向到任意的服务器上而不用考虑它运行的是哪一种操作系统。这种技术使得管理员能够将不同的服务器组合在一起，从而达到扩展处理能力的目的。

因为是放在服务器群之前，负载均衡器能够保护服务器免受恶意用户的破坏。许多负载均衡产品包含多种安全功能，阻止特定的攻击到达服务器。真实的服务器可以使用私有的IP地址，在RFC1918中定义，以阻止外部用户直接访问服务器。私有的IP地址是无法在Internet上路由的，任何在公网的用户必须通过网络地址转换(NAT)才能与私有IP地址的主机通讯。负载均衡器可以做网络地址转换，这是它做负载均衡，也就是将客户请求分发到不同的服务器的最基本的工作内容。负载均衡器上的VIP可以是公网的IP地址，这样才能够对Internet用户能够访问。但是在负载均衡器后面的真实服务器可以使用私有的IP地址，强制所有的通讯都要通过负载均衡器。

服务质量有很多种定义方式，它可以被定义为服务器和应用的响应时间，应用的可用性，或者根据客户类型的不同以提供不同的服务。比如，一个提供跳伞运动信息的网站希望给白金客户提供的响应时间比黄金客户或白银客户的更好。负载均衡器可以根据数据包中的一些信息来区分客户类型，并把这些请求导向到对应的一个或一组服务器，或者通过设置IP包中相应字段来提供相同的功能。

我们以图2.2为例，讨论采用负载均衡器后数据包的流程。如图2.2所示，有三台服务器，RS1到RS3，还包含三种应用：Web(HTTP)，FTP，和SMTP，分别在三台服务器上运行。在这个例子中，所有的应用都运行在TCP之上，而且每个应用都使用不同的TCP端口。WEB应用在80端口上运行，FTP在21端口上运行，而SMTP在端口25上运行。负载均衡器根据接收的TCP数据包中的目的端口号识别客户端需要访问的应用，并为每个客户请求选择合适的服务器。选择服务的过程分两步，第一，负载均衡器必须判断哪些服务器上面的应用是可用的。服务器和应用是否可用由健康检查决定，我们将会在后面的章节中详细讨论。第二，负载均衡器采用一种负载均衡算法来选择服务器。常用的复杂均衡算法有轮循、最小连接数、权重、最快响应时间等，负载均衡算法将会在后面的章节详细讨论。

负载均衡器的配置包括以下几个步骤：

1．定义一个VIP：VIP=123.122.121.1；

2．确定哪些应用需要负载均衡：Web、FTP和SMTP；

3．对每个应用，绑定VIP到相应的真实服务器：把RS1和RS2绑定到Web的VIP；把RS1绑定到FTP的VIP；把RS2和RS3绑定到SMTP的VIP。也就是说，VIP的80端口绑定到RS1和RS2的80端口；VIP的21端口绑定到RS1的21端口，依此类推，如图2.2所示；

4．设置健康检查，用来检查服务器和应用的健康状态；

5．设置负载均衡算法。 通过把VIP绑定到真实服务器的不同TCP端口，我们把服务器和应用分离开，提供了强大的灵活性。举例来说，如果FTP应用的访问量增加，只需要把另外一台服务器绑定到VIP的21端口就可以增加FTP服务的处理能力。如果RS2需要下线维护，我们可以利用负载均衡器实现RS2的无缝停机，也就是停止向RS2发送任何新的请求，并等待所有的在线连接关闭，然后将RS2停机。

注意示例中所有的真实服务器都使用私有IP地址，这样做有两个好处：首先，只用一个公网IP地址，也就是VIP，来表示所有的服务器群可以节省IP地址空间；第二，提高了安全性，任何客户的请求都不能绕过负载均衡器直接访问到服务器。

对于负载均衡器能够做什么，现在我们都了解了，下面看一下采用负载均衡器后数据包的转发流程。

我们用一个简单例子，如图2.3所示，来了解请求响应过程中数据包的转发流程。客户端首先建立一个TCP连接，如图2.1所示，发送HTTP请求，接收服务器响应，并关闭这个TCP连结。建立TCP连接需要三次握手，负载均衡器接收到的TCP SYN请求包含以下信息：

源IP地址：客户端的IP地址；

源端口：客户端用于此TCP连接的端口号码；

目的IP地址：VIP地址；

目的端口：由于请求访问的是WEB应用，所以目的端口是80。

上述四个因素唯一标识了一个TCP会话，当负载均衡器接收到第一个TCP SYN数据包后，假定选择RS2处理这个请求，并将请求发送到RS2。为了让RS2接收TCP SYN数据包并进行处理，必须把数据包的目的地址修改为RS2的私有IP地址，而不是VIP的IP地址。因此，负载均衡器在转发数据包之前会把目的地址修改为RS2的IP地址，这个IP地址转换的过程称为网络地址转换(NAT)。(更多关于NAT的信息，可以查阅<<NAT手册：实施和管理网络地址翻译>>，Bill Dutcher著，John Wiley&Sons出版)。更确切的讲，由于负载均衡器修改的是目的地址，所以也称为目的地址NAT。

当用户敲入www.xyz.com之后，浏览器会产生一个DNS查询请求，获取www.xyz.com对应的IP地址，也就是VIP。然后客户端的浏览器发送TCP SYN数据包以建立一个新的TCP联接。当负载均衡器接收TCP SYN数据包后，它先确认这个请求是需要做负载均衡的数据包，因为数据包的目的地址是VIP。由于这是一个新的连接，负载均衡器无法在会话表中通过源IP地址、目的IP地址、源端口地址、目的端口地址查到这一个会话。根据负载均衡设置和健康检查的结果，负载均衡器确认RS1和RS2可以接收新建连接。根据预先定义的负载均衡算法，负载均衡器选择RS2来处理这个会话请求。服务器选定之后，负载均衡器在它的会话表中建立一个新的记录，并把数据包的目的IP地址和目的MAC地址修改为服务器RS2的IP地址和MAC地址，然后把数据包发送到RS2。

当接收到TCP SYN包之后，RS2会应答TCP SYN ACK包，数据包的源地址是RS2的IP地址，而目的地址就是客户端的IP地址。负载均衡器接收到这个数据包之后，再把RS2的IP地址修改为VIP的IP地址，并把数据包发送到路由器，最终路由到客户端。这个TCP会话后续所有的请求和回应数据包都是经过同样的流程。最终，当通过FIN或RESET结束或终止这个连接时，负载均衡器在其会话表中删除这个会话记录。

现在我们来跟踪数据包的流程，看一下IP地址和MAC地址是如何改变的。当路由器接收到数据包时，数据包的目的IP地址是VIP，而目的MAC地址是M1，也就是路由器的MAC地址。第一步，如图2.3中所示，路由器把目的MAC地址修改为M2并把数据包发送到负载均衡器，M2是负载均衡器的MAC地址。第二步，负载均衡器把目的IP地址和目的MAC地址修改为RS2的IP地址和MAC地址，并发送到RS2。第三步，RS2响应客户端的请求。因此，源IP和源MAC都是RS2的地址，而目的IP地址是客户端的IP地址。RS1和RS2的缺省网关是负载均衡器的IP地址。因此，目的MAC地址是负载均衡器的MAC地址。第四步，负载均衡器接收数据包之后，把源IP地址修改为VIP的地址，使得回应看起来跟VIP发出的一样。这一点非常重要，TCP连接是建立在客户端和VIP之间的，并不是真实服务器，所以回应的数据包必须看起来象是从VIP发出的一样。为了数据包能够正常到达客户端，负载均衡器需要把数据包转发给它的下一跳，也就是路由器。负载均衡器把源MAC地址修改为自己的MAC地址M2，目的MAC地址修改为路由器的MAC地址M1，然后把数据包转发至路由器。

在这个例子中，负载均衡器作为真实服务器的缺省网关。其实，也可以用路由器作为服务器的缺省网关。那样的话，从真实服务器返回的数据包的目的MAC地址为M1，也就是路由器的MAC地址，而负载均衡器对源MAC和目的MAC不做任何改动。对于其他的二、三层交换机和主机而言，负载均衡器就相当于一个二层交换机，我们将在第三章讨论负载均衡器启用三层交换功能的情况。

通过健康检查来确定服务器和应用的健康状况是负载均衡器器一个非常重要的功能。没有负载均衡器，客户端可能会将请求发送到已经停机的服务器上。网络管理员必须手动干预替换这台服务器，或者排除服务器的故障。有时服务器可能没有停机，但是因为某种原因，比如软件的漏洞，服务器上面运行的应用系统已经不能正常工作。比如Web应用可能正常运行，但它返回的页面却是错误的内容。负载均衡器能够检测这些情况并立即将客户请求导向到正常的服务器而不需要管理员的干预。

总的来说，健康检查分有两类：带内健康检查和带外健康检查。带内健康检查就是负载均衡器观察客户端跟服务器之间的流量判断服务器是否健康。例如，如果负载均衡器发送一个客户端的SYN数据包到真实服务器，但是没有收到SYN ACK数据包回应，负载均衡器就会怀疑这台真实服务器有问题。负载均衡器也可以直接发送健康检查的数据包来检验真实服务器是否健康，这种数据包是由负载均衡器自己产生的。

负载均衡器可以提供多种健康检查方式，能够在OSI不同层面进行基本的健康检查：

二层的健康检查就是发送一个ARP请求查找给定IP地址的MAC地址。负载均衡器上面配置了真实服务器的IP地址，它会给每个IP地址都发送一个ARP请求，以找到其对应的MAC地址。服务器会响应这个ARP请求，除非它已经停机。

三层的健康检查就是发送一个”PING”包到每个真实服务器的IP地址。”PING”是一个常用的程序，用来确认一个IP地址是否在网络中存在，或者用来确认主机是否运行。

四层的健康检查，负载均衡器会尝试连接到服务器上面应用程序运行的特定的TCP或UDP端口。举例来说，假定真实服务器通过80端口来提供Web应用，负载均衡器会尝试建立一个到真实服务器80端口的连接。负载均衡器发送一个TCP SYN请求包到每个真实服务器的80端口，检查是否接收到回应的TCP SYN ACK数据包，如果没有收到，负载均衡器就认定相应服务器的80服务有故障。负载均衡器有必要针对服务器的每个应用端口分别做健康检查，比如，RS1的80服务可能有故障，但是21端口还能正常工作，负载均衡器可以继续利用这个服务器的21端口提供FTP服务，但是把WEB应用标记为停机状态。这样一来就提供了一个高效率的负载均衡解决方案，精细的健康检查有效地提高了服务器的处理能力。

负载均衡器能够对常用的应用进行七层或者应用级的健康检查。针对应用级的健康检查没有统一的规范，而且不同的负载均衡产品也有不同的健康检查方法，让我们通过几个例子看一下应用健康检查包含哪些内容。

针对Web服务器，负载均衡器可以发送针对某一特定URL的HTTP GET或者HTTP HEAD请求。可以让负载均衡器检查HTTP响应状态码，这样就可以检测到“404 Object not found”之类的错误响应。对于DNS服务器，负载均衡器可以发送DNS查询请求，把指定的域名解析成IP地址，并将结果与期望的结果做比对。对于FTP服务器，负载均衡器可以使用一个特定的账号和密码登陆到FTP服务器，来确认其是否正常工作。

有时侯我们可能在真实服务器上面运行多个互相关联的应用。例如，WEB服务器在它的80端口提供购物车的Web应用，443端口则运行另外一个使用SSL协议的应用。SSL可以在通信过程中对信用卡信息等敏感内容进行加密，保证客户端和服务器之间通信的安全性。客户端首先浏览网页，把商品放进购物车，然后按下结帐的按钮。浏览器就会跳转到SSL应用，即提交信用卡信息来购买购物车中的商品。SSL应用通过WEB应用获取购物车的内容，如果SSL应用出现故障，那么WEB应用也应该停止服务。否则，就可能出现用户可以在购物车中增加商品但是不能访问SSL应用从而无法结帐的情况。许多负载均衡产品支持端口分组的功能，就是将多个TCP或者UDP端口组合在一起。如果这个组中任何一个应用出现故障，负载均衡器就认为这台真实服务器的所有应用都出现故障。这样就可以保证用户被导向到能够正常完成所有应用的服务器，从而保证交易的完整性。

即便服务器和应用都能够通过健康检查，但是它提供的内容还是有可能存在问题。举例来说，某个文件可能损坏或者被替换，这时可以通过负载均衡器来检查内容是否正确，不同的负载均衡产品有不同的检查方法。负载均衡器发送HTTP GET请求，获取指定的URL进行应用级别的健康检查时，它就可以确认接收到的WEB页面是否正确。确认内容正确性的方法通常有两种，第一种方法是用关键字过滤整个网页，另外一个方法是计算校验码，并跟预先配置的值进行对比。对于其他的应用，如FTP，负载均衡器可以下载一个文件，并通过计算校验码来验证内容的正确性。 另外负载均衡器可以通过HTTP GET请求检查一个特定的CGI或者ASP页面。例如，设置需要检查的URL为“HTTP://www.abc.com/q?check=1”，当服务器接收到这个请求时，它会根据传递的参数”check=1”运行相关程序进行扩展的服务器检查，包括后台数据库、服务器的内容等，并返回HTTP的状态代码给负载均衡器。这种方法消耗负载均衡器的资源较少，同时能够提供服务器扩展健康检查，因此被广泛采用。

还有另外一种简单灵活的健康检查方法，让负载均衡器到服务器上面获取一个URL：“HTTP://www.mysite.com/test.html”。服务器上面运行一个程序，定期检查服务器、应用、后台数据库和内容的健康状态，如果一切正常的话，程序会创建一个名为test.html的文件，否则就删除文件test.html。当负载均衡器发送HTTP GET请求test.html文件时，就可以根据这个测试文件是否存在来判断服务器的健康状况。

某些负载均衡器可以提供自定义脚本指令来做健康检查的功能，这些设备大多基于UNIX或者LINUX开发，这些操作系统支持多种脚本语言，用户可以非常容易的编写一段脚本指令来检查服务器、应用和内容的健康状况。 熟悉脚本语言的服务器管理员大多喜欢这种健康检查方法，可以从这种灵活、强大的健康检查机制中体验到非凡的乐趣。

就象在服务器上运行一个程序来检测服务器的负载一样，我们也可以用一个插件来监控服务器的健康状况。因为插件就在服务器上运行，它可以获取大量的信息以确定服务器的健康状况。某些负载均衡产品的厂商为每个主流的服务器操作系统都提供一个插件，而插件将通过应用编程接口把服务器、应用和内容的健康状况通知负载均衡器。某些厂商公布它们的应用编程接口，以便客户能够编写自己的插件程序。应用编程接口(API)可以是厂商专用的或着是开放的标准。例如，客户可以写一段程序，把服务器的健康状况通过SNMP(简单网络管理协议)传递给负载均衡器。

图2.8中所示就是一个非常好的例子，每个Web服务器都绑定一个后台的数据库服务器。在实际应用中，WEB服务器和数据库服务器并不是一对一绑定的，通常是所有的Web服务器共享一组数据库服务器。不管哪种情况，如果后台的数据库服务器出现问题，Web服务器就无法处理客户请求。使用服务器端的插件程序就能够准确检查后台数据库服务器的健康状态，将结果转换成Web服务器的健康状况，并反馈给负载均衡器。这也可以通过基于内容的健康检查来实现，负载均衡器通过HTTP GET请求一个特定的URL，服务器接收到请求之后，运行相关程序检查WEB服务器和后端数据库服务器的健康状况。

有如此众多的健康检查的方法，那么，到底哪种健康检查方法最合适呢？答案是视具体情况而定，但还是会有一些最基本的原则供参考。

优先选择负载均衡器提供的标准的健康检查，而不是专用的代码或者API的健康检查方式。这样，更换负载均衡产品时就非常方便，如果有必要的话。另外负载均衡器不要运行过多不必要的健康检查，它最根本的工作是做负载分担，如果在健康检查上花过多的时间，会影响数据包分发的工作。尽可能地采用带内检查的方式，这时负载均衡器通过客户端和服务器之间正常的通信来判断服务器的健康状况，对资源的占用较少。而带外的健康检查方式能够有效监控带内健康检查所无法侦测的信息。例如，负载均衡器能够很容易地通过带内检查技术检测服务器是否响应TCP SYN请求，但是它不能确定服务器返回的内容的正确性。所以，需要配置带外的应用健康检查来检查内容的正确性。在服务器上面使用智能的插件或者脚本来检查服务器的健康状况也是一个不错的选择，有两个重要的原因：首先，它给管理员极大的灵活性，可以编写脚本检查任何需要检查的内容；第二，它有效地将负载均衡器的负荷降到最低，使负载均衡器能够集中精力处理更多的用户请求。

网络地址转换是负载均衡技术中最基础的部分，负载均衡器本质上就是通过NAT把客户请求导向到多个真实服务器。负载均衡器是把目的地址由VIP修改为真实服务器的IP地址，这被称为目的地址NAT。当真实服务器回应时，负载均衡器必须将真实服务器的IP地址再修改为VIP的地址。需要注意的是这时数据包是由服务器发给客户端的，因此此时转换的是源地址。为了简单起见，我们把这种NAT称为un-NAT，因为负载均衡器必须要把数据包恢复成原来的样子，使得回应的数据包看起来好象是从VIP发出的一样。

为了理解负载均衡时的网络地址转换，有三个字段需要特别注意：MAC地址、IP地址和TCP/UDP端口号。

改变数据包目的地址的过程称为目的地址NAT。大多数负载均衡产品缺省都是进行目的地址NAT，图2.3所示就是负载均衡时目的地址NAT。每个数据包都有源地址和目的地址，由于目的地址NAT只处理目的地址，它有时也被称为half-NAT。

如果负载均衡器在改变目的IP地址的同时也改变数据包的源IP地址，就称为源地址NAT。因为在这一过程中源地址和目的地址都会被转换，因此有时也称之为full-NAT。源地址转换不常用，除非在特定的网络环境下。比如真实服务器回应数据包不经过负载均衡器时，我们就必须要用源地址NAT了，如图图2.9所示。图2.10是一个需要做源地址NAT的网络设计方案，在这些方案中采用源地址NAT，强制服务器回应的数据包必须经过负载均衡器。源地址NAT有两种替代方案，直接服务器返回(DSR)或者把负载均衡器做为真实服务器的缺省网关。这两种替代方案均要求负载均衡器和真实服务器在一个广播域中或者是一个二层域中。我们会在后续章节中详细介绍服务器直接返回（DSR）技术。

使用源地址NAT时，负载均衡器在把数据包转发到真实服务器之前会把源IP地址修改为预先定义好的一个地址，如图2.11所示。可以把源地址转换成VIP的地址或者其他IP地址，这取决于负载均衡器上面的设置。当服务器接收到数据包时，因为源地址被转换了，它会认为客户端就是负载均衡器。真实服务器并不知道真正的客户端的源IP地址。真实服务器发送响应到负载均衡器，负载均衡器再把目的IP地址转换为真实客户端的IP地址。

站在负载均衡器的角度看，需要建立两个会话：客户端的会话和服务器端的会话。每个客户端的会话都对应一个服务器端的会话。图2.12给出了客户端会话与服务器端会话之间的对应关系。所有服务器端会话的源IP地址都是在负载均衡器上面预先定义的，负载均衡器为每个服务器端的会话分配一个不同的源端口号码来确保与客户端会话的唯一性。但由于TCP端口号码的限制，负载均衡器通过一个源IP地址最多能够支持65536(64K)个并发会话。为了支持更多的并发会话，负载均衡器上面一般会设置多个源IP地址。

源地址NAT的好处是可以让用户在任何位置部署负载均衡器，不受网络拓扑的限制。缺点是真实服务器看不到客户端的IP地址，因为负载均衡器改变了源IP地址。必须根据源IP地址认证客户端的应用系统，如果采用了源地址NAT的话，认证将失败。许多网站的管理员也会分析日志信息中的源IP地址，这时也不宜采用源地址NAT。不过有些负载均衡产品能够提供一些选项，以日志的方式输出客户端源地址。

使用负载均衡器时，为了节省公网的IP地址资源、提高真实服务器的安全性，真实服务器常常使用私有的IP地址。对于所有客户端访问虚拟服务器的流量，负载均衡器都会把数据包的目的地址进行转换。但是，如果在负载均衡器后边部署的真实服务器需要主动发起连接，与外部世界通讯时，也必须经过地址转换，因为真实服务器使用的是私有IP地址。可以在负载均衡器上面设置反向NAT来解决这个问题，即真实服务器发起访问外部的请求时，由负载均衡器把数据包的源IP地址进行转换，把真实服务器的IP地址转换成一个预先定义好的公网IP地址。这个公网地址可以和VIP共用一个地址，也可以使用一个单独的地址，这取决于负载均衡设备自身的设置。

增强型NAT是指对特定协议进行负载均衡时，为了保证通讯正常，在负载均衡器上面进行了特殊处理的NAT。到目前为止，我们所讨论的NAT只涉及到数据包头中IP地址的变化，但是某些特定的协议在数据通讯时会把本机的IP地址或端口等信息封装在数据包有效载荷里面。因此，在修改数据包头信息的时候，数据包内的相应信息也需要修改。针对这种协议，就需要负载均衡器进行智能处理。很多应用协议在进行负载均衡时都需要增强型NAT进行处理，在此，我们只讨论负载均衡领域最常见的一种协议流媒体协议。因为流媒体协议是一种对计算性能和网络I/O处理能力非常敏感的一种应用，流媒体服务器一般只能处理几百或者上千个并发连接。因此，提高流媒体处理能力和可扩展性的有效途径就是采用负载均衡。

常用的流媒体协议有多种，如Real Networks的Real Media协议，和Microsoft的Windows Media Player。Real Media协议是基于RFC 2326所定义Real Time Streaming Protocol (RTSP)标准。流媒体协议一般都包含两个连接：控制连接和数据连接。控制连接是基于TCP的，而数据连接是基于UDP的。客户端首先在服务器的知名端口上打开一个控制连接，然后客户端和服务器协商数据连接的通讯方式，如图2.13所示。协商内容包括客户端需要与服务器建立数据连接的服务器IP地址和端口号码。如果服务器使用私有的IP地址，负载均衡器需要对控制连接执行目的地址NAT的同时还必须检查它们协商的内容，把服务器返回的数据中私有IP地址或端口信息转换成公网VIP地址和相应端口，以保证客户端的数据连接是发送给公网的VIP而不是服务器的私有IP地址。并且，客户端和服务器之间协商的端口可能是一个随机的端口，因此负载均衡器必须正确地处理发送给VIP的UDP请求，因为这个随机的端口并没有绑定到任何服务器。由于许多企业网络中防火墙上面安全策略的限制，基于UDP的数据连接无法成功建立。许多播放器能够播放基于TCP或HTTP协议的流媒体，即整个连接都建立在HTTP协议之上。

在本书中，端口地址转换(PAT)是指修改TCP/UDP数据包中的端口号码，虽然这个端口号码也可能在其它协议中使用。PAT是负载均衡器最基本的特性，比如VIP使用端口80，而真实服务器使用端口1000时，负载均衡器接收到请求以后，就把目的端口从80修改为1000，并转发给真实服务器。PAT有三个优点：提高安全性，提高应用的可扩展性和应用的可管理性。 让应用系统运行在私有端口之上，我们就可以关闭真实服务器的知名端口，以提高安全性。举例来说，在真实服务器的4000端口上运行Web服务，并将VIP的80端口与真实服务器的4000端口绑定。客户端将不会发现有任何不同，Web浏览器继续发送Web请求到VIP的80端口。负载均衡器转换所有接收到的数据包的端口号码并将请求转发到真实服务器的4000端口上。现在，黑客就不能通过80端口对真实服务器发动攻击，因为真实服务器已经将80端口关闭了。当然，这只能稍微增加一点攻击的难度，黑客还是能够很容易的发现服务器开放的端口。解决安全性问题没有一劳永逸的方法，需要通过多种途径来提高服务器群和网站的安全性。 提高安全性的方法之一就是给真实服务器设置私有IP地址，或者通过访问控制列表拒绝所有直接访问真实服务器IP地址的流量，强制客户端必须通过负载均衡器访问真实的服务器，在负载均衡器上面配置相应的策略防御特定类型的攻击。

有了PAT，我们就可以在多个端口上面运行同样的应用，提高了可扩展性。有的应用系统允许同时运行多个副本，运行多个副本能够更有效地利用服务器的资源。以微软的IIS为例，我们在每台服务器的端口80，81，82，和83上分别运行IIS，将VIP端口80绑定到每个运行IIS的端口上。这样，负载均衡器不仅仅在真实服务器之间分发流量，还可以在每台服务器上的多个端口之间分发。

PAT在特定的环境下也能够提高可管理性。举例来说，我们在一组服务器上托管了多个虚拟主机，所有的域名都可以使用同一个VIP。不同域名的虚拟主机运行在不同的端口之上，比如www.abc.com运行在80端口上，www.xyz.com运行在81端口上，负载均衡器在VIP的80端口接收所有的请求，并根据访问的域名把请求分发到服务器的不同端口上。为了能够基于URL中的域名进行负载均衡，选择不同的服务器，负载均衡器必须执行延迟绑定并基于URL选择不同的服务器，我们将会在第三章详细介绍延迟绑定和 URL交换。

迄今为止，在我们讨论的所有网络结构中，服务器返回的数据都经过负载均衡器。如果没有的话，我们使用源地址NAT强制服务器返回的数据经过负载均衡器，负载均衡器处理请求的同时也处理响应。DSR(服务器直接返回)技术可以让服务器响应的数据包不经过负载均衡器。这样，负载均衡器只需要处理请求的数据包，极大地降低了需要处理的数据包的数量，就可以防止负载均衡器成为性能瓶颈，从而获得更好的效率。为了实现DSR，需要负载均衡器在把请求转发给服务器时，不转换目的IP地址，这样回应的数据包就不需要进行地址转换，就可以不经过负载均衡器直接返回给客户端。

在配置实现DSR时，负载均衡器只转换请求数据包的目的MAC地址，目的IP地址保持不变，还是VIP的地址。为了保证请求的数据包只根据MAC地址就到达真实服务器，所以真实服务器必须与负载均衡器在同一个二层广播域。一旦数据包到达真实服务器，其目的IP地址是VIP而不是真实服务器的IP地址，所以我们必须让真实服务器接收这个数据包。因此，需要把每个真实服务器的Loopback地址设置成VIP的地址。Loopback地址是一个逻辑的IP接口，存在于任何一台运行TCP/IP协议的主机上面。它通常被设置为127.x.x.x，其中x.x.x可以是任何数字。一个主机可以设置多个Loopback地址，如127.0.0.1，127.0.0.10，和127.120.12.45，实际支持的Loopback地址的数量取决于操作系统本身。

地址解析协议(ARP)用来在以太网上发现主机IP地址及其相应的MAC地址。根据定义，Loopback地址不响应ARP请求。因此，网络中没人知道Loopback地址的存在，因为它完全是在主机内部使用。我们可以把Loopback地址设置成任意的IP地址，也就是说，这个IP地址不一定非要以127开头。主机不响应Loopback地址的ARP请求，但是它可以响应那些发送给这个IP地址的数据包。所以如果客户端知道一台主机上面定义的Loopback地址的话，它就可以发送请求到这台主机上的Loopback地址。如果Loopback地址确实被定义了，主机就会接收并处理这个请求。DSR技术就是在上述前提条件下不修改请求数据包的目的地址，把VIP地址配置成服务器的Loopback地址，使服务器接收并处理的。

采用DSR技术时，数据包处理的流程图如图2.14所示。首先，负载均衡器并不修改数据包的目的地址，维持VIP地址不变，把目的MAC地址修改为指定的服务器的MAC地址。由于负载均衡器与真实服务器之间的交换机是二层交换机，它简单地把数据包转发给目的MAC地址所对应的服务器。真实服务器接收请求，因为目的IP地址是其Loopback地址。当服务器回应时，源地址变成的VIP地址，目的地址变成了客户端的IP地址。数据包通过二层交换机转发到路由器，并随后转发到客户端，避免了在回应中出现任何的NAT。因此我们成功的使回应的数据流不经过负载均衡器，直接转发到客户端。

下面讨论一下如何在一些主流的操作系统中设置Loopback地址。在Sun Solaris操作系统上可以使用以下命令把141.149.65.3设置为一个Loopback地址：

ifconfig lo0:1 vip addr 141.149.65.3 up

这个命令只会影响到正在运行的配置，如果设备重启，会失效，需要重新配置。为了保证上述配置永久生效，需要把上述命令写入一个脚本文件中，在重启或加电过程中执行这个脚本即可。

在Linux操作系统上可以使用以下命令把141.149.65.3设置为一个Loopback地址：

ifconfig lo0:0 141.149.65.3 netmask 255.255.255.0 up

这个命令只会影响当前运行的配置，使其永久生效的方法同Sun Solaris操作系统环境下的配置方法。

对于那些对流量比较敏感的应用来说，DSR是一个非常有用的功能，比如FTP或流媒体。此类应用服务器返回的数据跟请求的数据相比要大得多。如果每个请求包都会产生20个回应包的话，我们就可以用这种方式让20个回应数据包不经过负载均衡器，显著降低负载均衡器的压力。这样一来负载均衡器就可以处理更多的请求，从而提高了系统的处理容量。

DSR还应用于某些特殊的网络环境中，比如对NAT的要求比较复杂或负载均衡器无法支持的情况下，可以采用DSR消除地址转换的需要。举例来讲，如果一个负载均衡器不支持RTSP的增强型NAT，我们就可以采用DSR方法消除NAT的需要，因为在采用DSR时，数据包目的地址是不做转换的。 在不能确保回应包返回到负载均衡器的情况下都可以使用DSR，如图2.9、2.10和2.11所示。当然我们可以采用源地址NAT的方式强制所有返回的流量经过负载均衡器，或者采用DSR的方式使返回的数据包不经过负载均衡器。在图2.11所示的例子中，可以把负载均衡器设置成所有真实服务器的网关，强制回应的流量经过负载均衡器，这样既不需要配置源地址NAT也不需要配置DSR。我们将会在第四章详细讨论负载均衡器作为二层交换机使用的情况。

有一点需要注意，在某些特定的环境下，是不能使用DSR的，我们将在第三章详细介绍。

负载均衡器为我们提供了非常多的益处，它能够提高服务器群的可用性、可管理性、安全性和可扩展性。服务器负载均衡是负载均衡器最基本的功能，它还能够提供多种健康检查方法确保服务器、应用和内容的正确性。负载均衡的算法有很多种，可以在不同类型的服务器之间分发请求，提供了最大限度的灵活性和处理能力。最简单的就是无状态的负载均衡算法，通常采用的是更完善、更强大的有状态的负载均衡算法。

网络地址转换是是负载均衡处理的基本要素，有几种不同地址转换方法，如目的NAT和源地址NAT，有助于在不同的网络环境中采用负载均衡器。DSR能够避免在处理过程中出现NAT，从而能够在复杂NAT需求情况下部署负载均衡器。