分布式应用弹性支撑机制的研究与实现

贾翔龙，吴 刚

(上海交通大学软件学院，上海 200240)

1 引言

云计算[1,2]是当前信息技术领域的热门话题之一，它将大量计算资源和存储资源连接起来，形成虚拟资源池。云平台的一个基本目标是，能够根据应用负载的波动，动态调整分配给某一应用的资源，这种按需调配和使用资源的能力称为弹性。弹性是云计算区别于网格计算等其它分布式计算的重要特征。

学术界和产业界从平台的角度出发对弹性做了大量研究。云计算的本质是分布式计算，增加分布式系统的资源有两种途径：升级(Scale Up)和扩展(Scale Out)。升级是指提升系统内节点的运算能力，扩展是指增加系统内节点的数量。本文只考虑通过扩展实现应用弹性。不同类型的云平台根据平台特点采取不同手段实现平台的弹性[3,4]。PaaS平台通过虚拟化技术对用户提供屏蔽了系统分布式拓扑结构的可升级计算节点，代表产品有GAE(Google App Engine)。IaaS平台为用户提供虚拟机实例，平台根据请求生成和回收实例，代表产品有Amazon EC2[5]。上述平台为保证通用性有一定限制，GAE不支持应用对多线程和文件系统的操作，EC2把负载均衡、内容部署等集群维护工作完全交给用户处理。

然而，从应用角度系统地研究弹性扩展的工作却很少。对于部署在云平台上的应用而言，如果自身没有支持动态扩展的机制，将无法利用平台提供的资源实现弹性。因此，本文面向应用本身的弹性需求和扩展方法展开研究，提出了基本研究方法和实现手段，并重点以Web 2.0这一类应用进行了案例分析，提出了具体的应用模式和弹性支撑平台的解决方案。

本文后续内容组织如下：第2节给出了从应用特征分析到模式设计再到弹性支撑机制设计的基本研究方法；第3节对Web 2.0应用进行案例分析，给出具体的解决方案，并通过实验验证了模式有效性；第4节总结全文。

2 基本研究方法

本文的目标是提高分布式应用自身的弹性，以适应云计算环境下随着负载量变化而动态调整资源使用量的需求。影响分布式应用弹性的因素有很多，但是从配合以虚拟机为粒度的资源扩展角度，分布式系统的架构设计起决定性作用。

不同的分布式系统其架构可能会不一样，设计者当然可以针对每一个具体的系统进行具体分析。但是，我们注意到，某一类的分布式应用常常有着类似的架构。比如，面向信息发布和共享的Web 1.0应用，通常采取Web Server+Application Server+Database 的经典三层架构；再比如以社交网络为代表的Web 2.0应用，通常在三层架构基础上增加分布式文件系统并大量使用缓存，如人人网、新浪微博等。因此，本文认为针对同一类应用提出适合弹性的应用模式(Pattern)，并据此提供相应的弹性支撑机制，对应用开发者和平台提供者是具有参考意义和借鉴价值的。

我们把工作的步骤和内容总结如下，其流程如图1所示：

(1)分析应用特征；

(2)根据特征提出适合弹性的应用模式；

(3a)设计和优化平台架构，以支撑该应用模式的实现；

(3b)为方便应用实现这种模式，平台需要提供相关的弹性支撑库，设计库函数接口；

(4)搭建平台，实现弹性支撑库；

(5)实验验证(2)～(4)工作的有效性，如需进一步提高弹性可返回(2)；

(6)平台搭建成功。

Figure 1 Process diagram of basic approach图1 基本方法的流程图

下面我们以Web 2.0这一类应用为案例，按照上述基本方法的步骤予以实践，一方面验证上述方法的有效性，另一方面也切实针对这类应用提出具体的扩展机制。

3 面向Web 2.0的应用模式与弹性支撑库设计

3.1 Web 2.0应用特征分析

维基百科对Web 2.0的定义是`“一个利用Web平台、由用户主导生成内容的互联网产品模式”。具有代表性的Web 2.0应用是社交网络服务(Service Network Service)，从技术角度看，Web 2.0应用具有负载波动性强、对部分数据的一致性要求较弱、需要支持大量音频/视频/图片等格式的文件下载等特点。

3.2 提出应用模式

根据Web 2.0应用的特点，本文总结出适合实现弹性的PSP(Processor-State-Persistent)应用模式，描述如下：

名字(Name)：Processor-State-Persistent(PSP)模式。

背景(Context)：分布式应用有多种消息交换模式(Message Exchange Pattern)，Web 2.0是基于请求-响应模式的分布式应用。在这种模式下，用户向应用发送请求(Request)，应用经过运算向用户发送响应(Response)。请求之间可能相互关联构成上下文关系，这样的一组请求形成一次会话(Session)。应用可能将处理请求得到的运算结果持久化储存，称为持久数据(Persistent Data)。运算可能依赖于过去的持久数据。

问题(Problem)：用户的请求是不可预知的，包括响应请求需要的运算量、请求之间的关联关系、单位时间内应用会收到多少请求、运算依赖于哪些持久数据等方面。待解决的问题是：应用需要具备怎样的架构，才能通过添加和移除节点的方法高效利用计算和存储资源，应对负载的波动。

因素(Forces)：添加节点后，系统的整体吞吐量应该得到提升，使请求的平均响应时间降低或持平；移除节点时，尽量不要中断未完成的会话，平均响应时间尽量持平；应用在数据一致性和整体性能之间折衷，可以牺牲部分数据的一致性提升应用整体的吞吐量。

解决方案(Solution)：PSP模式有两条原则，第一是会话数据与执行运算的节点分离，任何运算节点都可以完成指定会话的运算；第二是使用独立缓存访问持久数据，写操作直接在保存持久数据的节点上进行，读操作仅在缓存上执行，对用户保证数据的弱一致性(Weak Consistency)。 PSP模式示意图如图2所示。

Figure 2 PSP pattern图2 PSP模式

Processor：接收用户请求，按业务逻辑执行运算，返回响应。Processor本身是无状态(Stateless)的，中间运算结果由CN保存，会话数据由SDN保存，持久数据由PDN保存。

SDN(State Data Node)：保存会话数据。一次会话的所有数据保存在一个SDN上，SDN之间互相隔离，不同步任何数据。Processor和SDN没有绑定关系。

PDN(Persistent Data Node)：保存持久数据，对Processor提供保证顺序一致性的写入数据的接口，对CN提供读取数据的接口。

CN(Cache Node)：保存持久数据的缓存以及Processor的中间运算结果，原则上Processor可以访问CN保存的所有内容。

PSP模式下，应用通过调整Processor、SDN和CN的数量应对负载的波动。在负载加重的情况下，添加Processor可以在单位时间内接收更多的请求、完成复杂度更高的运算；添加SDN可以维持更多的会话；添加CN可以缓存更多的持久数据，减轻读操作对PDN的压力。在负载减轻的情况下，移除Processor会中断未完成的运算，但不会中断现有的会话；移除SDN时可以根据会话的重要程度选择中断或转移会话；移除CN会减小缓存总量，可能会使命中率暂时降低。

3.3 平台架构

前文指出，体系架构的设计对支撑弹性的应用模式实现有决定性作用，本文给出了支持PSP模式应用的平台架构，如图3所示。

Figure 3 Architecture of platform for Web 2.0 applications图3 Web 2.0平台架构

对各个组件的功能描述及其与PSP模式的映射关系如表1所示，其中还列举了后续实验中各组件的配置情况，所有虚拟服务器通过Hyper-V提供，均安装Ubuntu 12.04，内核版本为3.2。

Table 1 Configuration and functionality of platform components表1 组件配置与功能

3.4 弹性支撑库的设计

3.4.1 接口设计

如3.2节所述，符合PSP模式的Web 2.0应用在平台支持下可以实现弹性。然而，要求应用开发者学习并恰当地实践一种新模式是很困难的，本文提供一系列贴近开发者编程习惯的库函数，帮助应用实现PSP模式。对弹性支撑库的接口设计如下：

sess_open()、sess_close($sid)、sess_read($sid)、sess_write($sid,$data)：操作会话数据；

put($filename,$file)：以Key-Value形式在平台上储存一个文件；

getURL($filename)：获取用户对指定文件的访问地址；

addSvr($type)、rmSvr($name)：添加、移除指定节点。

3.4.2 关键算法改进

PSP模式实现弹性的核心在于通过添加和移除节点调整应用的性能，对应弹性支撑库的addSvr和rmSvr函数。对于SDN和CN来说，需要找到一种算法，既能有效地把数据分散到各个节点上，又能在节点变动时减小数据的迁移量。本文采用改进一致性哈希实现这一目标，下面分别介绍一致性哈希的基本原理以及本文的改进。

一致性哈希的基本原理[7]是给每个节点(Node)和待存储对象(Object)生成一个键(Key)，这些键保存在同一个环形的哈希空间里，待存储对象存放在顺时针遇见的第一个节点上。一致性哈希基本解决了节点变动带来的全局重哈希问题，但是会丢失需要重映射的存储对象。PSP模式除了缓存之外还要维护会话数据，需要减少节点变动造成的无效查询。

本文按PSP模式的需要对一致性哈希做出了改进，使移除和增加节点后的首次访问也能正确获取数据。改进的核心是访问时把节点变动的状态考虑进去，在移除或增加节点前把此节点的数据拷贝到环形空间内的下一节点上，拷贝过程中的写操作在这两个节点上同时进行，失败的读操作在下一节点上尝试一次。

实现的具体方法是设置标志位$isAdjusting和循环链表$nodeList，节点按Key从小到大的顺序存放在$nodeList中。当新增或移除某节点开始时设置$isAdjusting为TRUE，把需要重映射的Object移动到$nodeList指向的这个节点的下一节点，移动完成后把$isAdjusting设置为FALSE。算法描述如表2所示。

3.5 弹性验证

Web 2.0应用的负载较为复杂，很难给出综合指标反映应用的性能。本文分别对会话访问和文件下载这两个比较重要的方面进行弹性验证。

Table 2 Improved consistent Hashing algorithm表2 改进的一致性哈希算法

动态调整Session Server数量验证对会话访问的弹性。如图4a所示，会话总数为50K，一台Web Server持续以200并发量对会话进行随机读写(读操作和写操作概率相同)，横坐标为时间，纵坐标为平均响应时间。初始状态有一台Session Server，分别在第10、22、34、46分钟执行add、add、remove、remove操作。平均需要8分钟完成虚拟机生成和会话数据拷贝，这段时间内写操作要在两台Session Server上进行，读操作可能会计算两次存储节点，拷贝要占用大量I/O，所以性能有明显下降。拷贝完成后平均响应时间恢复正常。

动态调整File Server数量验证文件下载的弹性。如图4b所示，文件大小总和为4 GB，全部保存在File Server上，六台与Web Server配置相同的虚拟机以总并发量696持续随机下载大小为100 KB的文件，横坐标为时间，纵坐标为平均响应时间。初始状态有一台File Server，分别在第10、22、34、46分钟执行add、add、remove、remove操作。平均需要10分钟完成虚拟机的生成和文件拷贝，拷贝过程中性能下降明显，完成后平均响应时间恢复正常。

Figure 4 Validation of elasticity图4 弹性验证

4 结束语

本文面向应用本身的弹性需求和扩展方法展开研究，提出了实现弹性机制的基本研究方法：首先总结应用特征，提出适合实现弹性的应用模式，然后根据应用模式设计平台架构和相应的弹性支

撑库，最后通过实验验证模式的有效性。对Web 2.0应用采用基本方法进行案例分析，提出了PSP模式并给出了支撑平台解决方案，通过实验验证了平台的弹性，证明了PSP模式和基本方法的有效性。

[1] Patterson G,Rabkin D A,Stoica A,et al.Above the clouds:A Berkeley view of cloud computing[R]. Berkeley:Technical Report UCB/EECS.Department of Electrical Engineer and Computer Sciences, University of California, 2009.

[2] Armbrust M, Fox A, Griffith R, et al. Amazon web services. health case study[EB/OL].[2012-10-10].http://aws.amazon.com/ec2.

[3] Nurmi D,Wolski R,Grzegorczyk C,et al.Eucalyptus:A technical report on an elastic utility computing architecture linking your programs to useful systems[C]∥Proc of UCSB Computer Science Technical Conference, 2008:45-58.

[4] Zhou J T, Zheng S, Jing D Li. An approach of creative application evolution on cloud computing platform[C]∥Proc of ACM SAC’11,2011:54-58.

[5] Amazon simple storage service(Amazon S3)[EB/OL].[2012-10-10].http://docs.amazonwebservices.com/AmazonS3/2006-03-01/.

[6] Zhang Wen-song. Linux virtual server:Linux server clusters for scalable network services[C]∥Proc of World Congress Conference, 2000:1-10.

[7] Karger D, Sherman A, Berkheimer A, et al. Web caching with consistent hashing[J]. Computer Networks, 1999,31(11-16):1203-1213.