运用OpenStack构建高速云平台

平台"/>

运用OpenStack构建高速云平台

随着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倍。

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

在我们的解决方案中，利用到的关键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管理。

图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更新等。

挑战及debug

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

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

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

通过分析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.

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

作者简介：
任敏敏，目前就职于IBM，主要负责IBM云平台产品开发和运维工作，OpenStack社区项目的开发人员，具有丰富的OpenStack开发和运维经验。