返回 登录
0

运用OpenStack构建高速云平台

阅读4210

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

表1

type Speed in bps Speed in Bps 1 minute size
Uncompressed raw 1.2Gbps 153.6MBps 9GB
4K Apple ProRes 0.88Gbps 110MBps 6.44GB

方案设计与架构

首先我们对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的特殊需求。

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

评论