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

鹏博士电信传媒集团是上海 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 做的事情还跟老版的一样，就不需要动业务逻辑而能够完成底层的升级，这方面倒是问题不大。

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

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