第七章 高速缓存负载均衡

本章介绍高速缓存的基本概念,概要描述其工作原理和部署方式。然后讨论智能交换的需求、高速缓存的负载均衡并讨论高速缓存负载均衡的几种算法。
7.1高速缓存的定义
高速缓存用来存放频繁访问的Web内容,从而加快响应时间、节省网络带宽。图7.1显示了高速缓存是如何工作的。当第一个用户,用户A,使用浏览器访问URL:HTTP://www.foundrynet.com的时候,高速缓存得到这个HTTP请求,由于这是对此页面的第一次访问,高速缓存没有相应的内容。高速缓存会到foundrynet.com的Web服务器上面获取这个Web页面,并保存在本地存储,如内存或磁盘中。然后高速缓存把得到的Web内容回复给用户A。之后用户B访问相同的Web页面的时候,高速缓存再次得到访问请求,发现本地存储中有相应的内容,不必访问最终的Web服务器,直接把内容回复给用户B。用户B比用户A更快得到响应,并且由于高速缓存不用通过Internet访问最终的Web服务器,从而节省了网络带宽。
图7.1 高速缓存的工作原理
需要注意的一点是每个Web页面实际上是由许多对象构成,作为页面内容的一部分,Web服务器会返回页面中所有内嵌对象的URL。浏览器会获取每个对象,收集并显示完整的页面。
由于高速缓存代替最终用户访问原始服务器,因此也被称作代理高速缓存或者代理服务器。如果被请求的对象在高速缓存的本地存储中,并且由高速缓存提供内容,称作一次高速缓存命中;如果高速缓存内没有这个对象,称作一次高速缓存缺失。如果没有相应内容,高速缓存必须访问最终服务器获取内容。命中的次数跟请求总数的比值称作高速缓存的命中率,可以用命中率来衡量高速缓存的工作效率。命中率越高,缓存服务器自主服务的请求就越多,更能够提高用户的响应时间、节省网络带宽。
7.2高速缓存的种类
使用相同的基本原理,存放频繁访问的内容为后续访问提供服务,高速缓存可以被用来加快用户的响应时间或者提高原始Web服务器的性能。这样,高速缓存按照功能的不同可以分成两种:客户端加速和服务器端加速。客户端加速的价值所在是加快客户端响应时间、节省网络带宽。服务器端加速的价值所在是加快内容分法的速度,节省Web服务器的数量。由于高速缓存是专用设备,经过特殊处理,因此比服务器更适合提供静态内容的服务;另外Web服务器是通用设备,并没有针对静态内容进行特殊处理。服务器端加速的高速缓存可以卸载服务器提供静态内容的压力,使其更加专注于提供动态内容。
7.3部署高速缓存
根据相同的基本原理,高速缓存可以按照以下四种不同的方式进行部署和使用:
1:正向代理:用于客户端加速
2:透明代理:用户客户端加速
3:反向代理:用户服务器端加速
4:透明反向代理:用户服务器端加速
顾名思义,高速缓存以正向代理的方式进行部署用于加速客户端的Internet访问,而以反向代理的方式部署为原始服务器加速内容的分发。透明代理一般是部署高速缓存用于透明的客户端加速,客户端并不知道网络中存在高速缓存。透明反向代理按照反向代理的方式进行工作,对服务器是完全透明的。
7.3.1 正向代理
正向代理需要最终用户把本地的代理服务器配置成高速缓存服务器。需要配置每个用户的浏览器指向代理服务器。浏览器使用一种特殊的协议把用户所有的请求发送给高速缓存,高速缓存代替用户获取内容。许多企业部署正向代理用于客户端加速。把高速缓存部署为正向代理的问题是需要配置每一个浏览器指向代理服务器。然而,可以通过在用户登录到公司网络时自动执行一个脚本来解决这个问题。正向代理可以提高安全性,因为网络管理员可以只允许代理服务器访问Internet,不允许其他人访问。所有最终用户必须通过代理服务器访问Internet,由于原始服务器把代理服务器看作最终用户,这样隐藏了每个最终用户真实的IP地址。部署正向代理的另外一个问题是必须确保高速缓存的可扩展性。假设一台高速缓存能够处理500用户的访问,如果网络中有4,000个用户,就需要购买八台这样的高速缓存,在它们之间分配压力。由于每个用户都明确指向一个高速缓存,如果这个高速缓存出现故障怎么办?如果高速缓存出现故障,用户就不能访问Internet,导致可用性的瓶颈。
通过部署负载均衡器,可以轻松解决部署正向代理服务器扩展性和可用性的问题。如图7.2所示:负载均衡器部署在正向代理高速缓存的前端。在负载均衡器上面定义一个虚拟的IP地址,并把这个IP地址绑定到每个高速缓存的8080端口。由于客户端跟代理服务器之间使用8080端口通讯,因此在负载均衡器上面也使用8080端口。浏览器上面配置代理服务器时指定的端口号也是8080,所有的请求都会发到这个端口号。使用负载均衡立即解决了扩展性和可用性这两个问题。为了以后的扩展,可以透明的添加更多的高速缓存。如果一个高速缓存出现故障,请求会立即在其他可用的高速缓存之间分发,提高可用性。除此之外,还可以提供较高的可管理性,管理员可以适当停止一台高速缓存进行维护,比如软件更新,而不用影响用户的服务。
图7.2 正向代理的负载均衡
正向代理负载均衡跟服务器负载均衡非常类似。客户端浏览器的代理服务器的IP地址配置成负载均衡器上面的VIP地址。使用正向代理最大的问题是每个客户端的浏览器都必须指向代理服务器,这个问题可以在用户登录网络时自动执行一些脚本来解决,另外使用透明代理也可以解决浏览器配置的问题。
7.3.2 透明代理
把高速缓存部署成透明代理的方式,就不用配置每个用户的浏览器指定代理服务器。如图7.3所示,把高速缓存放置在Internet连接的通道上部署成透明代理的方式。由于所有的流量都通过高速缓存,它可以终止Web请求的连接,由高速缓存自己提供内容;如果缓存没有请求的内容,就到原始服务器抓取内容。用户不会感觉到网络中存在一个高速缓存。但是透明代理会带来扩展性和可用性方面的问题。首先,由于只有一条或者两条Internet链路,无法部署多台高速缓存。一条Internet链路上面只能放置一台高速缓存。第二,如果高速缓存出现故障,就完全失去了Internet访问,并不仅仅是Web访问的流量。这种部署方式让管理员的维护工作变得非常困难,比如软件升级、损坏硬件的更换等。
图7.3 透明高速缓存的工作原理
如图7.4所示,通过使用负载均衡器完成透明高速缓存的交换,可以简化透明代理高速缓存的部署。负载均衡器必须配置基于流量重定向的策略把所有目的端口为80的流量重定向到高速缓存。这条策略必须只应用在跟内网相连流量进入方向的物理端口。这一点非常重要,如果高速缓存没有相应内容的话,它会到原始服务器上面请求对象,这个请求会再次穿透负载均衡器。对于高速缓存发出的请求,负载均衡器不能再次执行重定向,而是要把请求转发给原始服务器。
图7.4 透明高速缓存交换
利用透明的高速缓存交换,负载均衡器可以对高速缓存执行健康检查,能够立即检测出高速缓存的故障。如果高速缓存出现故障,负载均衡器只要变成一个直通的交换机,两个方向转发流量即可。因为高速缓存并没有串接在网络中,客户端仍然能够访问Internet。但前提是负载均衡器跟连接Internet的交换机和路由器一样比高速缓存的可靠性要高,因为如果负载均衡器出现故障,客户端就失去了Internet连接。
7.3.3 反向代理
就像正向代理作为客户端的代理,发送请求到服务器一样,反向代理顾名思义就是作为服务器的代理,如图7.5所示。在Web服务器的前面部署反向代理时,必须配置DNS服务器,把Web站点的域名指向反向代理的IP地址,这样高速缓存就可以代替Web服务器接受用户请求。如果高速缓存没有请求的对象,它会到Web服务器上面获取对象。
图7.5 反向代理高速缓存的工作原理
为了提高扩展性和可用性,要部署多个反向代理服务器该怎么办呢?如图7.6所示,可以在反向代理高速缓存前面部署一个负载均衡器。反向代理的负载均衡跟服务器的负载均衡极其相似。需要在负载均衡器上面定义一个虚拟IP地址,绑定到反向代理的指定应用端口,比如:HTTP、FTP等。在负载均衡器看来,反向代理高速缓存看起来就像一个Web服务器。
图7.6 反向代理的负载均衡
需要紧记的一点是,反向代理高速缓存并不一定必须部署在Web服务器前端。它们可以部署在世界的任何地方。例如:原始服务器可能部署在圣何塞,而反向代理高速缓存可能部署在伦敦和新加坡。为了快速进行内容分发,客户可以使用广域网负载均衡技术把来自欧洲的用户导向伦敦,亚洲的用户导向新加坡。在第八章将会讨论内容分发网络解决方案。
7.3.4 透明反向代理
就像在正向代理的部署中,不得不把用户浏览器指向正向代理一样,在反向代理的部署中,不得不把DNS纪录指向反向代理服务器。能不能不改动DNS纪录呢?如果在代理服务器后面有很多台Web服务器该怎么办呢?高速缓存必须在多台Web服务器之间分发请求,让Web服务器保持负载均衡。另外,如果做虚拟主机的公司只想给额外付费用户提供服务器加速应该怎么办呢?使用透明反向代理和一个负载均衡器可以解决上述需求。
如图7.7所示,可以在Web服务器的前端部署一个负载均衡器,为每一个站点定义一个VIP地址。如果一个主机托管的用户购买了优先服务,服务提供商就可以在这个客户的VIP地址上面配置策略,把目的端口是80的流量首先发送到高速缓存。如果高速缓存没有请求的对象,它会发送请求到负载均衡器上面的VIP地址。负载均衡器会执行标准负载均衡,把请求转发到Web服务器。这样就把负载均衡的工作交给负载均衡器处理,而不是高速缓存。如果高速缓存出现故障,负载均衡器直接把流量转发到Web服务器即可。如果一台高速缓存压力较大,可以增加更多的高速缓存,使用负载均衡器在多台高速缓存之间均衡压力。
图7.7 透明反向代理的负载均衡
7.4高速缓存负载均衡算法
高速缓存的负载均衡跟服务器的负载均衡有所不同,对服务器进行负载均衡时,负载均衡器把下一个请求转发到压力最小的服务器。对高速缓存进行负载均衡时,需要注意每个高速缓存上面可用的内容,以获取最大的命中率。例如,访问www.abc.com/home/products.gif的请求第一次被发送到高速缓存1,该缓存到原始服务器获取内容。当收到对相同对象的后续请求时,如果负载均衡器把请求转发到缓存2,那么效率就是比较低的。因为缓存2也必须到原始服务器获取内容。如果负载均衡器能够记住这个对象已经在缓存1里面,把所有对该对象的后续请求都转发给缓存1,会提高缓存的命中率,提高最终用户的响应时间。
7.4.1无状态负载均衡
就像无状态的服务器负载均衡,负载均衡器可以执行无状态高速缓存负载均衡。负载均衡器根据一些字段的集合,比如目的地址、目的端口、源地址、源端口,计算出一个哈希值,然后根据这个值决定哪一个高速缓存接收请求。用于哈希计算的字段不同,得到的结果不同。
一种算法是执行简单的哈希,把选中字段的字节累加起来的数学运算。一个字节结果在0到255之间,把这个值除以高速缓存的个数N,余数在0到N-1之间,这个数字对应的高速缓存接收下一个请求。
如果选择目的地址进行哈希运算,某种程度上,可以在缓存之间减少内容的重复。使用基于目的地址的哈希运算时,访问同一个Web服务器的所有请求都会被发送到同一个高速缓存,因为同一个目的地址得出的哈希值相同,因此被发送到同一个高速缓存。在选择字段进行哈希运算的时候还需要考虑负载分发效率的问题。例如,如果80%的流量是访问同一个目的IP地址的,并且部署了三台缓存服务器,基于目的地址的哈希运算将会导致一台缓存服务器处理80%的流量,另外两台缓存服务器处理20%的流量,这不是理想的负载均衡。如果高速缓存提供多种应用,比如:HTTP、FTP和流媒体,可以把目的端口作为哈希运算的一部分。这对负载的分发有所帮助,因为尽管目的地址相同,目的端口是不一样的。如果只处理一种应用,比如HTTP,加上目的端口一起运算也不会带来任何益处。这时可以把源地址作为哈希运算的一部分来提高负载的分发。但不同IP地址的客户端访问相同Web服务器的时候,这种实现方式会导致负载均衡器把请求发送到不同的缓存服务器,尽管这些请求的目的地址是相同的。尽管这种方法会提高负载分发的效率,但会导致缓存服务器之间内容重复,降低缓存的命中率。
当一个缓存服务器出现故障,简单哈希算法会在N-1个缓存服务器之间分发请求而不是之前的N个。在N-1个缓存服务器之间重新分发所有流量会导致缓存命中率急剧下降。
7.4.2有状态负载均衡
有状态负载均衡,跟服务器负载均衡一样,可以根据缓存服务器当前的压力分发请求,让当前状态最佳的缓存服务器处理下一个请求。有状态负载均衡跟无状态负载均衡相比,可以提供更精确、更有效的负载分发。然而,有状态负载均衡无法解决多个缓存服务器之间内容重复的问题。
7.4.3高速缓存负载均衡的优化
之前讨论的基于目的地址哈希的算法只在一定程度上解决了内容重复的问题。站点HTTP://www.foundrynet.com有10个不同的IP地址,对应10台Web服务器,提供相同的内容。每个目的IP地址都会产生一个不同的哈希值。因此,由于目的IP地址不同,负载均衡器会把访问HTTP://www.foundrynet.com/站点下相同对象的请求发送到不同的高速缓存。高速缓存的负载均衡需要一种新的最好的算法,也就是接下来讨论的算法:哈希数组和URL哈希,有状态的算法和无状态的算法各一种。
哈希数组
哈希数组算法能够帮助我们克服简单哈希算法的限制。哈希数组算法使用选定的字段计算哈希值,比如目的IP地址。计算的结果在0到H之间,H是哈希数组的大小,比如说H=255。当增加H的值时,负载分发会变得更加精确和有效。例如,H值为1024时能够比值为256提供更好的负载分发。
如图7.8所示,数组每个元素在初始化的时候都没有赋值。收到一个新建连接(TCP SYN包),负载均衡器计算其哈希值,对应到一个未赋值的元素,负载均衡器使用有状态的负载均衡算法,比如最小连接数来选择一台缓存服务器,并把该缓存服务器绑定到数组的这个元素。所有哈希值等于这个元素的后续会话和数据包都会被转发到此数组元素绑定的缓存服务器。这种实现方式要求负载均衡器能够获得缓存服务器的负载压力状况,保证合理的绑定到数组里面的元素。
图7.8 哈希数组算法
如果一台缓存服务器出现故障,只有出现故障的缓存服务器对应的元素才会被重新赋值,其他的元素完全不受影响。负载均衡器会根据每台缓存服务器的负载情况重新给这些元素分配缓存服务器。实际上,发生故障的缓存服务器上面的流量会被分发到其他缓存服务器而不影响其他的流量。
因为哈希算法只是根据IP地址或者端口号来计算,而不是URL,因此这种算法只是在一定程度上减小了内容的重复,但跟简单哈希算法相比能提供更好的负载分发。如果一台缓存出现故障,简单哈希需要在剩余的缓存服务器上面分发所有流量,完全破坏了缓存服务器之间内容的分发。哈希数组算法只是把已经出现故障的缓存的元素重新赋值,对别的元素没有影响。然而,哈希数组算法也有可能出现效率较低的情况。例如,请求有可能没有均匀分发,导致缓存服务器之间负载分发效率的低下。例如,如果所有的用户都访问HTTP://www.mars.com/,那么所有的请求都在一个缓存服务器上面终结,而其他的缓存服务器却被闲置。为了减小这些低效产生的影响,负载均衡器可以周期性的根据每个元素 的点击数在缓存服务器之间重新分发元素。在重新分发的时候,已经存在的连接会被继续分发到原有的缓存服务器,而新建连接被发送到新赋予的缓存服务器。这就要求负载均衡器能够跟踪会话,尽管哈希计算是针对每个数据包的。跟踪会话能够使负载均衡器把新建会话重定向到新赋值的数组元素,而保持已经存在的会话不动。
URL哈希
要完全消除缓存服务器之间内容的重复,必须使用URL哈希算法。这是保证对相同URL分发到同一个缓存服务器、提高命中率、使缓存服务器性能最优的唯一方法。使用URL哈希算法,负载均衡器必须做更多的工作包括延迟绑定,跟第三章服务器负载均衡中描述的延时绑定相同。
当一个客户端发出一个TCP SYN包初始化一个TCP连接时,负载均衡器并没有URL信息,也无从决定选择哪一个缓存服务器。因此负载均衡器发送一个SYN ACK包,并等待客户端的ACK包。一旦建立了连接,客户端就发送一个包含URL的HTTP GET请求。这时负载均衡器可以使用URL计算哈希值并决定将此请求转发到哪个缓存服务器。有时URL可能会很长,跨越多个数据包。如果那样的话,负载均衡器不得不缓冲数据包,等待多个数据包以得到完整的URL。所有上述工作都需要负载均衡器准确快速完成。另外,负载均衡器也许能够限制用于哈希计算的URL字节数,或者第一个数据包中任何能够使用的URL字符串。负载均衡器是否支持跨越多个数据包的URL、性能如何都随着产品的不同而不同。尽管性能取决于使用的缓存服务器和负载均衡器的产品,大多数情况下,缓存服务器会在负载均衡器变成瓶颈之前成为性能的瓶颈。
URL哈希算法可以跟哈希数组算法一起使用,提供更加有效的负载均衡。
7.4.4 基于内容的高速缓存交换
缓存服务器主要是被设计用于加速静态内容的分发。不经常改变的内容可以简单定义为静态内容。例如,Yahoo的首页,由多个对象构成。这些对象中,有些是动态生成的,其他的就是静态内容。Yahoo的Logo、背景颜色、文本的基本种类、还有页面中的链接都是静态的内容。动态内容包括当前时间和最新的头版头条。当前时间对象的属性跟头版头条的属性有所不同。每次访问的当前时间都不同,而头版头条可能30分钟更新一次。缓存服务器可以用来加速类似头版头条这种对象的分发,尽管这些对象是动态的,但它们只是偶尔发生改变。内容发布者可以指定一个标签称作TTL,代表这个对象可以在多长时间内被认为是最新的。在提供这个对象之前,缓存服务器会检查TTL,如果TTL过期,缓存服务器会发送请求到原始服务器察看内容是否发生变化,并刷新本地的副本。但是缓存服务器不能加速当前时间或者实时股票行情等对象的分发,因为这些对象每次访问内容都不一样。
在部署负载均衡器进行透明缓存服务器交换时,我们已经讨论过了把所有特定目的端口的流量重定向到缓存服务器。但是如果所请求的是不能被缓存的动态内容,为什么还要把请求转发给缓存服务器呢?如果负载均衡器能够查看请求中URL并识别出动态对象,它就可以绕过缓存服务器,直接把请求转发给原始服务器。这样可以避免缓存服务器处理动态内容,而让缓存服务器集中处理静态内容。因为负载均衡器基于被请求的内容进行交换,所以这个过程也可称作基于内容的高速缓存交换。
我们需要指定基于URL的规则,让负载均衡器能够识别动态的内容并让这些请求绕过缓存服务器。如何指定规则、规则中控制精确程度每种产品都不一样。如图7.9所示:可以指定一个规则让负载均衡器查找以“.asp”结尾的URL,或者在URL中查找包含“?”的请求。
图7.9 基于内容的cache交换
基于内容的高速缓存交换也有其他用途,例如,可以指定一个规则使负载均衡器对访问特定的主机名的请求绕过缓存服务器。这样,管理员就可以控制哪个站点需要做缓存,哪个站点不需要做缓存。我们还可以把缓存分成不同的组,给每种类型的内容或每个站点分配一组缓存。例如,ISP也许会跟站点所有者签署协议,为其站点单独使用一组高速缓存。
7.5小结
高速缓存可以改善客户端响应时间,节省网络带宽。跟原始服务器一起使用的时候,高速缓存提高了服务器的性能和可扩展性。负载均衡器让缓存服务器容易部署、管理和扩展。特殊的负载均衡算法比如哈希数组和URL哈希能够帮助提高缓存命中率。使用基于内容的高速缓存交换,负载均衡器可以有选择性的根据内容把请求导向到缓存服务器或者原始服务器,以提高高速缓存的效率。

--------------------------------------------------------------------------------------------------------------------------------------

版权所有,转载请注明出处  京ICP备2021040351号