云计算环境下的流量控制和负载均衡策略

宋 昕，宋欢欢

（1.河南省地方税务局培训中心 学员科，河南 开封 475000；2.北京邮电大学 网络技术研究院，北京 100876）

作为分布式计算和服务计算领域的主要服务提供技术，云计算为用户提供了共享基础设施，应用开发平台以及商业应用的环境。对应于云计算提供的不同共享环境，一些著名的云计算框架被提出来，比如以IaaS（Infrastructure as a Service）形式出现的Amazon公司的EC2（弹性云计算）和以PaaS（Platform as a Service）形式出现的Google公司的GAE（谷歌应用开发引擎）[1-2]。

作为通用的要求，提供web服务的平台应该提供一系列的特性，比如资源管理，流量控制和负载控制等。在传统的提供web服务专用资源的情况下，应用开发者能够通过许多策略管理他们的资源平台并且实现负载均衡，比如基于DNS的和基于转发器的策略。然而，在云环境下，所有这些问题都必须由云平台自身解决。一方面，来自不同开发者的大量不同的应用共享后台服务器池的CPU，内存和带宽等资源；另一方面，对不同应用承诺的不同QoS必须实施保障。因此，在云环境下构建web服务最大的挑战是如何在为不同应用提供不同QoS保障的同时，实施流量控制和负载均衡控制。

在之前的工作中研究了开源的PasS形式的云环境平台：TANSO（云环境下基于组件的分布式服务平台）[3]。TANSO通过一系列的组件提供了平台用于管理大规模web应用的接口[4]。 在 TANSO的组件层，Routing TCI（TANSO component instance）负责应用请求的转发，流量控制和负载均衡。作为Routing TCI的实现，DRS被提出来。

下面将介绍关于流量控制和负载均衡的的相关工作。

1 相关工作

在web集群中的负载均衡策略已经被研究的很多[5]。通常情况下现有的负载均衡策略可以被分为两类：集中式的和分布式的策略。基于DNS的策略和集中式的基于转发器的策略是常见的集中式负载均衡策略。在文献[6]中，基于DNS的负载均衡控制策略被详细的介绍。引用文献[7]提出了一种基于位置信息的转发器负责均衡策略（LARD），通过使用一个集中式的请求分发器，LARD将应用请求转发到后台服务器时，不但考虑后台服务器的负责状况，同时考虑后台服务器的内存击中率。但是，LARD集中式的分发器承担非常大的负荷，限制了整个系统的吞吐量。考虑到集中式分发策略的单点故障和性能瓶颈，分布式的转发器策略被提出来[8]。在分布式转发器策略的设计中，许多转发器被组织成结构化的或者非结构化的形式去转发应用请求，转发器间通过广播机制进行通信协调。

但是，目前存在的负责均衡策略不能在云环境下很好的适用。在云环境中面临着成千上万不同的应用请求，不同的请求之间共享后台服务器资源。在这种情况下，基于DNS的负责均衡策略不能简单的将后台服务器的IP地址映射成逻辑的主机名或者应用标识。同时，现有的基于转发器策略的的负责均衡策略不适用于转发大量不同应用的请求，这些应用共享后台服务资源，同时具有不同的QoS优先级。更重要的是，现有的策略忽略了对不同应用的流量控制。在文献[9]中，一个分布式的流量控制策略被提出来，通过对全局请求速率和局部请求速率的统计，采用一种随机丢弃的策略对某一种特定的应用进行流量控制。DRS提供了一个分布式转发策略，它提供了一些机制用于解决在云环境下上述提到的问题，同时考虑到流量控制和负载均衡控制。

2 DRS的设计与实现

在TANSO的设计框架中，存在许多的前端转发路由节点，如图1所示，它们之间有组织的或者无组织的通过协调来实现转发应用请求，流量控制和负载均衡控制。相比传统web集群环境中的集中式转发器，实现分布式转发器需要解决以下问题。

1）需要提出一个有效的路由扩散算法用于在多个路由节点上更新应用路由信息。

2）为了实现对某种应用的流量控制，多个路由节点之间必须相互协调保证在一段时间间隔内的总流量速率。

3）相比集中式的转发器，每个路由节点对后台服务器状态都有一个视图，需要一种策略去同步不同转发器之间的后台服务器状态。

图1 TANSO平台基本框架Fig.1 The basic framework of TANSO platform

3 分布式流量控制器

在集中式的流量控制器上，通过不断统计经过该流量器的流量，判断其是否超过流量上限决定丢弃或转发。在TANSO路由子系统的设计中，每个TANSO节点上都存在一个路由TCI，它维护了一个全局的路由表，任何对云平台服务的访问都会经过路由TCI。现在需要协调在物理拓扑上处于局域网的多个流量控制节点来呈现出集中式流量控制器功能，通过使用分布式的队列机制来限制不同应用的流量控制。

在进行流量控制时，是针对每个应用进行考虑，并为每个应用维持一个队列，统计每个应用请求的速率，因此，对于出队列的每类请求，保存一个统计表，统计每种应用的本地流量。表格的形式非常简单，实现上是Java中的HashMap，哈希的键是每种应用的应用ID，哈希值是该应用在一个时间间隔内的请求数量。每个应用请求的命运（转发或丢弃）不能仅由本地的控制器决定，必须通过计算该应用流经所有流量控制器的总统计值来决定。

在实现上，使用单位时间内应用请求（HTTP请求）的个数来计算流量，每个流量控制器维护着局部流量并收集全局流量值。对于每个流量控制器，决定转发/丢弃出队的应用请求时，需要经过以下处理过程。

1）计算一定时间间隔s内这种请求的本地流量。

2）从其他流量控制器收集此种应用的流量，计算s间段内的全局流量。

3）根据收集全局流量，通过全局流量控制算法决定该请求的转发或丢弃。

所有的流量控制器被组织成分布式的架构，每个控制器独通过和其他控制器通信决定通过本地请求的命运，最简单的通信方式广播网[9]。通过广播的方式虽然速度很快，但同时也是非常消耗带宽（O（N2））。

作为替代，采用基于pub/sub的通信子系统用于节点之间的通信。在使用pub/sub通信子系统时，选取一个不参与路由的TANSO节点（比如一些资源管理节点），增加一个简单PS Master组件（PSM TCI），该插件的功能非常简单，可以作为一个独立的线程独立运行。PSM TCI的存在是为了给在基于pub/sub模型中实现“统计/反馈”需求提供辅助，上述提到的局部流量的统计和全局流量的计算可以看成一个 “统计/反馈”的过程，如图2、3和4所示的3个阶段。

图2 初始化订阅信息Fig.2 The initialization of sub

如图4所示，在每一时段的初始阶段，每一个流量控制器节点订阅全局某一应用的请求流量，PS Master则订阅所有流量控制器的局部流量。

图5是在每一时段末，所有流量控制器发布某一应用的局部请求流量，相应的PS Master将会收到所有流量控制器的流量统计值，据此计算全局流量。第一二阶段是“统计”阶段。

图3 发布局部流量信息Fig.3 Pub local traffic infomation

图4 反馈全局浏览信息Fig.4 Feedback of global information

第三阶段如图4所示，PS Master计算完全局请求流量以后，发布全局流量，根据第一阶段的订阅，所有流量控制器便会收到全局流量统计值，并以此进行流量控制算法。这个阶段是“反馈”阶段。

基于pub/sub通信子系统，采用“统计/反馈”这种形式进行局部流量信息和全局流量信息的统计，极大地减少了消息通信量，流程更加清晰。在第三阶段末，每一个流量控制器采取一定的请求转发/丢弃策略，对出队列的请求进行处理。

4 负载均衡策略

在传统的web集群应用中，web服务提供者将服务部署在自己的数据中心或者托管在别的数据中心，但是自己负责服务负载均衡实施。图5描述了一种简单的负载均衡框架。

图5 常用的负载均衡框架Fig.5 Common load equilibrium frame

用户的请求首先经过DNS进行初步路由，之后经过4层或者7层的转发器网络设备（软件模块）再次进行负载选择。在进行路由或者负载选择时，可以采用轮询或者随机的静态负载均衡算法。通常在DNS处采用简单的静态算法，在Dispatcher可以采用动态或者静态算法。

在图5的场景中，后台的服务器池是web服务提供商自己或托管的数据中心，内部部署的应用独享这些服务器。在Dispatcher使用随机的负载均衡算法时，可以根据服务器初始处理能力不同，按一定比例随机提交请求。比如服务器A和B的处理能力分别为M和W，那么可以简单的将M/（M+W）的请求量提交给服务器A，W/（M+W）的请求流量提交给B。在使用轮转策略时，可以将服务器从1～N编号，针对每一个到来的请求，按服务器编号递增模N的顺序提交给服务器。在Dispatcher处采用动态负载均衡算法时，比如采用最少链接算法，可以动态监控每个服务器链接状态，并反馈给Dispatcher模块，以选择状态最优的服务器提交请求。

考虑到集中式转发器的单点故障和性能问题，TANSO根据平台自身的特点，采用分布式的转发器实施负载均衡。一方面这是性能的需求；另一方面，TANSO平台的分布式路由子系统为构建分布式转发器实施分布式负载均衡策略提供了基础环境。在实现上，通过在路由系统中增加Dispatcher的功能，实施负载均衡策略。图6描述TANSO平台的负载均衡框架。

图6 TANSO分布式负载均衡框架Fig.6 Distributed load balance frame of TANSO

根据图6中描述的负载均衡框架，首要解决以下问题：

1）存在多个前端的Dispatcher，需要同步、协调他们对后台服务器的状态信息。如果采用传统web集群环境中的动态监听获取服务器状态，每个Dispatcher都需要周期性的监听服务器的状态，一方面造成了大量的通信量；另一方面，由于每个Dispatcher都是基于服务器状态进行选择提交请求，就有可能造成因某一个服务器状态空载高而所有的请求都被提交过去，造成“瞬间过载”的情况。

2）区别于传统集群环境的应用独享后台服务器，TANSO中的应用共享服务器资源，如何处理不同应用对服务器负载的影响是另外一个问题。

服务器状态更新和应用请求的转发是一个异步的过程，能够大大减少应用请求的响应时间。在实现上，TANSO引入了一个Monitor节点，用于获取服务器状态信息，并反馈给分布的Dispatcher。这样做将传统中的Dispatcher从既监听服务器状态又负载转发应用请求中分离出来，让Dispatcher仅仅去转发应用请求。同时，Monitor可以统一的获取服务器的状态，保证Dispatcher之间的状态同步。但是，Monitor的存在又引入了集中式单点缺陷，但不存在性能瓶颈问题。Monitor周期性的监听服务器状态，并反馈给Dispatcher，这种周期性的监听信息量相比应用请求访问量小很多数量级。要彻底解决集中节点单点故障的问题，必须考虑完全的分布式结构，比如让所有的Dispatcher组成P2P拓扑结构，但是目前还没有能力实现如此复杂的设计。相对简单的做法是对Monitor采取简单热备份，当Monitor出现故障时，切换到备用节点。引入Monitor后，TANSO的负载均衡框架如图7所示。

图7 引入Monitor的TANSO负载均衡框架Fig.7 Distributed load balance frame with monitor

引入Monitor后，TANSO负载均衡的流程如下：

1）应用请求经过Layer-4的网络转发设备（试验中的客户端代理），进行初步的负载选择。

2）Monitor周期性的监听服务器状态，并将状态统一反馈给Dispatcher。

3）Dispatcher修改涉及所有服务器的路由表项。

4）Dispatcher基于路由表中当前服务器状态选择最优服务器转发请求。

Monitor监听服务器状态仍然使用pub/sub通信系统，获取应用服务器的状态主要包括连接数，CPU和内存使用率。Monitor可以作为一个单独节TANSO点存在，主要加载AS Manager TCI，通过Socket获取服务器状态信息，同时将状态信息pub给各个订阅的Dispatcher。此外，Monitor也可以作为一个插件（AS Manager TCI）存在，插在路由节点中，pub/sub通信系统提供了两层的消息转发机制，能够满足任何一种需求。

5 结 论

本文给出了云计算环境下的服务器管理平台TANSO的简单介绍，并基于 TANSO的前端路由系统，对云计算环境中涉及到的任务调度策略做了研究，包括流量控制策略，区分服务策略及负载均衡策略。任务调度策略是web应用从传统的web集群环境迁移到云环境中必须解决的问题，本文在提出问题背景的同时，分析了解决问题存在的挑战，最后给出了解决方案。 云计算平台在业界还没有统一的定义和标准，虽然论文中的研究是基于TANSO平台的，但是研究的问题具有普遍性，文中提出的问题解决方案为也为其他平台的研究提供一定的参考意义。

[1]Google.Google App Engine[EB/OL].2004.http：//code.google.com/intl/en/appengine/

[2]Amazon.Amazon EC2 [EB/OL].2004.http：//aws.amazon.com/ec2/

[3]LI Li， TIAN Rui-xiong， YANG Bo， et al.TANSO：A componentized distributed service foundation in cloud environment[C]//2010 IEEE.Network Operations and Management Symposium （NOMS）， 2010：120-127.

[4]LILi.TANSO：A componentized distributed service foundation in cloud environment[EB/OL].http：//sourceforge.net/projects/tanso

[5]Cardellini V，Colajanni M，Yu P S.Dyamic load balancing on Web-server systems[J].IEEE.Internet Computing，1999，3（3）：28-39.

[6]Brisco T.DNS Support for Load Balancing [EB/OL].1995.http：//www.ietf.org/rfc/rfc1794.txt.

[7]Pail V S，Aront M，Bangat G，et al.Locality-aware request distribution in cluster-based Network Servers[C]//ASPLOS 98 VIII， 1998：127-139.

[8]DU Zeng-kai，JU Jiu-bin.Distributed content-aware request distribution in cluster-based Web servers[C]//IEEE.Parallel and Distributed Computing，Applications and Technologies.2003：99-103.

[9]Raghavan B，Vishwanath K，Ramabhadran S，et al.Cloud control with distributed rate limiting[C]//SIGCOMM’07，2007.