基于OpenFlow 的流媒体云服务迁移方法

战立松,奚宏生,王子磊

(中国科学技术大学自动化系网络传播系统与控制联合实验室,合肥 230027)

1 概述

近年来,随着中国互联网产业走向成熟,以及网络视频与传统电视媒体的深入合作,网络视频业务成为互联网产业中发展最快的业务之一。同时,随着移动终端的普及以及使用环境的逐步完善,中国互联网已经步入移动互联网时代。大规模并发的用户接入、多终端接入方式以及高品质的服务要求,成为流媒体服务面临的新挑战。然而,传统的基于CDN 与P2P 技术的流媒体服务难以支持服务时用户终端切换(多屏切换)、移动自动切换等需求,同时系统扩展能力有限。

云计算的兴起让人们考虑将流媒体服务向云形态转变。基于云计算的新型流媒体服务模式(流媒体云)将庞大的资源和超强的计算能力包装成一个整体并进行统一的管理,支持用户在任意位置、使用各种终端获取“不知不觉”的服务,且其规模可以动态伸缩,以满足应用和用户增长的需要,能够解决传统流媒体服务遇到的问题。因此,多种流媒体云平台和框架相继被提出,文献[1]从广播电视的角度提出了如何利用云计算技术构建了一个灵活、可靠、节能、安全的流媒体服务平台；文献[2]提供了一种支持多终端接入,有服务质量保障的云模式流媒体服务平台；文献[3]提出一种由多个媒体边缘云(子云)构成的多媒体云框架,以提供QoS 支持。除基本平台外,云形态下的流媒体服务也带来了许多挑战,如云资源的优化调度、系统的容错能力、有效负载均衡、服务终端的移动性和实时切换、服务透明性等。特别地,流媒体服务的在线迁移技术(简称流媒体迁移)是解决上述问题的关键技术之一。

针对流媒体的服务迁移技术,先前研究主要集中在应用层的服务迁移,通过在应用层加入中间件或服务代理来实现迁移,这也是当前流媒体服务系统中普遍采用的技术[4-5]。但这种方式存在以下问题：(1)只适用于局域的集群系统中,不适用于广域的流媒体云；(2)中间件或代理通常成为系统的性能瓶颈,且可靠性难以保障；(3)流媒体的交互性和长会话特性使其难以做到对用户透明。

针对上述流媒体云的服务迁移挑战,本文借助于软件定义网络中的OpenFlow[6]技术,将迁移功能从应用层业务剥离,提出一种网络层实现的流媒体服务迁移方法,以克服用户透明性、服务瓶颈等问题。另外,在提出的流媒体服务迁移框架下,通过预测用户请求分布,提出一种优化迁移数的迁移模型及其策略,从而在增强系统服务能力的同时降低迁移代价。

2 流媒体云及其存在的问题

流媒体服务具有会话时间较长、网络QoS 要求高、交互性强等特点,移动互联网对终端的多样性和移动性支持又提出了较高的要求,针对这些特点设计的流媒体云有其鲜明的特征。如图1 所示,在网络拓扑结构上,为了降低时延,将服务和处理推到处于云边缘的各子云,同时为了避免传统CDN 中存在的单点失效问题,采用分布式方式管理各子云。

图1 流媒体云的拓扑结构

子云是在地理位置上处于同一地区的服务器群,面向的是同一个地区的采用不同终端接入的用户,其内部也是按照分布式方式来管理虚拟化的服务节点。在功能和服务上,融合了超大规模分布式存储、智能并行分布式计算、动态实时分布式转码、自动适配终端类型和码流自适应调整等。这样流媒体云就能以一个云计算平台整体的形式向处于不同地理位置的多终端用户提供统一的流媒体服务。

这种云形态的流媒体服务在解决传统服务时存在以下问题：

(1) 服务可靠性问题

长期大量的服务使单个节点的失效概率剧增,节点失效使流媒体服务的可靠性得不到保障。当发现其中的某个节点失效时,需要将该节点上正在进行的服务准确迅速地迁移到其他节点上,使用户不需要重新进行请求和等待,才符合云计算对用户透明的本质。

(2) 服务移动性问题

在移动互联网时代,用户终端常常在服务时频繁移动导致地理位置不断变化,为了保证服务的持续性和服务质量,需要在不同的子云之间及时切换服务节点,这就需要进行服务迁移,同时为了使服务的变化对用户透明,服务迁移要有良好的性能。目前移动网络的迁移技术大都需要终端参与处理[7],而移动终端的处理能力有限。如果能将处理压力完全转移到服务端,可以减轻终端的压力,增强其续航能力和移动性。

(3) 负载均衡问题

在流媒体云中,各虚拟服务节点经统一的协作组成一个服务能力极强的系统,作为一个整体向用户提供统一的、透明的服务。各节点的负载分布往往不够均衡,从而导致整个系统容量下降。通过服务迁移可以调整系统的负载分布,使各节点达到一定的负载均衡,从而提高系统的服务能力[8]。

因此,服务迁移是解决这些问题的关键技术。以往的迁移技术主要集中在应用层,通过在加入中间件或服务代理来实现,但这种方式存在以下问题：(1)只适用于局域的集群系统中,不适用于广域的流媒体云；(2)中间件或代理往往成为系统的性能瓶颈,且可靠性难以保障；(3)流媒体的交互性和长会话特性使其难以做到对用户透明。软件定义网络(Software Defined Network,SDN)的出现能够解决以上问题。下文介绍如何采用SDN 中的OpenFlow技术在网络层实现服务迁移。

3 基于OpenFlow 的流媒体迁移技术

3.1 OpenFlow 架构及其关键组件介绍

OpenFlow 主要由OpenFlow 交换机和控制器两部分组成,实现了数据层和控制层的分离,其具体架构如图2 所示[9]。OpenFlow 交换机是数据层,负责根据流表转发数据包；控制器是控制平面,通过全网视图来实现对数据转发的控制。

图2 OpenFlow 架构

OpenFlow 交换机主要由流表、安全信道和OpenFlow 协议三部分组成。流表是OpenFlow 交换机进行转发策略控制的核心数据结构,每个流表由许多流表项组成,流表项代表转发规则,交换机通过查找匹配的流表项来决策对进入交换机的数据包执行的操作。流表项主要由匹配字段(Header fields)、计数器(Counters)和操作(Action)等三部分组成,如图3 所示。

图3 OpenFlow 交换机流表结构

匹配字段包含很多匹配项,涵盖了链路层、网络层和传输层大部分关键标识。计数器用来对数据流的基本数据进行统计,操作则表明了对与该流表项匹配的数据包应该执行的下一步操作。安全通道用来连接OpenFlow 交换机和控制器,可以用SSL 进行加密,控制器按照OpenFlow 协议的规定配置和管理OpenFlow 交换机。

控制器通过 OpenFlow 协议标准接口对OpenFlow 交换机中的流表进行控制,从而实现对整个网络的集中控制。控制器通过维护网络视图来获取整个网络的基本信息,如拓扑、网络单元和提供的服务[10]。运行在控制器之上的应用程序通过调用网络视图中的全局数据,进而操作OpenFlow 交换机来对整个网络进行管理和控制。

3.2 基于OpenFlow 的服务迁移实现

以仅有一个OpenFlow 交换机的网络为例,简单说明在流媒体云中如何基于OpenFlow 实现服务迁移。假设将一个正在服务的流(A 到C)从源服务节点A 迁移到目标服务节点B,迁移流程如图4 所示：

(1) 查询源节点A 得到当前播放偏移；

(2) 停止源节点A 的服务；

(3) 向OpenFlow 交换机下发流表项,将由B 发往C 的相关数据包的源地址和端口改为A 的地址和端口后,从交换机的端口3 发出；

(4) 向目标节点B 请求相应播放偏移之后的数据；

(5) 目标节点发出播放偏移之后的数据；

(6) 数据流经OpenFlow 交换机后匹配流表(Header Fields),执行一系列操作(Action)后,最终到达客户端C。

图4 基于OpenFlow 的迁移流程

在客户端“完全不知情”的情况下,为其服务的节点已经改变。由于客户端有缓存的存在,且云的超强计算能力使整个调度过程耗时极短,因此可以做到不影响客户端正常播放影片,即无缝迁移。由于OpenFlow 控制器拥有网络视图,当A,B,C 之间存在多个交换机、多条路径时,控制器会根据网络视图中的全局数据自动选择一条最短路径,向此最短路径上的每个OpenFlow 交换机下发流表,下发流程与上述流程相似,达到修改媒体流走向的目的,进而实现网络层服务迁移。

由于流媒体云对各虚拟节点采用二级分布式智能管理方式,各个节点实际上成为了云中的对等节点。虽然不同的流媒体服务有不同的特征,如协议、码率等,但是在网络层中都解析为通过OpenFlow 交换机进行统一控制的数据包。而在OpenFlow 网络中,控制器通过网络视图中的全局数据将网络中的各OpenFlow 交换机统一管理和控制,使得整个网络实际上成为一个“大”的可控网络节点。所以,可以将基于OpenFlow 的流媒体云服务迁移问题抽象成如图5 所示的模型。

图5 基于OpenFlow 的流媒体云服务迁移抽象模型

3.3 基于OpenFlow 的预测迁移策略

如本文第2 节所述,通过服务迁移可以调整系统的负载分布,使各节点达到一定的负载均衡,从而提高系统的服务能力。由于服务迁移所需的系统开销较大,而流媒体服务对网络QoS 的要求很高,如何优化迁移数,在调整负载分布的同时使得迁移的媒体流的数目最小,是迁移策略要解决的关键问题。如文献[11]中所述,用户对不同影片的请求热度不同是造成负载不够均衡的主要原因,所以本文提出通过预测用户请求分布来优化迁移数的迁移策略。

根据图5 所示的抽象模型可以将流媒体云中基于OpenFlow 的服务迁移建立数学模型来描述迁移策略。设已知流媒体云中的节点集合为N,影片集合为V,每个节点的负载能力(同时服务的媒体流的数目)为cap,用户请求到达速率服从参数为λ的泊松分布[11],用户请求影片的概率服从Zipf 分布[12]。设每隔Δt时间记录监测到的各个流的状态,据此分析得到此段时间内用户请求影片的概率分布,结合用户请求到达速率,可以预测下一个Δt时间内用户对第i个影片的请求数为Ri。设查询信息模块得到的节点j的当前负载大小为Lj,则节点j的当前空余负载为cap-Lj。设下一个Δt时间内分配给第j个节点的对第i个影片的请求数为若不等式式(1)有解,则表明根据对上一个Δt时间内用户请求特征的分析,当前服务的分布在概率上可以满足下一个Δt时间内用户的请求,即预测的结果不需要进行服务迁移。

如不等式式(1)无整数解,则表明当前的服务分布是不合理的,未来很有可能出现某些节点过载的情况,所以预测的结果是需要进行服务迁移,即要调整当前服务的分布。为使迁移的代价最小,设当前第j个节点上的第i个影片的服务数为调整服务分布后第j个节点上的第i个影片的服务数为此时抽象出的整数规划问题如下：

若此问题有解,则Z即为最少迁移次数,根据和即可得到相应的迁移步骤。

4 迁移策略评估

为评估本文提出的迁移策略,进行仿真测试。测试环境如下：整个系统共有20 个流媒体服务节点,每个节点的负载能力为100 个媒体流,每个节点上部署了110 个影片副本,整个系统共有1 500 个影片(不包括副本)；取单位时间为1 min,单位时间内整个系统接受到的用户请求数服从参数为λ的泊松分布,影片热度服从参数为0.6 的Zipf 分布,每次请求的会话时长服从参数为90 的指数分布[11],因此当λ=20(100/90≈23 时系统达到满载。本文实验以360 min 内用户请求的接受率和迁移数为性能指标,分别对以下2 种情况进行仿真：

(1) 在理想状况下,影片热度与影片副本的部署分布相吻合,即热门影片在系统中部署的副本较多,冷门影片在系统中部署的副本较少。

(2) 在实际情况下,影片热度与影片副本的分布部署不吻合,即热门影片在系统中部署的副本可能较少,冷门影片在系统中部署的副本可能较多。

2 种情况下的仿真结果分别如图6、图7 所示。

图6 理想状况下的实验结果

图7 实际状况下的实验结果

由图6 可以看出,理想情况下,由于影片副本的部署分布较合理,可以有效发挥系统的服务能力,因此在λ=23 时仍然有99% 的请求接受率。随着请求到达速率的上升,请求接受率下降明显,通过迁移策略的调度,各节点的负载得到更合理的分配,提升了系统容量,所以,系统的请求接受率有显著提升,提升的平均幅度约为2% 。

由图7 可以看出,实际情况下,由于影片副本的部署分布不是很合理,在λ=23 时请求接受率只有约96%,明显低于图6 中的情况,此时系统的服务能力显然没有达到最大发挥。通过迁移策略的调度,各节点的负载得到更合理的分配,一定程度上弥补了影片副本部署分布不合理的问题。由于影片副本部署分布的不合理,系统容量的提升空间不大,服务分布的调整次数也较少,因此图7 中接受率的提升幅度没有图6 中的大,但是仍然有平均幅度约1.5%的提升,而迁移数也相对较少。这说明实际情况下,迁移策略仍可以在一定程度上提高系统容量。

5 结束语

本文基于OpenFlow 技术,提出一种网络层的流媒体服务迁移方法,解决了服务的可靠性、用户透明性和服务瓶颈等问题。另外,基于对用户请求分布的预测,提出一种优化迁移数的迁移模型及其策略,在增强了系统接受并发请求能力的同时降低了迁移代价。实验结果验证了在2 种不同情况下,该策略均可以用较少的迁移数明显提高请求接受率。由于影片副本的部署方式对系统服务能力有着重要影响,因此下一步的工作重点是优化资源的自适应部署。

[1]杨铭民,徐元凯.基于云计算平台的网络视频技术应用研究[J].广播与电视技术,2012,(11)：30-35.

[2]北京原力创新科技有限公司.云模式流媒体服务平台：中国,200910091537.2[P].2010-01-27.

[3]Zhu Wenwu,Luo Chong,Wang Jianfeng,et al.Multimedia Cloud Computing [ J ].IEEE Signal Processing Magazine,2011,28(3)：59-69.

[4]中国科学技术大学.媒体流在线服务迁移的方法和装置：中国,200810104086.7[P].2008-08-27.

[5]周 俊,李文中,陆桑璐,等.利用网格技术实现流媒体服务迁移[J].计算机科学,2005,32(8)：109-113.

[6]左青云,陈 鸣,赵广松,等.基于OpenFlow 的SDN技术研究[J].软件学报,2013,24(5)：1078-1097.

[7]Hu Yuefei,Li Wenzhong,Lu Sanglu,et al.On Media Streaming Application Migration in Pervasive Environment[C]//Proceedings of the 1st Asia-Pacific Symposium on Internetware.New York,USA：ACM Press,2009：206-230.

[8]Zhao Yinqing,Zhi Shi,Kuo C C.Dynamic Load Balancing and Content Update for Media Storage Servers[C]//Proceedings of SPIE’02.Orlando,USA：[s.n.],2002：201-212.

[9]McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow：Enabling Innovation in Campus Networks[J].ACM SIGCOMM Computer Communication Review,2008,38(2)：69-74.

[10]Gude N,Koponen T,Pettit J,et al.Nox：Towards an Operating System for Networks[J].ACM SIGCOMM Computer Communication Review,2008,38(3)：105-110.

[11]Yu Hongliang,Zheng Dongdong.Understanding User Behavior in Large-scale Video-on-Demand Systems[C]//Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems.New York,USA：ACM Press,2006：333-344.

[12]Qiu Tongqing,Ge Zihui,Lee Seung-Joon,et al.Modeling Channel Popularity Dynamics in a Large IPTV System[J].ACM SIGMETRICS Performance Evaluation Review,2009,37(1)：275-286.