货币互换和掉期:Web透明缓存争得带宽

字体选择：【大】　【中】　【小】

最新

推荐

2010教育"云服务"暨校园优质数... 11-08　　CERNET第十七届学术年会暨会员... 10-22　　

CERNET第十七届学术年会技术报... 10-26　　CERNET第十七届学术年会暨会员... 10-29　　

　　针对当前校园网网络出口带宽紧张与信息化应用精彩纷呈以及校园网用户规模不断壮大的矛盾日益激化的问题，引入了Web缓存系统，该Web缓存系统基于Squid服务构建了由前端调度器和后端缓存池相结合的一个高可用和弹性扩展的服务架构。

校园网的带宽问题

　　随着Internet的高速发展，网络应用的不断丰富，各种网络业务不断吞噬着互联网带宽。同时，Internet 的用户也在迅速增长，导致了以下问题：一方面用户的急速增多，使服务器的负载过重，不能及时响应用户的请求；另一方面网络带宽的不足以及数据传输链路的延迟，造成了严重的网络阻塞。

　　根据网络数据传输的时间和地域相关性，一个用户在某一时刻访问某个数据后该用户及其周围的用户一段时间内很有可能再次访问这个数据。如果在相同区域内不同用户每次需要相同的数据时都要到远端服务器获取，则会造成数据的重复传输。这样不但浪费了网络带宽，使网络响应速度变慢，同时加重了服务器的负荷。 从而可以为企事业或者服务提供者节省大量的带宽建设费用，更重要的是提高了用户体验和服务质量。

Web缓存基本原理

　　Web 高速缓存服务器通常是网络中的一个专用的计算机系统，它监视Web 对象请求，获得这些对象，然后存储这些对象。其工作原理如下：

　　缓存服务器接受浏览器请求；缓存服务器从原始服务器获得缓存中的未存储或已过期的对象(Cache Miss)；缓存服务器存储获得的对象，并将其发送给客户端浏览器。

透明Web缓存的实现架构

　　应用环境

　　本应用的校园网出口环境如图1所示，通过在出口的流量控制设备AG3000E上配置策略路由，将内网所有满足策略的数据都重定向到Web缓存服务器上，再利用缓存机制，从而实现透明代理的效果。

图1 部署Web缓存服务器前的出口拓扑

 高可用弹性扩展的实现架构

　　由于校园网的最大并发为4000～5000人，网络压力相对较大，为确保Web缓存服务器的系统性能，使用一个Cache服务器显然不能满足需求，同时随着校园网用户数的不断增加、网络需求量也会随之增加，需要考虑一定的扩展性。因此，整个系统中部署了两台服务器，分别规划为Balancer层和Cache-Pools层，如图2所示，Balancer层上面运行了一个Squid实例（简称SZone），主要用于请求调度，其本身并不缓存任何对象。而Cache-Pools层则运行了4个Squid实例，分别服务在3128，3228，3328，3428四个端口，主要用于接受并处理来自Balancer层转发的请求，提供并发的缓存服务。

　　1. 前端调度器（Balancer）

　　图2中的Balancer称为前端调度器，有两种部署方式，一是串联部署，通常是处于内网数据包到达出口路由器/网关前的位置；二是旁路部署，通常是处于出口路由/网关处。部署方式虽然不同但是对应的调度方式是相同的，区别在于数据包进入Balancer层的方式不同，前者是主动流入；后者为被动流入。而且后者具有更灵活的伸缩性，但是需要在路由器/网关上配置路由转发策略，使来自内网的http请求都转向Web缓存服务器的Balancer层(可以通过WCCP协议来进行转发，Cisco公司的IOS系统已经支持该协议了)。考虑到需要根据实际负载情况随时调整经过缓存服务器的用户数，本应用是采取旁路部署的方式，以实现弹性扩展的效果。

图2 高可用弹性扩展的Web缓存服务器群架构

　　请求调度层的作用是通过截获进入本机的HTTP请求并转发到本地Squid所监听的80端口，然后由Squid程序负责解析请求。Balancer将后台Cache-Pools中所有的SZone定义为父服务器（parent），并使用CARP调度算法进行请求调度。CARP算法是一种URI策略算法，一种确定性的算法,它以每个服务器的状态作为请求分发的前提条件，然后进行均衡的请求转发，并在转发后记录本次分发策略，下次如有同样的请求时会按照这个策略直接分发，而不再进行均衡评估从而节省了分发决策时间，经过实践证明这种分发策略较为适合这个应用环境，它可以带来最大化的命中目标和最小化的目标重复。Balancer层的配置除了CARP算法和服务端口外，其他的使用Squid的通用配置即可。以下是实现CARP算法调度的配置语句：

　　cache_peer zone1 parent 3128 0 carp proxy-only no-query
　　cache_peer zone2 parent 3228 0 carp proxy-only no-query
　　cache_peer zone3 parent 3328 0 carp proxy-only no-query
　　cache_peer zone4 parent 3428 0 carp proxy-only no-query

　　Balancer会定期去检查父服务器的状态：存活或者死亡，当Balancer检测到某个父服务器为死亡状态，那么将不再向其转发请求，直到再次检测其为存活状态后才对其转发请求。这种调度策略体现了均衡性的同时，也有效地避免了单点故障，从而提高了系统的可用性。

　　2. 高可用和弹性扩展的后端缓存池（Cache-Pools）

　　图2中，Cache-Pools中配置有4个SZone，即四个Squid实例，他们分别进行请求响应、原始内容请求、内容缓存等工作。其中SZone-1，SZone-2，SZone-3，SZone-4是相互独立的，即它们分别运行于互相独立的系统用户。之所以设计成多个实例是因为：一是可以解决系统对用户和进程的资源占用限制，从而充分利用硬件资源；二是提高大并发用户情况下的并行处理能力和整体性能；三是增加可扩展性，一旦发现现有的Cache-Pools不能满足实际需求后，可以迅速的配置更多的SZone来缓解负载压力；四是提高可用性，即在某个SZone因为处理异常导致服务崩溃后，其它SZone可以不受影响继续提供服务。也就是说任何一个SZone出现故障，都不会影响其他的SZone进行缓存服务。

　　本文仅用一台服务器承担所有Cache-Pools服务，即将多个实例运行在一个物理服务器和操作系统之上。实际使用环境中，如果需要提高用户容纳量或降低用户等待响应时间，可以适当地增加Cache-Pools的数量，即增加父服务器数量（由于Balancer层资源开销不是很大，无需同比增加）。扩展时可以迁移一部分现有实例到新的物理服务器上，让每个实例拥有更大的内存来响应请求以及更大的磁盘存储空间来缓存更多的对象数据，并且拥有足够的CPU计算时间进行事务处理；假如单台服务器硬件资源充足也可以直接在新的服务器上新建更多的实例，以减轻现有实例的负载，提高服务的稳定性和响应速度。不同的网络和用户环境，SZone的调配基准会有所不同。

　　如上所述，这种以前端调度器和后端缓存池相结合的部署结构充分体现了高可用和弹性扩展的特点：前端调度器以旁路部署的方式接入，可以灵活的控制进入Web缓存服务器的用户量，体现了弹性扩展的特点；而后端缓存池，多个SZone并行且又独立地提供服务，体现了高可用的特点，不仅如此，一旦服务器本身的性能或资源出现瓶颈后，可以简单地通过拆分一部分原有的SZone到其他物理服务器上，或者直接在新的物理服务器上部署新的SZone，同样体现了弹性扩展的特点。

  服务运行监控与管理

　　服务运行过程中，对Squid进行实时监控很重要，监控结果可以让我们实时了解整个Web缓存系统的运行状况，而且对我们调整资源和配置参数具有重要的参考意义，比如是否需要进行配置优化或硬件扩容等，从而不断优化和完善透明Web缓存服务。

　　Squid的监控方法基本分为两大类，一是基于日志进行统计和分析；二是利用SNMP协议登录设备控制台进行实时监控。前者可以做到更详细一些，但是记录详细的access日志会带来一些额外的存储和CPU计算时间上的开销，对整体服务性能会造成一定的负面影响；而后者则可以节省记录日志的资源损耗，并且提供更细的统计时间轴精度。

　　因此，我们采用方式二对Balancer层和Cache-Pools层的各个Squid实例进行监控。Balancer层主要监控CARP调度表、对各SZone实例转发请求的比重及各SZone实例的工作状态。Cache-Pools层的监控主要针对总请求数、命中请求数、命中率、磁盘缓存量、内存缓存量、磁盘缓存命中率、内存缓存命中率、发送数据量、接收数据量、文件描述符使用率及CPU占用率等。

　　经过一段时间的正式运行，Cache-Pools层中的各个SZone实例的Hit率都达到50%左右，并趋于稳定。

　　同时，为了更直观地显现Web缓存的效果，通过使用Firefox结合Yslow插件在同一时间同一客户端上对同一个网站进行加载时间的对比，经过Web缓存的客户端加载时间约为：2.378 s，而不经过Web缓存的客户端加载时间约为：12.534 s，反复测试结果表明，加入Web缓存之后，可使Web的访问速度提高至少5倍，从而有效地缩短了网络延迟，大大地提升了用户体验。

（作者单位为天津科技大学信息化建设与管理办公室）