BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

打造基于开源系统的公有云——文思海辉的OpenStack实践

| 作者 杨赛 关注 3 他的粉丝 发布于 2013年11月23日. 估计阅读时间: 8 分钟 | 如何结合区块链技术,帮助企业降本增效?让我们深度了解几个成功的案例。

鹏博士电信传媒集团是上海A股上市公司,通过收购北京电信通长城宽带等子公司,目前,互联网接入及增值服务业务已占到鹏博士业务总额的95%以上。2012年底,鹏博士通过收购的北京息壤传媒文化有限公司开始对外提供公有云服务, 而支持这套公有云服务的软件是文思海辉的HSCloud,一套基于OpenStack的云计算管理系统。到2013年11月,该公有云平台上的实例数已经超过了一万个。

为了对这个OpenStack用户案例进行更深入的了解,InfoQ中文站编辑于近日跟文思海辉的云计算团队进行了沟通,包括文思海辉高级副总裁吴凯和多名主要的系统架构师。

计算资源数据

整个公有云目前用到的物理机在几百台的规模,分布在北京、佛山、香港等地的多个机房中,集群分布还在不断向各个主要国内节点的机房扩展。根据目前的增长速度,预测到明年将达到三万个实例左右的规模。

研发与运维

文思海辉在HSCloud云计算方面的团队,三分之二都是研发,其余的是运维和测试。运维方面,文思海辉负责远程的二线运维,一线运维由鹏博士/息壤的运维团队负责。

研发团队大约有一半做OpenStack本身的开发,主要用Python。

研发团队的另一半专注于业务层面和前端控制面板的研发,同时他们也需要了解OpenStack的API。因为业务层面涉及到的很多功能(如提供发票、退款、备案、针对不同渠道商的不同套餐定价等)是OpenStack项目本身所不具备的,所以这一层并没有用Horizon和Keystone,而是自己用Java写的。据透露,微软Azure在国内落地,其业务支撑系统也是由文思海辉所开发的。

在这个HSCloud云平台上,文思海辉云计算团队对OpenStack本身的改动并不是很多——事实上,修改OpenStack核心代码是需要避免的,因为会导致后续难以升级。HSCloud研发团队的工作重点在于搭建一个“隔离层”,将底层OpenStack提供的功能和上面的业务需求对接起来。隔离层做的事情很多,下面会逐步说明。

虚拟化方案的选型

HSCloud之前基于OpenStack Essex版本进行主要扩展。最初选型的时候其实考虑过CloudStack,不过因为觉得OpenStack的支持厂家更多,社区更活跃,在中国的OpenStacker人数又比较多,所以选择了OpenStack。目前看来选择是正确的。

虚拟化方案主要是基于KVM。VMware方面,主要取决于VMware开放了哪些接口。目前在vCloud层之上进行管理是没有问题的。对于目前有这方面需求的客户,文思海辉提供的方案是两套系统分别运作,通过隔离层实现在一个界面里面管理两套系统。

IBM小型机虚拟化方案也有需求,基于IBM对Openstack的大力支持,相关接口也已经逐步公开出来。

存储的选型

目前以本地存储为主。长期来看,吴凯认为本地存储的方案可以满足大多数的需求。

客户有共享存储需求的情况,EMC、NetApp、赛门铁克的存储方案都可以接入。基本上只要厂商提供的就可以用。此外,有一个监控录像存储的应用用到了Swift。

共享存储主要是应对有迁移、虚机HA、大数据类应用需求而储备,这方面文思海辉团队对Ceph、GlusterFS、Sheepdog和Swift都在进行测试,目前各种解决方案还各有优势。

此外,吴凯表示文思海辉正在跟国内的服务器硬件厂商合作打造自主品牌的Pactera云计算一体机,该方案采用了GlusterFS作为标配。

网络的选型

一开始上Essex版本的时候Quantum的功能太差,就是用Nova,加上iptables和ebtables自己实现的伪三层软路由来解决网络隔离的问题。

下一个版本的HSCloud会上虚拟企业私有云(VPDC)的功能,是基于Neutron实现的,用上了Open vSwitch,比较炫。

遇到的问题和解决方案

做一套公有云体系,很多挑战是业务上的。文思海辉认为将工作流与OpenStack结合起来,需要考虑很多东西。要确保运营商、渠道分销商、开发商等各个层面都能够获得利润,保证较好的最终用户体验,这一块需要比较多的思考。当然,还需要有足够的决心才能运转下去。

鹏博士公有云在发展到三、四千台实例的时候,其实遇到了一个很大的性能瓶颈。性能瓶颈来自于几个方面:

  1. 抢占资源经常出现,部分用户优先抢占资源造成其他用户性能差、网络慢
  2. OpenStack本身的资源调度策略是比较傻的,可能会从比较远、比较忙的节点调度资源,导致网络慢
  3. 业务平台直接调用OpenStack的RESTful接口,调用多了之后遇到压力,响应速度慢

这就造成了很多客户停用甚至退款,用户增长出现停滞。由于OpenStack本身在网络隔离和IO隔离方面的实现不够成熟,单靠OpenStack本身无法解决上述问题,因此文思海辉研发团队采取了如下动作:

首先是计算资源隔离和流量控制。基于libvirt做CPU资源隔离本身是很有效的,CPU忙其实很多时候都是IO等待所引起的。libvirt对IO隔离支持的并不好,所以引入了cgroups来实现IO的控制,给每一台VM做了IOPS的限制。再加上给每台VM做网络连接数的限制,这一块的负载很快就下来了。在管理后台可以很方便的对指定的任意VM设置资源限制,这也可以用于在业务上进行高付费级别和低付费级别的客户的区分对待。

调度策略方面倒是不难解决,因为OpenStack可定制化是很强的,只要自己写一个调度策略,忽略掉默认的nova.conf就解决了。事实上,OpenStack E版的快照、磁盘管理、迁移的功能都比较弱,也都是自己重写的。

至于业务平台跟OpenStack的对接压力,则是在隔离层做了重构,加入了RabbitMQ做消息队列。此外还加入了负载均衡,把OpenStack服务组件按照Zone进行了拆分,把负载分摊到多个集群上面。

另外,一体机方案也对IO和内存带宽做过优化处理,可以进一步缓解这方面的瓶颈。

经过这些处理和压力测试之后,吴凯表示这套系统再进一步支持到五万台实例也是没有问题的。

后续升级的挑战

从2012年9月到2013年11月,OpenStack已经经历了F、G、H三个大版本。如果一直留在E版,那么新版加入的很多功能都难以用上;但是要从E版升级到H版本,相当于要跳跃两个大版本。在建立了自己的工作流之后,要进行这样的升级是比较麻烦的。有“隔离层”的存在,意味着只要新版的API做的事情还跟老版的一样,就不需要动业务逻辑而能够完成底层的升级,这方面倒是问题不大。

上面提到的一些快照、磁盘管理、迁移的功能,在版本更新后,有的模块自己改的更好用了,有的则消失了,这方面需要做一些整合。

对于平滑升级、持续集成这一块,文思海辉已经在新版本中考虑了相关机制,也欢迎业界同行交流解决思路分享实践经验。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

屌丝外包也做云! by Wang Jensen

连屌丝外包都要开始做云了,看已经严重产能过剩了。

Re: 屌丝外包也做云! by Xue Haitao

三十年河东三十年河西,屌丝亦可逆袭。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT