章宇：OpenStack在各领域的发展都很良性

个人简介 章宇博士于2002年及2007年分别于清华大学电子工程系获得学士及博士学位，其后加入IBM中国研究院，从事计算机系统领域的研究与开发工作，先后参与或主导过异构多核处理器设计及仿真、异构多核处理器虚拟化、FPGA虚拟化、OpenStack特性增强等多个项目。章宇博士于2014年1月加入华为技术有限公司，目前供职于云计算产品线云操作系统产品部，专注于OpenStack产品化工作。 闲时喜欢读读历史，听听音乐，曾经当过戏剧青年。 理性军迷一枚，“自古知兵非好战”。 支持后驱，时常开着Reiz到处流窜。 衷心希望国家富强，人民幸福，天天阳光灿烂，永葆APEC蓝。 Linkedin: Yu Zhang

QCon是由InfoQ主办的全球顶级技术盛会，每年在伦敦、北京、东京、纽约、圣保罗、杭州、旧金山召开。自2007年3月份首次举办以来，已经有包括传统制造、金融、电信、互联网、航空航天等领域的近万名架构师、项目经理、团队领导者和高级开发人员参加过QCon大会。

   

1. 大家好，我现在在2015年QCon北京大会现场，今天十分高兴邀请到华为的云产品线，云操作系统产品部架构师章宇博士接受我们的采访，章宇博士以前是做虚拟化的，对各个方面都有研究，现在做OpenStack比较多，请你先简单介绍一下。

章宇：大家好，我现在在2015年QCon北京大会现场，今天十分高兴邀请到华为的云产品线，云操作系统产品部架构师章宇博士接受我们的采访，章宇博士以前是做虚拟化的，对各个方面都有研究，现在做OpenStack比较多，请你先简单介绍一下。

   

2. 好的，今天您分享的话题其实是NFV在OpenStack落地的情况，您提到说这个是属于专门给电信级的云做的一个方案，可能跟OpenStack的很多思路不太一样，折腾了比较长的时间，最近OpenStack社区才接受这些改动，大概说一下现在的情况吧。

章宇：这个事情是这样的，因为OpenStack开源项目从它最早创建开始，我们都认为OpenStack它是用来构建云的。这个云呢，可能有两种场景，一种是公有云，一种是私有云。NFV从传统意义上讲，它其实最早是源自电信网络得一套系统，怎么样能够把它虚拟化，把一些电信网络的关键网络设备，通过专用的硬件、软件实现，变成相对开放的体系结构，然后在开放的硬件架构Hypervisor上面跑虚拟机，变成开放的架构来实现。这样的一个应用场景，他和传统意义上的云的场景实际上是有所区别的，这个区别更多地强调虚拟机的性能，强调虚拟机与虚拟机之间，虚拟机与外界之间的数据转发的性能。强调整套系统的可靠性，包括控制面和数据面的可靠性。还强调一些类似于故障管理自动化等概念。这些概念确实不是传统的OpenStack的典型诉求，事实上OpenStack社区，一开始不认可这种场景，现在逐渐认可并接受这个场景。这个中间确实经历了一定的过程。我个人对这个过程的背景比较清楚，因为OpenStack从2014年开始，就开始逐渐从自身组件的功能丰富，或者是特性的开发，转向在各种应用场景里边落地，特别是商用化的落地。在这个过程当中，社区也开始逐渐认识到NFV是一种比较强烈的商业诉求。NFV的生态系统也认为OpenStack确实是一个可以帮助NFV加速落地的开源平台。 OpenStack社区和NFV的生态系统之间，也有意识地进行了这种合作。我们看到在2014年下半年，NFV场景对很多特性的诉求就开始逐渐被社区接纳了。在OpenStack里面，至少有两个大的组件或者说模块都接纳了和NFV相关的一些特性，比如Nova。我们前面提到过，在NFV场景下，虚拟机的性能是一个比较关键的因素，虽然说虚拟机的性能直接取决于Hypervisor的能力，但是Hypervisor具备了这些能力之后，我是不是能够通过Nova的API把这些能力暴露出来，让虚拟机的创建者或者说虚拟机的用户去调用，创建符合性能要求的高性能的虚拟机。这个确实需要Nova和Hypervisor配合来完成。Nova从去年10月份的Juno版本开始，包括今年上半年马上要发布的Kilo版本，陆续接纳了很多跟虚拟机性能优化相关的特性，比如物理CPU和虚拟CPU之间的绑定，包括虚拟机的大页面，包括NUMA亲和性和IO亲和性的调度，等等。这些特性都陆续在Nova里面落地了。Neutron也接纳了一些跟NFV相关的特性，比如支持虚拟交换机。这些都是为了满足OpenStack在NFV场景下的应用需求。

   

3. 好像整个OpenStack的氛围，包括这些项目的发展都有一些有意思的变化，能大概给我们介绍一下吗？

章宇：是这样的，实际上OpenStack这个社区，总的来说还是一个很开放很繁荣的社区。虽然说最近有一些OpenStack的负面消息，但是我个人感觉，这些消息本身并不能对OpenStack构成根本性的冲击。因为OpenStack的繁荣取决于两个因素。第一，从大的技术发展趋势角度上讲，云这样的一个技术类型，或者说技术趋势，它是不是最终会成为IT交付或者落地的主流趋势，如果会，OpenStack就有它的市场。第二，社区里面的这些大的厂商，不管是不是在商业上有竞争关系，但都是在本着这种开放和合作精神在社区里面做事，那么这个社区本身就能够健康发展。我们可以看到Kilo版本的各方面的指标，实际上都是再创新高的，并没有比以前有下降的趋势，这个就是最能说明问题的一个现实情况。从具体技术角度来讲，我们可以看到，OpenStack这个社区项目的分布或者项目的技术走向。从技术上讲，我认为有几点是值得关注的。首先就是OpenStack最早赖以起家的IaaS层的这些项目，总的来说它们的功能是比较丰富的，能够满足客户大部分实际需要。比如说以Nova为代表的一些核心项目，它会更多地追求项目本身的稳定可用。那么当然它还会审慎的再去接纳一些新的特性。那么在IaaS层里面，更活跃的是Neutron，因为Neutron主要关注的是二三层虚拟网络的管理能力。比如说二三层的网络定义，网络间的隔离等。但是后续随着二三层服务的不断成熟，它应该会向上发展，扩充四到七层的能力。这方面大家如果注意的话，可以看到社区现在是比较活跃的。在IaaS层以上，我们会以稳为先，同时有意识地扩充以前的不足。OpenStack也和我们很多的公有云的发展趋势相似，他会逐渐从IaaS层往上扩充并提升服务能力。在OpenStack社区里，有大量的PaaS层甚至是SaaS层的项目。比如说在PaaS层，我们有大数据级服务，有数据库级服务，有消息总线级服务，甚至有像Solum这样纯粹意义上的PaaS项目。在此基础之上，随着现在容器计算技术的发展，在OpenStack的IaaS层上也出现了纯粹意义上的容器级服务项目。在SaaS这一层，OpenStack社区里面也出现了Murano这样的SaaS服务框架。这些动向其实都是非常值得关注的。除了IaaS、PaaS、SaaS这三层服务能力以外， OpenStack社区也在关注OpenStack本身的运维能力。因为OpenStack是一个相对比较复杂的IT系统，对于这样一个系统，它怎么去运维，肯定是很值得关注的。现在社区不管是在解决OpenStack的安装部署的便利性，还是在解决OpenStack监控、分析便利性等角度，其实都有一些相关的项目正在推进。总的来说，在OpenStack的各个领域，传统的领域在不断成熟，新兴的重点的领域，也在不断涌现新的项目。所以我个人认为，OpenStack这个社区的发展还是很繁荣、很健康的。

   

4. 好像说现在也没有孵化项目了。

章宇：对，后续OpenStack社区会稍微调整它的政策，然后改变项目的划分方法OpenStack的社区的项目，有一个单维度的评价，也就是说是集成项目，还是次一级孵化项目，还有更次一级的所谓的新创项目或者是其他项目。这样的一个评价机制，实际上最早是为了便于管理整个项目的发布周期。集成项目就意味着，当某个版本正式发布时，集成项目是跟随正式版本一起发布的。但客观地讲，集成项目确实不意味着100%成熟可用。特别是这样一个单维度的评价体系。从某种意义上讲，它导致了社区的功利化倾向。所有的项目，不管创建的时间长短，是不是真的成熟，都会非常努力地想成为集成项目。社区管理机构也看到了这样的问题。所以现在社区已经改变了这种单维度的评价机制。首先取消了之前维度系统中的孵化状态，只有集成项目和其他项目。社区将来也会扩展出其他的维度描述或标签，然后采用一个多维度的机制来综合描述一个项目，它是否成熟可用，帮助最终用户去判断，某一个项目到底是不是有必要部署、使用。

   

5. 您刚才也提到，容器相关的一些项目，OpenStack和容器的一个组合或者说合作，您对此持有什么观点？

章宇：这个其实也是一个非常好的项目，也是一个现在非常热的一个问题。一直都会有这样的声音出来，就是说有容器了，我们是不是还需要OpenStack。就我个人感觉，如果我们纠结于这样一个问题，那可能说明我们对于OpenStack和容器这两者的定位还不完全清晰。客观讲，其实OpenStack它从最早产生的时候，它首先解决的是SaaS层的资源的抽象、管理包括孵化，它更多是怎么样把下面的不同类型的物理资源，比如说不同的物理服务器，不同类型的存储，不同类型的网络设备，把它分门别类的打成资源池以后，进行抽象，对外提供服务，这是它关心的能力。OpenStack最早是盯着下面的层。而容器主要是采用一种轻量化的方式，去对应用做封装，包括引入了Docker以后，这种封装会是格式化、标准化的，解决应用的分发、部署的便利性问题。通过这种对比我们可以看到，其实OpenStack所解决的问题跟容器所解决的问题，本身并不完全重合。反过来讲，它也很难相互替代。如果想把容器应用在一个相对复杂的IT环境下，他必然就要面临网络的异构，网络的抽象管理，存储的异构，存储的抽象管理等问题。当然容器也可以把这些事情自己再做一遍。但是这个成本会很高，而OpenStack已经解决了这样的问题。那么在这种情况下，一个非常合理的思路就是让大家各司其职。OpenStack管好资源的抽象，提供必要的服务。而容器着眼在怎么更好地支撑、抽象应用这个层面上，大家分工合作，并不是严格意义上的相互替代的关系。OpenStack社区也逐一的解决了OpenStack跟容器，包括OpenStack跟Docker之间的融合问题。现在应该是有几条技术路线都在同步推进。比如像Nova，它在尝试把Docker作为一个虚拟化的类型，然后通过Driver的方式，用Nova去管理Docker，这是第一个。第二，Heat作为一个资源的编配机制，它也会把Docker作为一种可以被编配的资源类型进行编配。这就是OpenStack传统的核心项目在容器相关的技术方面上做的一些工作。在此基础上，OpenStack社区还有一些新的工作正在推进。比如说我们会看到OpenStack社区里面有一个项目叫Magnum，它就是一个容器即服务的新项目。它的诉求是，在OpenStack里把容器当作一种新的服务类型对外提供，然后通过OpenStack的框架，然后用API去管理技术栈所构成的服务能力。这可能就更接近于我刚才提到的，在一个更合理的方式下，解决容器技术生态与OpenStack技术生态相结合的问题。另外，就OpenStack本身，它其实是一个由大量的组件所构成的一个相对比较复杂的IT系统，如果仔细分析，可以发现OpenStack包括OpenStack所依赖的第三方组件，可以看作一个分布式的Web架构的应用，特别是从Linux操作系统角度往上看，它其实就是一个Web架构分布应用。而Docker本来就可以用于管理，比如分发、安装部署一个分布式Web架构应用的引擎，那么这种情况下，是不是可以用Docker来加速或者说是使OpenStack的安装更便利呢？其实是可以的。所以现在社区推出了Kolla，解决怎么样利用容器的技术，利用Docker使OpenStack的安装，以及自身的生命周期管理变得更容易。我个人认为，这个技术方向也比较有意思，也是值得关注的。