随着OpenStack行业应用的开展，大家都在尝试建设适应行业业务特点的OpenStack解决方案。IBM BlueBox团队将分享一个基于OpenStack创建的高速传输视频云的解决方案。这个方案是通过集成OpenStack，Aspera和F5，最大限度解决视频云环境中高速数据传输的需求。Aspera是IBM公司的高速文件传输软件，其专利技术FASP能够在WAN的传输环境下比传统技术提升速率10x, 100x, 1000x。F5是著名的负载均衡器，在企业中有非常广泛的应用。

我们的解决方案最初的来源于我们的客户IoT的需求，对于怎样把高速安全地将数据传输到云中，数据传输是这类用户在使用云平台中最基础的要求，有数据才有业务。这让我们意识到单纯的云平台并不足以满足所有的用户，例如我们的解决方案是在基本的云平台上加入了快速传输的特性，能够解决对大数据依赖的用户需求，例如IoT、大数据分析平台、视频云平台和媒体行业等等。例如视频行业4K视频数据量，无压缩的4K视频1分钟的数据已经达到了9GB，而4K Apple ProRes格式的1分钟数据量也达到了6GB。

方案设计与架构

首先我们对Aspera的加速能力做了实际的测试，评估是否适合加入云平台。我们在IBM softlayer共有云平台上申请了一台虚拟机，数据中心选在了加州圣荷西，用于部署aspera服务。在IBM公司内部的私有云平台上申请了一台200Mbps带宽的虚拟机作为aspera client，测试结果显示，相同1GB文件的下载，Aspera相对于FTP传输的加速达到了22.5倍。此外我们在国内公有云平台腾讯云上也申请了一台100Mbps的虚拟机，数据中心选择的是广州，加速达到了47倍。Aspera的加速能力非常好，即使是在美国和中国经过了GFW的情况，也能达到如此的效果。同样，我们也做了极端网络环境的测试，就是在使用家庭网络比如电信带宽非常有限而且共享情况下，经过VPN，加速依然达到了8倍。

图1

图2

在经过传输速度验证之后，我们做了Aspera于IBM bluebox云平台的集成，Aspera支持多种存储系统，包括对象存储Swift的支持。我们的集成解决方案如图，既是利用OpenStack的自动弹性可扩展的能力来保证Aspera传输速度的需求，从而加速数据快速的传输到云平台。整合之后的测试结果显示，从美国（vm）传输数据与原生的swift client的方式对比，也有3~4倍的加速。

图3

在我们的解决方案中，利用到的关键OpenStack组件，如图4所示：

Neutron LBaaS Service —— 提供Load Balance管理

F5 LBaaS agent —— neutron lbaas service driver

F5 BigIP ——　Load balance provider， 同时支持TCP/UDP协议的load balance

Ceilometer 和 Aodh —— 计算资源和网络资源monitor, 和autoScaling Alarm支持

Nova scheduler —— 自定义Filter保证Aspera的网络QoS

Nova —— Aspera计算资源

Neutron —— Aspera网络资源

Swift —— Aspera存储资源

Heat —— Resource group管理和Autoscaling policy定义，可定义的Aspera用户管理和License管理。

图4

图5展示的是详细的技术架构。

Aspera Fasp专利技术用于传输加速到云平台。Neutron的L3 agent的Floatingip提供唯一的服务访问入口。

F5则为Aspera service提供load balance功能， aspera instances作为neutron Lbaas pool的members， F5实现了neutron lbaas virtual ip, lbaas pool, healthmonitor。Ceilometer则负责监控和处理Aspera instances的incoming 和outgoing的流量，已经CPU内存的使用情况，提供自定义的alarm，出发AutoScaling。

Heat提供了Resource Group的编排能力，已经AutoScaling policy的定义。自定义的resource template可以实现aspera instance启动后的配置，包括aspera用户管理和aspera自定义的存储配置以及license更新等。

图5

挑战及debug

我们的解决方案在实施过程中也遇到了很多问题，以下分享给大家我们遇到主要的困难以及debug的过程。

一个是我们在使用F5作为lbaas provider的时候，遇到了healthmonitor检测member的状态为down的情况，尽管member都是正常工作的，也都是可以正常访问的。

我们在Network Controller和network namespace进行抓包分析图6，发现F5能够发送ARP request，而Instance也发送了APR reply，但是奇怪的是Reply并没有被发送到F5。

图6

通过分析neutron code和f5 agent code发现，neutron为了降低广播对L2的ARP responder做了优化，利用了linux Kernel vxlan mode的proxy ARP和FDB功能与l2population，使得ARP responder能够请求只能发送到已经创建了instance的compute节点，而不是所有的compute节点都会收到ARP responder。

但是F5 lbaas agent在port创建之后，发送的fdb entry确实广播模式的FLOODING_ENTRY = (‘00:00:00:00:00:00’, ‘0.0.0.0’)，即需要利用到网络二层的MAC学习能力。

很幸运的是，我们发现了community在Liberty版本有了新的配置，可以去选择设置arp_responder flage去决定是否开启arp responder。

另外一个就是Aspera网络服务质量的问题，对于数据传输服务来讲，稳定可靠的网络带宽是先决条件。而且需要具有nova scheduler去支持instance的调度到具备可用带宽的节点。很遗憾在我们做了调研之后，并没有如上个问题那么幸运找到可用的code patch。虽然Mitaka版本Neutron已经有了可定义的QoS，但是依然没有对应的调度测率的实现。所以我们自主实现了，instance network QoS和基于网络带宽的nova scheduler filter。我们的compute的虚拟化使用的是KVM，libvirt可以支持instance的网络带宽的定义。所以我们从这点出发，我们实现了基于flavor（图7）和host aggregate （图8）的filter，从而能够将指定的hosts作为网络带宽提供的instace的network QoS.

图7

图8

最后一个问题就是Neutron LBaaS服务对Load Balance的支持，到目前为止Neutron LBaaS是不支持UDP协议的，但是Aspera服务却需要TCP/UDP两种协议同时支持，所幸的是F5的功能是支持TCP/UDP协议的，因此我们对F5 LBaaS agent做了code patch，满足了Aspera service的特殊需求。