王为：开源本身是一件好事

个人简介 王为 SDN 工程师，2014年5月加入 UnitedStack，专注于虚拟网络和 SDN 方向，OpenStack Neutron 社区活跃贡献者。

全球架构师峰会（International Architect Summit，下简称ArchSummit）是由InfoQ中文站主办的一次全球性架构师峰会。ArchSummit专门针对架构师人群，讲述与架构和架构师相关的各方面趋势、技术和案例。这也是继QCon之后，InfoQ中文站主办的又一次高端技术盛会。

   

1. 大家好，我在ArchSummit深圳大会的现场，今天非常高兴邀请到了UnitedStack的网络工程师王为。王为在SDN虚拟网络功能方面有比较深入的研究。您大概是在2014年加入的UnitedStack，您在那里主要是负责UnitedStack的核心产品UOS，关于虚拟网络方面的构建。能大概说一下您在去年加入UnitedStack后所涉及的工作以及这些工作的重心和内容吗？

王为：我从去年年初加入了UnitedStack，当时正在筹划我们的第二个产品——UOS2.0，或者是说现在的UnitedStack公有云平台。在之前UOS1.0向2.0转变的时候遇到很多挑战，其中之一是Neutron本身其实并没有经过很多的验证，很多Superuser都在使用Nova Network，所以我们在Neutron上，无论是功能方面还是稳定性方面都做了很大的研究和拓展。在功能上我们增加了公有IP绑定的路由器或说是同步转发，以及很多企业需要的功能；在稳定上针对OpenvSwitch本身的Agent与虚拟路由下了很大功夫去做了定制和研究。

   

2. 您所说的针对于IP的整个管理体系，是怎么样的情况？这方面的绑定是跟厂商合作还是你们自主去实现？

王为：我们的方案是完全纯软的，不产生任何锁定。我们大部分功能是比较依赖Linux网络协议和OpenvSwitch本身的，这样就避开了硬件的问题。当然这样有好处也有坏处，好处是灵活，完全自主的；坏处是软件方面要下很大的功夫去研究如何提高性能。

   

3. 您工作到现在这方面有一些新的改善吗？或者说需要有一些持续性的工作？针对这方面，虚拟网络还有哪些问题也是你们工作的重点？

王为：监控应该说是所有云计算系统里面的一大痛点，因为监控很复杂，管理上需要注意很多。比如每台物理机都要管理它的cpu的性能，cpu的load，IO的情况，还有它的磁盘性能。然后针对虚拟机还要检查它的负载和IO性能，针对交换机与API也同样需要再检测。我们的监控中心前段时间甚至有上两万条的监控项，监控系统非常的复杂。网络方面我们也做了很多事，首先是API的监控，其次是网络性能方面，也就是QoS上下了很多功夫，因为社区本身是不提供QoS的。社区本身没有做的两大QoS，一个是用户网络的QoS，比如说用户提供它千兆的网卡，另外一个是国内公有IP的带宽的QoS，毕竟它是有一个限制的。我们花了很多的力气处理这个问题。关于公有IP的QoS是比较头疼的，因为它是实现在路由器上的。如何只限制在路由器的南北向流量上，而不把用户的流量也限制住，还要实现绑定大量公有IP，做性能和查询算法的优化，作为我们工作的一个重点，在去年到今年的这段时间里基本都解决了。

   

4. 目前这个监控功能已经在UOS2.0上面集成了吗？

王为：对，我们现在应该都统一叫作UStack有云。我们发现UOS1.0到2.0对国内的很多用户来说被当作是一个版本的升级，而不是一个产品的转化，所以我们通过提供一个新的品牌标识来提醒用户这是一个很大的变化。

   

5. 在监控方面，除了QoS你们还会定期做一些更针对于网络的探测监测吗？

王为：有，这部分监控叫作SLA监控，区别以前的通过zabbix或者jog来做的监控。做这方面的监控可以完全模拟用户的感受，因为用户体验与监控结果是有间接关系的。你在服务端上做任何监控都有可能失效，所以我们通过自动定时的去启动虚拟机，启动网络，启动公有IP，来监控它的SLA，看它的SLA是否达到我们给用户的承诺。这方面需要基于我们的平台各个组建的。

   

6. 用户可以自定义去构建这个监控吗？

王为：对用户来说这些其实是透明的，用户只会关注他想了解的部分。他们不关心我们用什么方法进行保障或者监测。用户不需要我告诉他你身边的好多虚拟机，它们网络IO正常，公有IP流量正常，公有IP的性能很好。我们有自己的集中化的监控中心，所有的监控服务都是独立运行并向监控中心报告，然后监控中心会给我们发出通知。

   

7. 目前这种监控中心是你们自主研发的吗？

王为：是基于开源研发的。并且我们也在大量使用这种开源软件。

   

8. 针对于OpenStack社区的发展以及在开源软件的应用方面，能谈一下您的看法吗？

王为：开源本身肯定是件好事，如果没有开源软件的话现在很多IT平台或者web平台都没法搭建起来。但是社区一旦发展得大了也会有很多问题出现。OpenStack社区本身有很多公司的支持，而且最近有另外一家重量级公司——Google宣布加入OpenStack的组织。不过山头多了就容易引起分歧，可能会有政治问题。 以Neutron为例，目前Neutron在一些新特性的开发方面速度并不尽如人意，比如一些我们已经有了设想的功能，并没有完全开发出来。其中包括代码的审查慢，因为社区会有一套很完整的CI体系来检查代码是否健康，而Neutron为了支持了大量的第三方的厂商需要加入第三方的CI，所以你可能为了提交一份只有一行的改动，而需要跑去IBM的CI，Cisco的CI和各处厂商的CI。

   

9. 由于Neutron支持了很多的厂商，导致厂家各自的CI都集成在你们现有社区CI体系里，使得你们的流程非常长。那么这种周期有一个时间概念吗，比方说一个月？

王为：一个月倒还不至于，只不过Neutron本身为了保障社区的完全公平，它是个瀑布式的开发模型。bug fix相对来说好一点，对现有CI体系来说一般跑一遍大概是一到两天左右。但如果你想提一个功能的话，需要先撰写说明书，放在社区上供人评阅。当社区的PTL认为这个功能已经经过足够多的人评审了，他们才会考虑把它合并进去，才开始提交代码。然后通过CI的检查、review的检查与社区的检查，最后合并到主分支里。所以新功能的开发流程非常的长。

   

10. 面对这么高的时间成本，你们还会去贡献开源的代码吗？

王为：之前我们对社区的贡献一直都非常高，应该是国内贡献最高的公司。后来由于自身需要努力研发的缘故，在一段时间内的贡献可能有所下降，但是我们还是很积极地在做这种贡献的，目前排名也在稳定上升。我们希望把自己维护的代码交给社区维护，因为自己维护的话可能会错过一些问题，而在社区可能会被发现。我们也会积极地参与一些非核心的，但是很有意思的项目：比如说社区正在积极地进行Nova的分拆，把它的schedule分拆出来；比如Neutron把网络分仓库后在努力解决代码推进慢的问题。

   

11. 您觉得在厂商在依赖自己的内核与依靠OpenStack社区支持方面，两者的结合的可能性更大呢，还是说两者分离的可能性更大？在能够捆绑的情况下，性能是不是会更高一些？因为对虚拟网络来说数据最后还是会经过上层交换，从您的角度是怎么去看待这个问题的？

王为：首先社区是完全中立的，它不倾向于任何一个厂商。因为社区有很好的架构，可以满足厂商的开发的需求，然后厂商通过自己开发以插入的形式将需求插入进来，所以社区是没有问题的。你想问这种纯软方案与硬件依赖方案，能否融合是不是。情况是这样，对于纯软的方案来说，虽然需要你去解决很多性能上的问题，但是它灵活；而对于硬件方案来说，虽然跟厂商的绑定关系比较重，但是在短期内效果更好。所以这个问题恐怕没有一个标准答案，我个人建议恐怕还是要看公司的实力。比如Comcast公司是上一届Summit里OpenStack的第一名得主，击败了天河二号与沃尔玛，成为了Superuser。他们在OpenStack的数据上做了很大的努力，有上百名工程师在社区工作。我觉得如果公司的研发能力强或者是希望比较care这方面的话，完全可以靠纯软方案去解决问题。但如果研发能力没有那么强，或者觉得硬件方案也可以接受的话，也是一个很好的方法。其实现在很多硬件厂商也在很努力地向软件方向走。

   

12. 针对现在的虚拟化网络的发展方向，您能根据您的经验谈谈后续的发展的趋势吗？比如会向哪些方面靠拢，有哪些新功能，或者会有哪些大的改变？

王为：说起来主要是几点吧。一是关于SDN或者云上虚拟网络这类东西，大家肯定永远都会去追求更好的性能，这个我们之前也有所谈到，就不再详细说了。另一个是关于提出网络功能的虚拟化，比如ovs虽然是一个虚拟交换机，但其实它是一个比较底层的东西。网络里面有很多更上层的东西，比如网元的设备，包括高级网关，高级的防火墙，路由器等等。

目前大家在热谈NFV的事情，也就是软件功能的虚拟化。这是将来需要很长一段时间去进行的工作，因为它的最终结果可能使数据中心里的很多设备，甚至运营商的很多设备被取代，这是一个往上说的发展方向。往下面来说，开发者还会比较关心容器方面的事情。目前容器的解决方案也不是多令人满意，它的安全性隔离性都不尽如人意，所以容器的网络技术也是一个未来的发展方向。前段时间Ubuntu的母公司Canonical就发布了一个网络容器叫做Ubuntu Fan，它是一个很好的尝试，但是距离企业级应用还是有一段距离的。

   

13. 您刚才提到隔离container这种方案，这方面你们也会进行一些支持和关注吗？既然你们在OpenStack上进行了部分转型，那么在平台提供的服务方面也应该不仅限于OpenStack本身吧？如果在container方面你们你作为后续支撑的一个组件或服务的话，那么在网络方面你们的挑战会更大。

王为：网络方面的挑战我个人认为就是刚才跟你说的那部分，至于安全的问题，解决的方案也已经是比较多的了。我觉得这方面压力还是比较小的，关键是如何去选择一个合适的方案，如何去解答用户对容器安全性的考虑。

   

14. 我们今天整体的采访就到这里结束了，最后想请您聊一下此次参加大会的感受。

王为：很感谢InfoQ提供了这么一个机会，供来自全国各地的讲师和架构师在一起交流，感谢ArchSummit提供了很密集的议程和talk，让人受益很多，并认识了很多朋友。

InfoQ：非常感谢王为接受我们今天的采访。