随着云计算技术的发展,云存储服务在商业应用及个人应用方面都成为普遍适用的存储解决方案,出现了Dropbox、SugarSync、Google Drive等国外云存储软件及百度云盘、360云盘等国内云存储服务。由于云存储服务具有共享和协作的特性,故云存储服务用户进行文件共享的应用场景非常普遍。例如,教师在课堂上通过校园云存储平台向学生共享实验数据集文件,学生通过该平台提供的链接进行下载。这时,学生作为客户端会向云存储服务器发出下载同一文件的请求,服务端收到请求后开始提供下载服务,这种数据内容分发过程中的数据传输协议一般采用超文本传输协议(HyperText Transfer Protocol,HTTP)。同时,数据分发过程中可能会出现如下问题:大量客户端短时间内向云存储服务器发出下载同一文件的请求,造成云服务端带宽压力过大,及客户端下载过慢。为了有效解决这一问题,在云平台内容分发过程中融合Peer-to-Peer (P2P)传输技术,利用P2P分发系统中节点之间能够分享数据的特性,来降低服务端带宽消耗,减少用户的数据文件下载时间[1-4]。
在融合P2P技术到云平台数据分发过程的相关研究中,文献[5-7]分别阐述了BitTorrent(BT)协议等P2P类传输协议不仅对于普通文件同步和分发是非常有效的,而且对于云环境的内部虚拟机的镜像传输也能降低其传输时间。例如文献[6]中,作者论证了使用他们的BT协议解决方案后,虚拟机镜像的传输相对于传统的远程文件传输速度提高了超过30倍。文献[8]中作者提出了利用时间收益比较来确定选用哪种分发协议,并讨论了小文件对P2P协议分发的影响。上述相关研究工作,一方面讨论使用BT等协议对云平台内容大文件分发的好处,另一方面利用分发时间等指标简单地比较了两种协议的效率。但事实上,具体讨论如何在云平台(尤其是在普遍采用的OpenStack云平台)中同时融合HTTP和BT两种协议,并进行动态协议转换来提高数据分发效率的研究非常少。
本文为了有效解决大量云服务客户端在短时间内向云存储服务器发出并发文件数据传输的请求,造成云服务端带宽压力过大、客户端下载过慢的问题,提出了一种融合BT协议与传统HTTP传输技术的云平台快速内容分发方法,主要内容包括:综合选取多种协议转换度量指标并给出其具体计算方法,在此基础上,给出云平台中数据内容分发时HTTP和BitTorrent协议之间的协议动态转换方法,用来实现高效的内容下载分发过程,并基于OpenStack云平台实现了上述动态协议转换方法。通过实验将本文所提方法与纯使用HTTP或BT协议下载方式对比,论证本文所提方法能够保证客户端用户获得较短的文件下载时间,同时有效降低了云服务商带宽消耗。
1 快速内容分发参考度量指标选取及定义融合BT协议实现云平台快速内容分发的主要思想是,当服务端发现客户端文件请求量大量增长时,其所使用的文件分发协议会从原有的HTTP转换为BT协议,并随情况进行动态调整。基于BT协议的分发过程对于大文件数据传输是非常有效的,但是对于小文件数据传输,使用BT协议效果则不佳,可能造成用户下载时间的增加。因此,动态协议转换机制的设计难点包括以下两个方面:一方面是确定协议转换的时间点,即达到什么样的条件进行协议转换;另一方面是转换后的效果如何衡量,即衡量服务提供商的带宽节约量和用户的下载时间的减少或提高程度。为此,本文要选取合适的参考度量指标,并进行一定的建模和计算来确定协议的转换时间点及衡量协议转换后的效果,然后,根据转换效果来确定后续操作。
鉴于云快速内容分发机制涉及到两个利益主体,分别为云存储服务提供商(即服务端)和云存储访问用户(及客户端),基于这两个利益主体的利益考虑,本文选取了时间收益、宽带收益、服务质量、用户类型等四个度量指标,作为动态协议转换方法中的核心考量指标。其中,时间收益(即客户端用户下载时间收益)和服务质量(即客户端用户获得的服务水平)度量指标侧重于对用户利益的综合考虑,而宽带收益(即服务端可节约的带宽资源量)与用户类型(及区分付费和免费用户)度量指标侧重于对云服务提供商利益的综合考虑。为了方便下文描述协议转换指标的具体含义,表 1定义了用到的系统参数符号。
为确定协议转换后使用BT协议与HTTP的收益情况,需要对两种下载协议下文件分发时间进行估算。
文献[9]提出一种BT时间估算方法,如式(1) :
${{T}_{BT}}=F/\min \{{{d}_{\min }},u(I)/L,u(S)\}$ | (1) |
其中:TBT表示大小为F的文件分发到L个下载节点所需要的最小时间,最小下载时间依赖于最慢节点的下载速度dmin、平分到L个下载节点的混合上传带宽的平均值以及云平台中种子节点的上传带宽。
1.1.1 BT协议下小文件分发时间的估算式(1) 中没有考虑到BT协议下载的额外时间开销,对于小文件,该时间会对文件下载时间有较大影响。文献[8]对小文件的额外开销进行了实验证明和讨论。实验证明,BT协议分时,下载小文件的额外开销时间对其总分发时间影响较大,该文作者分析额外开销的原因有以下两个方面:
启动阶段 下载节点对种子文件的预处理及分块时间(大约是分发时间的0.1%),之后定位和联系同伴节点开始传输数据。此项开销根据系统负载一般可以被检测并量化,且变化不大,可简单地把这种额外开销设定为一个常量αBT。
下载阶段 下载节点会向其他节点上传数据,即下载者只拥有部分数据。一旦上传者没有新的数据片提供给其他节点,就会导致上传中断,其他节点会再次请求另外拥有此数据块的节点,从而导致的额外开销。
对于下载阶段的额外开销,文献[8]中提出了一种解决方案,讨论了BT协议下文件共享的有效性问题,引入了一个参数η,按比例缩小下载节点的上传速度,参数η衡量文件分享的效果,表达式如式(2) 所示:
$\eta =1-{{\sum\limits_{{{n}_{i}}}^{N-1}{\frac{1}{N}(\frac{N-{{n}_{i}}}{N({{n}_{i}}+1)})}}^{k}}$ | (2) |
其中:参数N是请求文件被分割的片数,参数k表示下载节点拥有的连接数,该文指出对于大文件,η接近于1,但对于如1 MB的小文件(被分割4块且每块等于256 KB),当连接数等于2时,由公式得出η等于0.706 9,说明一个节点从那些对其非阻塞的节点中没有想下载的数据片的概率大约为30%,这就造成了节点下载时间的提高。
根据上述讨论,考虑既适用于小文件又适用于大文件的BT协议分发时间估算方程如式(3) 所示:
${{T}_{BT}}=F/\min \{{{d}_{\min }},u\left( I \right)'/L,u(S)\}+{{\alpha }_{BT}}$ | (3) |
其中u′(I)=u(S)+ηu(L)表示所有节点混合上传带宽。
1.1.2 时间收益时间收益用来比较BT协议和HTTP的下载效果,根据文献[6],定义时间收益Gain(T)如式(4) 所示:
$Gain(T)=\left( {{T}_{CS}}-{{T}_{BT}} \right)/{{T}_{CS}}$ | (4) |
其中:TCS表示使用HTTP的文件分发的最小时间,TBT表示BT协议下文件的最下分发时间。考虑到客户端下载节点不同,TCS主要受限于下载节点中速度最慢的一个,或者受限于种子节点平分到L个客户端的上传带宽,所以TCS可用式(5) 表示:
${{T}_{CS}}=F/\min \{{{d}_{\min }},u(S)/L\}$ | (5) |
为了推导出收益的表达式,结合式(1) 依据min{u(I)′/L,u(S),dmin}和min{u(S)/L,dmin}来区分几种情况分别得到HTTP和BT协议的最小分发时间,经过推导或实际分发情形只有以下4种情况合理,其他情况不存在。
情况1 dmin≤u(S)/L且dmin≤min{u(I)′/L,u(S)}。
不论使用HTTP下载协议还是BT协议其最小分发时间都取决于速度最慢的节点。此时两种分发协议对应的下载时间为:
$\left\{ \begin{align} & {{T}_{CS}}=F/{{d}_{\min }} \\ & {{T}_{BT}}=F/{{d}_{\min }}+{{\alpha }_{BT}} \\ \end{align} \right.$ |
情况2 u(S)/L≤dmin且dmin≤min{u(I)′/L,u(S)}。
使用HTTP的传输瓶颈是服务端为文件分配的带宽和下载用户数,而使用BT下载协议其传输瓶颈取决于下载节点最慢的节点,此时两种分发协议对应的下载时间为:
$\left\{ \begin{align} & {{T}_{CS}}=F\times L/u\left( S \right) \\ & {{T}_{BT}}=F/{{d}_{\min }}+{{\alpha }_{BT}} \\ \end{align} \right.$ |
情况3 u(I)′/L≤min{dmin,u(S)}。
使用BT下载协议的传输瓶颈受限于所有节点的混合上传带宽分配到L个下载节点的平均值,由于种子节点的混合上传带宽小于所有节点的混合带宽且u(I)′/L≤dmin,所以总有u(S)/L≤dmin。此时,对于使用HTTP下载协议来讲,其传输瓶颈受限于云服务端分配到所有节点的带宽的平均值,此时两种分发协议对应的下载时间为:
$\left\{ \begin{align} & {{T}_{CS}}=F\times L/u\left( S \right) \\ & {{T}_{BT}}=F\times L/u\left( I \right)'+{{\alpha }_{BT}} \\ \end{align} \right.$ |
情况4 u(S)≤min{dmin,u(I)′/L}。
由于种子节点混合上传带宽小于最慢下载节点的下载速度,且总有种子节点混合带宽分配到下载节点的平均值小于种子的节点混合带宽,即u(S)/L≤u(S)且u(S)≤dmin,所以,对于使用HTTP下载协议,云服务端文件的带宽分配到所有下载节点的平均值总是小于最慢节点的下载速度,此时两种分发协议对应的下载时间为:
$\left\{ \begin{align} & {{T}_{CS}}=F\times L/u\left( S \right) \\ & {{T}_{BT}}=F/u\left( S \right)+{{\alpha }_{BT}} \\ \end{align} \right.$ |
对于上述每种情况,把得出的时间TCS和TBT代入时间收益的计算式(4) 得出:
$Gai{{n}_{BT}}(T)=\left\{ \begin{matrix} \frac{-{{\alpha }_{BT}}\times d\min }{F}, & 情况1 \\ 1-\frac{u(S)}{\left| L \right|\times {{d}_{\min }}}-\frac{{{\alpha }_{BT}}\times u(S)}{F\times \left| L \right|}, & 情况2 \\ 1-\frac{u(S)}{u(I)'}-\frac{{{\alpha }_{BT}}\times u(S)}{F\times \left| L \right|}, & 情况3 \\ 1-\frac{1}{\left| L \right|}-\frac{{{\alpha }_{BT}}\times u(S)}{F\times \left| L \right|}, & 情况4 \\ \end{matrix} \right.$ | (6) |
带宽收益代表服务提供商的利益,表示使用BT协议进行文件分发时,下载节点从其他下载节点获得的下载数据量。带宽收益的数量对于服务提供商来说就是其带宽的节约量,由其他下载节点数据交换量决定。为了估算带宽收益,定义式(7) 来计算:
$\begin{align} & Gain(BW)=\frac{从节点获得数据量}{分发的总数据量} \\ & \text{=}1-\frac{云种子节点获得数据量}{分发的总数据量} \\ & \text{=1-}\frac{\sum\limits_{\text{i}\in L}{\int_{0}^{{T}_{{Bt}}}{{{S}_{i}}(t)dt}}}{F\times L} \\ \end{align}$ | (7) |
其中Si(t)为云种子节点的播种速率,表示在时间t内云种子节点向下载节点传送的比特率。文献[9]构造了播种速率Si(t),并给出了每种情况的表达式。播种速率依赖时间t、文件大小F、种子节点的上传速度u(S)和所有下载节点上传速度和下载速度的集合Cf。对于上述每种情况,式(8) 给出了播种速率的表达式如下:
${{S}_{i}}(t)=\left\{ \begin{matrix} \frac{{{u}_{i}}\times {{d}_{\min }}}{u(L)}, & 情况1 \\ \frac{{{u}_{i}}-u(L)}{\left| L \right|-1}+{{d}_{\min }}, & 情况2 \\ \frac{{{u}_{i}}-u(L)}{\left| L \right|-1}+\frac{u(I)'}{\left| L \right|}, & 情况3 \\ \frac{{{u}_{i}}\times u(S)}{u(L)}, & 情况4 \\ \end{matrix} \right.$ | (8) |
把求出的播种速率的表达式(8) 代入带宽收益公式(7) 中,得到如下带宽收益的具体估算公式(9) :
$Gain(BW)=\left\{ \begin{matrix} 1-1/\left| L \right|, & 情况1和情况4 \\ \frac{\eta \times u(L)}{\left| L \right|\times {{d}_{\min }}}, & 情况2 \\ 1-\frac{u(S)}{u\left( I \right)'}, & 情况3 \\ \end{matrix} \right.$ | (9) |
本文服务质量(Quality of Service,QoS)主要是指云服务提供商提供的云平台文件分发服务的质量,而云服务商提供服务能力主要是根据用户类型来提供的,故本文首先从服务商的视角对用户进行类型划分。考虑到现实中服务商提供的产品类型以及内容分发机制中的参考指标,本文根据用户对服务的付费情况把用户划分成付费用户(Pay_user)和免费用户(Free_user)两类。对于付费用户,云服务商提供的服务能力质量较高,而对于免费用户提供的服务能力质量不如付费用户。在实际云平台内容分发中,用户对服务质量的最明显感知是数据文件的下载时间,下载时间越低用户对服务商提供的能力满意度越高,反之用户对其提供的服务容忍度越低。本文对用户服务质量参数值的具体定义为:服务质量与服务商分配给文件的带宽和请求下载文件的用户数相关,服务质量的参数值等于文件分配带宽除以用户数,即QoSmin=U/L。
在本文所提的云平台快速内容分发机制中,用户的协议转换条件与用户的最低服务质量相关,而对于不同类型的用户,其最低服务质量参数值也不一样。例如,云服务提供商定义云平台中的免费用户的最低服务质量参数值为1 Mb/s,付费用户的最低服务质量参数值为2 Mb/s,免费用户的最低服务质量数值总是低于付费用户的最低服务质量的数值。而协议转换时,如果请求用户只有免费用户,达到或低于免费用户的最低服务质量则开始进行协议转换,例如:当前服务商分配的文件带宽为10 Mb/s,用户请求数为5,达到免费用户的最低服务质量限制,协议进行转换。如果请求用户中既包括免费用户又包括付费用户或者都是付费用户,则协议转换的条件是达到或低于付费用户的最低服务质量,例如:服务商分配给文件的带宽为10 Mb/s,当前文件的用户请求数为8,此时服务质量低于付费用户的最低服务质量,下载协议开始进行转换。
2 动态协议转换方法的设计第1章分别从云服务的两个利益主体的角度描述了四种参考指标来衡量HTTP和BT协议的转换条件及效果,其中用户类型和最低服务质量用来衡量HTTP和BT下载协议转换的条件和时间点;时间收益用来衡量文件分发时,下载协议从HTTP转换后BT时间的损益情况;带宽收益用来衡量使用BT协议时,下载节点从其他下载节点数据量交换情况,也是衡量服务提供商的带宽节约情况。
本章给出基于上述参考指标计算值的动态协议转换算法,且基本思想可概述为:同时对评价指标中的用户类型、服务质量和时间收益三种指标作出条件约束。首先考虑用户类型和服务质量,大量用户发送下载统一文件请求时,系统根据用户类型、用户数及文件分配带宽等条件,计算此时用户服务质量的参数值,并与服务商根据用户类型设定的最低服务质量进行比较,若小于预设的最低服务质量参数值,文件分发从初始默认的HTTP转化为使用BT协议。协议转换后,算法将分别预估后续使用HTTP和BT协议时,用户的下载时间并计算时间收益,当时间收益低于服务商设定的时间收益值时,下载协议进行逆转换,即再次转换为使用HTTP进行数据传输。其中,边界条件即时间收益阈值作为第二次协议转换判定条件,其参数值由服务提供商根据用户类型进行预设定。
动态协议转换算法具体实现步骤如下。
输入:系统参数集{文件大小F、节点上传速度u及下载速度d、文件请求用户的数量L、文件分配带宽U、用户类型user_type、最低服务服务质量QoSmin、云种子节点上传速度u(S)、时间收益阈值CP}。
输出:集群用户的时间收益。
步骤1 算法开始,实时收集文件分配带宽、用户类型及请求用户数、文件大小等系统参数。
步骤2 判断当前用户是否包括付费用户,并根据服务质量定义计算当前的用户平均服务质量。
步骤3 如果当前用户包括付费用户,判断其当前服务质量是否低于付费用户的最低服务质量,如果小于预设的约束条件,执行步骤4→步骤5,否则执行步骤6→步骤7;如果没有付费用户,计算平均服务质量是否低于免费用户最低服务质量,如果达到约束条件,执行步骤4→步骤5,否则执行步骤6→步骤7。
步骤4 云服务器生成种子文件并传输种子文件。
步骤5 用户接收种子文件,解析种子文件后启动BT服务下载开始进行BT传输。利用式(6) 计算用户下载时间收益Gain(T),如果用户时间收益大于给定值T则执行步骤7,否则执行步骤6→步骤7。
步骤6 继续以HTTP进行文件传输。
步骤7 所有用户完成下载文件,传输结束。
协议转化算法中关键步骤的伪代码描述如下:
if (user_type=Pay_user) //判断用户类型
{
//判断是否低于付费用户最低服务质量
if (QoS<=QoSmin(Pay_user))
produce a “.torrent” file //生成种子文件
launch a BT seed in the cloud //启动云种子节点
for all users requesting do
leechers get the .torrent file from the cloud
start BT transferring //启动BT传输
if (Gain(T)>CP(Pay))
continuing BT transferring
else download file via HTTP
else download file via HTTP
} else {
//判断是否低于免费用户最低服务质量
if (QoS<=QoSmin(Pay_free))
produce a “.torrent” file //生成种子文件
launch a BT seed in the cloud //启动云种子节点
for all users requesting do
leechers get the .torrent file from the cloud
start BT transferring// 启动BT传输
if (Gain(T)>CP(Free))
continuing BT transferring
else download file via HTTP
else download file via HTTP
}
上述动态协议转换方法中的时间收益阈值参数CP的取值依赖于用户类型的设定。对于付费用户,服务商要严格保证的用户的下载时间,收益阈值设置始终大于等于0(总是选择时间花费最少的协议作为分发协议);而对于免费用户,时间收益阈值可设置小于0(优先使用BT协议进行分发,节约服务提供商带宽)。
3 动态协议转换方法的实现及对比实验 3.1 实现环境配置本文使用OpenStack云平台的Swif组件来提供存储分发服务。参数收集工具使用高级消息队列组件Rabbitmq,由于OpenStack及Swift都是使用Python语言进行开发的[11],且Python语言具有易读、易维护和丰富强大的类库,故本文在实现动态协议转换方法时,采用脚本语言Python。实现相关的软硬件环境具体如下。
1) 基础硬件配置。CPU为Intel Core i3- 2120 3.30 GHz;内存为8 GB,1 TB存储,操作系统为CentOS 6.5 64位。
2) 基础软件配置。数据库为MySQL 5.1,消息队列组件为RabbitMQ,种子服务器为BitTorrent软件,客户端软件为utorrent、myBT,应用服务器为Tomcat6.0客户端软件使用,其他软件为hfs服务器,vmware workstation12.2。
实验环境首先部署Swift组件,Swift的部署上本文按照OpenStack官网上Swift开发版本的部署方式“Swift All In One”进行部署,即在单台服务器上安装运行所有Swift服务,并模拟运行4个节点的集群,首先安装依赖包,主要包括url、gcc、git-core、memcached、python-coverage、python-dev、python-nose、python-setuptool等类库,安装之后依次对Swfit各个服务进行配置,如为设置副本管理工具,创建配置文件/etc/rsyncd.conf,所有服务配置完毕后,启动服务[12]。
Swift服务集群搭建完成之后,下一步配置开发工具。本文使用Ecliplise开发环境,并下载Python开发插件PyDev集成到Ecliplise中。开发工具配置之后,在Ecliplise中添加Swift和Python-swiftclient的源代码,其中Swift的源代码存放在~/swift/swift_1.7.6 目录下,Swift客户端的源代码存放在~/swift/python-swiftclient_1.2.0目录下。
至此所有的环境和开发部署工具已经准备好,将实验代码编写到Ecliplise中进行调试,便可对动态协议转换算法进行实现和分析。
3.2 实现关键技术融合P2P协议的云平台分发机制实现关键技术主要有三点:1) 系统各参数的收集及传递;2) Swift组件代理节点Proxy请求转发的改变;3) 云平台中BT传输的实现。下文分别对这3点关键技术进行阐述。
1) 系统各参数的收集及传递。本文收集的参数为动态协议转换算法中的输入参数集合。其中,动态协议转换算法主要在代理组件swift-proxy中实现,所以代理组件需要收集的参数包括用户类型、文件分配带宽、副本数即云种子节点数、用户请求数、及所有下载节点和种子节点的带宽信息。对于种子服务器,为了创建被请求文件的种子,需要收集的参数包括所有文件的存储位置及数量。参数的收集及传递主要是利用消息队列组件RabbitMQ进行实现,其收集器的toCollection方法负责收集系统实时参数,而其中的消息传递机制“生产者消费者模型”负责系统各参数的传递。
2) Swift组件代理节点Proxy请求转发的改变。在Swift中所有的请求都要经过swift-proxy组件,作为请求的入口和处理点,其中主方法handle_request作为swift-proxy代理服务的入口点,负责对用户的请求进行处理和执行,故本文在handle_request中作了以下改变:handle_request方法获取用户请求后首先执行self.get_controller(req.path) 进行预处理,得到控制器的请求路径,预处理过程由协议转换算法进行实现,如果达到转换条件则获取种子服务器Tracker的控制路径,如果未达到则获取对象服务器Object的路径。接下来获取控制器类的实例化对像controller(self,**path_parts),并在环境变量req.environ[‘swift.trans_id’]中设置对象实例id。最后执行控制类方法getattr(controller,req.method),其中req.method标识具体操作,如Upload、Get等操作。
3) 云平台中基于BT协议的传输。为了在Swfit云平台进行BT数据传输,一方面需要在云平台中部署Tracker服务器,另一方面要对被请求文件进行做种处理。 本文对文件进行做种时,首先安装libtorrent库,且在编译时需要增加./configure-enable-python-binding,然后进入binding目录,make install运行,接着编写代码利用Rabbitmq获取文件路径path,然后调用方法lt.create_torrent(path)进行做种,并利用方法t.add_tracker把种子相关信息上传到Tracker 服务器中进行发布即可。BT客户端之间一般要通过Tracker服务器来进行信息交换才能知道彼此的存在,本文选用xbt Tracker。
3.3 对比实验结果与分析本文针对小文件分发的特殊性,对BT协议传输产生的额外开销进行了分析,并结合额外开销对文件分发时间进行了适应性的改变,所以本节通过实验首先计算额外开销和文件分发时间,然后对协议动态转换机制的效果进行分析和评价。
1) 首先对BT协议下的额外开销时间数值和BT文件分发时间的准确性进行验证。
本文实验选取的文件大小为1 MB,分配给该文件的上传带宽为2 Mb/s,客户端数量集合{2,3,4,5,6}且每个客户端的上传带宽为512 Kb/s,下载带宽为1 Mb/s。本文重复5次实验并测量客户端的平均下载时间和额外开销αBT。
额外开销时间的实验结果如图 1所示。分析可知,BT协议下,每个集群所产生的额外开销都围绕2.5 s进行散布,所以计算BT协议下文件的分发时间时,可以把额外开销时间设置成固定值2.5 s。
实验中,观察到每个集群的文件分发时间,并利用式(3) 能够计算出预估文件分发时间,故图 2给出预估文件分发时间和实际分发时间对比曲线。分析可知,利用式(3) 预估的文件分发时间与实际的BT文件分发时间比较近似错误率在10%之内,而利用式(1) 由于没有考虑文件的额外开销,文件分发时间与实际分发时间错误率在30%左右。所以在计算小文件的最少分发时间时一定考虑分发过程中的额外开销。
2) 动态协议转换方法有效性的验证。
为了验证动态协议转换算法的对云平台文件分发的有效性,本文设置了两组实验:大文件分发实验和小文件分发实验。为了使分发效果对比明显,本文使用大小为1 GB的大文件和大小为1 MB的小文件作为典型被请求文件。两组实验中集群客户端数量为{2,3,4,5,6},免费用户最低服务质量设置为512 Kb/s,付费用户的最低服务质量为1 Mb/s,时间收益阈值参数设置为0,文件分配带宽设置为2 Mb/s。客户端的上传带宽是512 Kb/s,下载带宽是1 Mb/s,BT的额外开销设置成固定值2.5 s。为防止协议转换时做种时间消耗的干扰,本文在实验前提前制作好种子文件。可通过修改客户端配置文件来模拟纯HTTP、纯BT协议的下载场景,并与本文提出的动态协议转换方法进行对比实验。
针对大文件的对比实验结果如表 2所示。
分析表 2数据可知,当集群客户端数量为2时,最低服务质量还未达到动态协议转换的条件,所以纯HTTP下载时间与动态协议转换方法下载时间近似相同。而使用纯BT进行下载,节点互相可以分享数据,故下载时间低于两者,此时使用动态协议转换方法带宽收益为0。随着集群客户端数量的增加,HTTP下载时间逐渐增加,并且服务端带宽被完全占用,而纯BT下载与动态协议转换方法的下载时间随着下载节点的增多而逐渐降低,并且开始产生带宽收益,降低了服务提供商的带宽开销。
针对小文件的对比实验结果如表 3所示。
分析表 3数据可知,进行小文件分发时,当集群客户端数量较少时未达到其最低服务质量,此时HTTP分发时间与动态协议分发时间近似,而BT分发时间由于额外开销导致花费时间较长。随着客户端数量增加,三者文件分发时间都逐渐增加,由于此时动态协议转换的时间收益小于0,所以动态协议使用的还是HTTP时间,故近似等于HTTP时间。当客户端数量进一步增加时,用户时间收益开始减小,文件分发协议继续使用BT协议,此时动态协议转换时间近似于BT协议的分发时间,并且产生一定的带宽收益。
综上,无论分发大文件还是小文件,本文提出动态协议转换方法总是选择最优的数据传输协议进行分发,能够有效降低用户的下载时间,并且获得很好的带宽收益。
4 结语本文提出了一种融合BitTorrent协议技术的云平台内容快速分发方法,主要贡献为选取并计算了用户类型、服务质量、时间收益、带宽收益等四种度量指标,在此基础上提出了一种在HTTP和BitTorrent协议之间的动态协议转换算法,用来实现高效的内容下载分发过程。此外,本文基于OpenStack云平台实现了上述动态协议转换方法。在该实际内容分发平台上,将本文所提方法与纯使用HTTP或BT协议下载方式对比,分析实验结果可知,基于协议动态转换方法的云平台内容分发过程无论在分发大文件还是小文件时,都能够保证客户端用户获得较短的文件下载时间,同时,服务商的带宽资源得到了进一步节省,提供商的带宽收益较好。后续工作将重点解决本文所提方法存在的一些局限性问题,如用户量数量较少时,其分发效率不如使用纯BT协议的效率;以及由于对已分配的下载带宽作动态改变,可能导致服务商存在一定的带宽浪费等问题。
[1] | LEON X, CHAABOUNI R, SANCHEZ-ARTIGAS M, et al. Smart cloud seeding for BitTorrent in datacenters[J]. IEEE Internet Computing, 2014, 18 (4) : 47-54. doi: 10.1109/MIC.2014.43 |
[2] | CHEN G, HU T, JIANG D, et al. BestPeer++:a peer-to-peer base large-scale data processing platform[J]. IEEE Transactions on Knowledge and Data Engineering, 2014, 26 (6) : 1316-1331. doi: 10.1109/TKDE.2012.236 |
[3] | PETERSON R S, SIRER E G. Antfarm:efficient content distribution with managed swarms[C]//NSDI 2009:Proceedings of the 6th USENIX Symposium on Networked Systems Design and Implementation. Piscataway, NJ:IEEE, 2009:107-122. |
[4] | SHARMA A, VENKATARAMANI A, ROCHA A A. Pros & Cons of model-based bandwidth control for client-assisted content delivery[C]//COMSNETS 2014:Proceedings of the 2014 Sixth International Conference on Communication Systems and Networks. Piscataway, NJ:IEEE, 2014:1-8. |
[5] | PRIYANKA S, KALPANA R, HEMALATHA M. Reducing upload and download time on cloud using content distribution algorithm[J]. International Journal on Recent and Innovation Trends in Computing and Communication, 2013, 1 (3) : 101-105. |
[6] | WARTEL R, CASS T, MOREIRA B, et al. Image distribution mechanisms in large scale cloud providers[C]//CloudCom 2010:Proceedings of the IEEE 5th International Conference on Cloud Computing Technology and Science. Piscataway, NJ:IEEE, 2010:112-117. |
[7] | CARBUNARU C, TEO Y M, LEONG B. A performance study of peer-assisted file distribution with heterogeneous swarms[C]//LCN 2011:Proceedings of the 38th Annual IEEE Conference on Local Computer Networks. Piscataway, NJ:IEEE, 2011:341-349. |
[8] | CHAABOUNI R, SANCHEZ-ARTIGAS M, GARCIA-LOPEZ P. Reducing costs in the personal cloud is BitTorrent a better bet?[C]//P2P 2014:Proceedings of the 14th IEEE International Conference on Peer-to-Peer Computing. Piscataway, NJ:IEEE, 2014:1-10. |
[9] | LIU S, HUANG X, FU H. Understanding data characteristics and access patterns in a cloud storage system[C]//CCGrid 2013:Proceedings of the 13th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing. Piscataway, NJ:IEEE, 2013:15-19. |
[10] | SCHMIDT M, FALLENBECK N, SMITH M. Efficient distribution of virtual machines for cloud computing[C]//PDP 2010:Proceedings of the 18th Euromicro International Conference on Parallel, Distributed and Network-Based Processing. Washington, DC:IEEE Computer Society, 2010:567-574. |
[11] | OPENSTACK PROJECT. OpenStack API guide[EB/OL].[2016-04-15] . http://developer.openstack.org/api-guide/quick-start/. |
[12] | OPENSTACK PROJECT. Object Storage service[EB/OL].[2016-03-30] . http://docs.openstack.org/mitaka/config-reference/object-storage.html. |