上周我们回顾了在东京OpenStack Summit上，Puppet、Ansible、Ceilometer、Gnocchi、Aodh、Monasca、Cloudkitty等项目的最新进展。今天我们将目光投向OpenStack的存储、容器、计算和网络领域子项目的发展走向。

以下内容根据2015年11月15日举办的“奔跑吧，OpenStack! ——UnitedStack与您⾯对⾯·北京站·东京峰会见闻专场”相关演讲整理，特此鸣谢。

存储、容器领域子项目的新进展，如何与Ceph更深入地结合

分享人：UnitedStack有云存储组PTL 陈迪豪

在“Big Tent”（大帐篷）模式下，孵化出了一些新项目，例如Magnum、Murano、Kolla。加上Cinder、Trove、Sahara，还有Ceph这一与OpenStack紧密结合的开源分布式存储项目，整个存储和容器领域的项目家族已经十分兴盛。

Cinder项目

目前，Cinder项目已经持续集成了60个驱动，其中包含16个存储卷驱动。值得注意的是，在这些驱动中，一些商用存储厂商（比如EMC、华为）会提供自己的商业存储设备来与社区项目做持续集成，这样就可以保证Cinder的每一次版本升级都对所有的驱动进行测试。另外，Cinder的新特性还包括新增了镜像缓存功能，不过如果后端使用的是Ceph这样的分布式存储，这一功能的意义就不是很大了。还有就是新增了Nested Quota（嵌套配额）功能，它与Keystone里的Project in project十分类似。

在OpenStack的下一版本Mitaka中，Cinder会支持真正的卷异步复制。关于Cinder，社区一直有一种传闻，称Cinder有可能从OpenStack社区脱离，成为一个统一的容器、虚机的块设备存储。那么在Mitaka版本中，Cinder和Nova的结合将会更加紧密。

比较有意思的是，通常我们使用Cinder默认的存储是LVM ，分布式存储一般选择Ceph。而在东京峰会上，我们接触到了众多的商业存储厂商，他们都开始与OpenStack做集成，而其后端的存储技术也是十分丰富的，比如iSCSI、FC、FCoE等。最近一段时间，UnitedStack有云的存储团队也开始做一些有意思的尝试，尝试将UOS云服务平台与一些商业存储系统（比如iSCSI）实现整合。

Trove项目

目前，Trove提供了SQL数据库和NoSQL数据库的服务，其中包括MySQL、Oracle、MongoDB、Redis、MariaDB、HiBase、Cassandra等。在未来，Trove还可能会支持新出现的NewSQL。

对于容器的支持，考虑到容器和OpenStack的集成仍然不够深入，Trove社区采取了观望的态度，希望 Kubernetes这样的项目能够为Trove提供编排工具，而Trove只需要关注数据库服务本身就可以了。在支持的数据库类型方面，在Mitaka版本中，Trove对不同数据库类型的支持将会精细到不同的版本号。目前Trove社区支持基于Swift的数据库备份，在未来，Trove有望支持目前非常流行的Ceph RGW备份方式，同时也支持基于Cinder的快照备份。

在东京峰会上，我们与Trove社区进行了深入的交流。在具体实践层面，UnitedStack的很多做法已经领先于社区，我们已经把这些具体的经验与社区分享。UnitedStack已经实现了基于Cinder的快照备份，与社区的推进方向不谋而合。而在Guestagent升级方面，社区目前拟定了几个方案，比如基于SSH或者Puppet Agent。UnitedStack有云的数据库服务和缓存服务已经开始内测，我们在内部已经解决了Guestagent升级的问题。

在配额管理方面，Trove对实例的个数或者卷的大小是有配额限制，而这种配额限制是全局的。如果基于Trove提供了MySQL和Redis服务，配额管理将限制两种数据库类型。Trove社区之前专注于做数据库服务，并没有考虑到这样的问题。UnitedStack在产品化的过程中发现了这样的问题，在内部我们已经实现了对不同数据库类型独立的配额管理。另外，我们还尝试了通过Ceilometer对Trove进行监控。

Magnum项目

在Liberty版本中，OpenStack的容器项目进行了很多重要的功能升级。其中包括对Mesos的支持、对Kubernetes集群的支持，以及Magnum的自动扩展功能，Magnum项目已经与Heat项目实现了集成。在Mitaka版本中，Magnum将集成网络容器项目Kuryr，并且推出Magnum的UI。从2014年开始，Magnum项目发展迅速，但是目前看，它的主要工作是对不同的容器框架做配置。

Ceph项目

本次峰会的Ceph主题的演讲并不太多，Ceph项目的创始人Sage Weil讲了在OpenStack中Ceph、Manila和容器的结合。另外，题为“Ceph and OpenStack: current integration and roadmap”的演讲也非常精彩，讲述了最新的Ceph和RBD能够实现的功能。在Ceph的当前版本（INFERNALIS）版本中，推出了多个期待已久的新功能。其中包括RBD驱动增加了卷删除的机制，支持Cinder的卷迁移，以及兼容对象存储项目Swift的API。

Jewel是Ceph的下一个版本代号。在Jewel版本中，Ceph将实现Cinder卷的异步复制。也就是把数据写到一个卷中，然后它被异步复制到另一个地方进行备份。另外，Jewel版本还将支持双活的RGW架构。Ceph在Liberty版本中支持的功能，以及Jewel版本中的功能升级具体如下：

最成熟的NOVA如何更出色？

分享人：UnitedStack有云 NOVA PTL 刘家军

“OpenStack Summit汇集了农贸市场、大学课堂和茶话会三种场景”，这是刘家军参与东京峰会的感受。所谓农贸市场就是峰会期间86家参展商云集的现场展示区，在这里你可以看到各式各样的厂商秀，并且与厂商的技术人员面对面深入交流。而大学课堂就是会议期间安排紧凑的Session，不同的厂商会分享他们的经验，对技术发展的看法，很多Session都非常精彩，让参会者受益匪浅。Design Summit则更像是茶话会，大家更多地是讨论下一个OpenStack软件版本要做的工作，开发者展开更多的交互，讨论十分热烈。

作为OpenStack现阶段最为成熟的子项目，Nova在未来将如何发展呢？根据相关统计，Nova的部署率和成熟度在OpenStack项目中都是非常高的，但是这也并不意味着Nova已经趋于完善，它仍然有很多需要改进的地方。那么在Mitaka版本中，Nova项目的主要努力方向是什么呢？

1. 向用户交付更稳定的API。社区一直在努力解决Nova V2版本的稳定性问题，也曾尝试推出Nova V3版本。但后来发现，这样的大版本跳跃也不是最合理的解决方案。社区目前的解决方案是用“小版本”（Mirco Version）逐步演进的方式，也就是说，在客户端，用客户说明需要的API版本，每个小版本的改进都会向上递增。这样做的好处是确保的API交付的逐步演进，而不是像以前那样跳跃式的发展。

2. 虚拟机性能优化。在基本功能日渐完善的情况下，社区也对基于Nova创建和交付的虚拟机的性能抱以重点关注。也就是说，Nova不仅能够帮助用户创建、管理这些虚拟机，也要保证交付给用户的虚拟机是高性能、高可用的。

3. 与其他服务强化协作。作为OpenStack的基础组件，Nova为Trove、Heat等众多子项目提供基础计算支持。而Nova的稳定性与可用性与这些上层服务的稳定性密切相关。因此，Nova正在致力于成为OpenStack相关子项目的基石，为服务之间的协作不断提升自身的稳定性。

4. 继续保持“开放”的开发文化。 目前，包括Nova在内，开发者在参与社区项目开发时通常会面临效率低下的问题，提交Patch、修复Bug的过程都十分耗时，周期很长。好在目前社区已经注意到了这样的问题，正在进一步推动开放的社区开发文化。

Neutron、DragonFlow如何让OpenStack网络更完善？

分享人：UnitedStack有云SDN网络部PTL 王为

NTT的示范意义

王为首先分享了在东京峰会摘得超级用户大奖的NTT Group的应用案例。OpenStack在实际部署时的坑是非常多的，这其中有太多的组件或模块需要同步或者集成、底层环境需要做修复Bug等升级操作、脚本执行经常出现异常。部署对于UnitedStack这样向客户交付云服务的公司是非常重要的，需要在这一环节实现快速部署、快速上线。NTT在自动化部署和基准测试方面进行很多有意义的尝试，他们采用的具体架构如下：

NTT的基准测试采用的方式是，先把网络规划、服务器规划写成文本，提交到Github中。然后整个的部署过程就可以用 jenkins 自动化进行了。作为一家电信运营商，NTT把OpenStack玩得很炫很酷。NTT得出的结论是，OpenStack的部署并没有一套完整、统一的解决方案，需要借助很多工具，有非常长的工具链。不过，用户只要合理地使用这些工具链，OpenStack的快速部署还是能够达到很好的效果的。NTT在OpenStack领域的实践不仅仅局限在部署方面，在NFV也有进行了非常深入的尝试。

“Big Tent”的机遇与挑战

除了典型的用户案例，“Big Tent”模式在东京峰会上迅速传播。“大帐篷”到底带来了什么呢？从github.com的OpenStack目录下，已经有了600个以上的Repos，这在之前是很难想象的。在十余个核心项目的基础上，OpenStack社区迅速孵化出众多的子项目。比方说做状态机管理的Automaton项目、专注ERP集成的Distil项目，以及能源消耗测量的Kwapi项目等等。“Big Tent”模式增加的OpenStack项目的繁荣度、产生了很多优秀的项目。但是我们也发现了一些问题。比方说，有的项目只有十几个Commit，前景不明。因此，“Big Tent”带来了宝贵的机遇，但是开发者也需要去辨别。

备受诟病的Neutron何去何从？

在东京峰会上，Neutron成为各方关注的焦点。这可能与Neutron在现实环境受到的种种诟病有关。前段时间有从业者撰文表达了一些对Neutron的悲观看法，提到的问题主要包括数据库模块的稳定性问题、RPC系统的稳定性、集群资源的协调等。实际上，数据库的死锁问题在开发中确实常常遇到，如果在开始阶段对数据库的用户定义不清，每一次的功能调整都会带来新的BUG。Neutron在演化过程中一直在努力解决这样的问题，从2011年至今不断完善。RPC系统的稳定性与开发者自身的搭建过程密切相关，很多人认为，在大规模应用的条件下，Neutron几乎是不可用的。而在这方面，UnitedStack已经在公有云平台进行了长期的实践，证明了Neutron作为底层的云平台网络的可行性。

DVR似乎也不是救世主？

Neutron不够令人满意，有段时间DVR似乎成了大家眼中的Neutron救世主。但是现在，DVR也开始受到抨击。DVR是由HP的工程师在没有代码的基础上进行修补完成的，其代码实现不优雅、很多服务依赖于RPC、运营存在挑战等。针对这些问题，OpenStack社区引入了一些有意思的解决方案。比如，networking-bgp 引入Bagpipe（法国Orange电信的项目）用来实现EVPN。

Dragonflow的未来路线图

关于Dragonflow项目，东京峰会期间王为与Dragonflow项目的发起者Gal Sagie做了一些探讨。在Liberty版本中，DragonFlow进行了多项性能优化，包括提供隧道优化、可插入式DB层、分布式DHCP等。从目前的情况看，DragonFlow的架构正在由纯粹的Centralized转向支持Centralized、Decentralized两种架构，后者将面向更大规模的方案，Dragonflow项目的另一个重要开发者Eran Gampel在博客上有定性的比较。SmartNic和SDN ToR算是对性能优化的一些尝试，可能Dragonflow和OVN将是Neutron SDN方案中最具有竞争力有的两个选手吧。

Dragonflow项目的技术路线图究竟如何呢？Sagie在东京峰会期间给出了具体的规划。Dragonflow正在设计的功能包括分布式SNAT/DNAT；分布式网络功能、拓扑注入与服务链；智能NIC；分层级的端口绑定——SDN架顶交换机；以及容器。