Neutron,网络虚拟化服务,做为OpenStack几大核心项目之一,这次在峰会上继续受到了较大的关注.
我其实是比较不乐意带着任务去参加OpenStack的设计大会的，尤其是外派的任务。但是从东京回来，各位同事和同僚总是要问我一些相关信息，比如：大师兄，Neutron项目有什么最近趋势呀？大会上有哪些亮点呀？诸如此类，我想还是做一些文字工作比较妥当。
Neutron的热度
Neutron，网络虚拟化服务，做为OpenStack几大核心项目之一，这次在峰会上继续受到了较大的关注。下面是网络和计算两大技术分类在今年两次峰会上的session数对比：
上图同时也可以看出东京峰会session的分布更加广泛，所以核心项目的session数都降下来了。大会第二天，Mark Collier的主题演讲把今年的重点放在了Neutron上，使得Neutron的热度达到了历史高点。如果没记错的话，这应该是Neutron第二次登上大会主题演讲。第一次应该是作为OpenStack的新生儿出现的，这次应该是Neutron的活跃度和社区的热度把它捧到了上位。为了证明这一点，我们仍然上图：
OpenStack项目数的激增是和管理模式的包容性分不开的。这就是现在的Big tent管理模式。
Big tent下的Neutron 的Stadium管理模式
大家对OpenStack big tent管理模式应该不会陌生，bigtent模式下一个明显的变化是没有了stackforge下的项目，这个模式的目的是希望各个项目能够比较容易地进入到OpenStack的旗帜下，并且得到应有的关注。下图为Mark collier主题演讲上的一张图。
利用Big tent，OpenStack的项目数可谓是像雨后春笋般地得到了提高。但是为了保证OpenStack的可用性和互操作性，defcore项目还是要在这些项目中选定一些，定义一个最小集。Neutron项目可望能在最近进入defcore的兼容性列表中。
发展至今，Neutron已不是单单指neutron项目本身，它是一个平台，在管理上称之为stadium模式。这个模式下允许各种插件和网络技术在各自的代码repo下，但是都集成进入Neutron平台。各个子项目一般都有自己的核心团队，有一个”队长”和neutron现有的核心团队进行交互。
Neutron项目本身被划分成多个部分，它们的划分和管理队长如下所示：
从代码仓库来说，Neutron项目本身会不断地拆分，关于具体的网络技术的实现不会直接在Neutron项目里头，它们将以子项目的方式进行管理，有自己的代码仓库，目前子项目和负责队长如下：
各个子项目的队长有任命自己core reviewer的权利。大家可以看到，neutron-lbaas和neutron-vpnaas不在这个列表中，因为他们在“队长”制之前就独立了。
Neutron的成熟度
当大家还在对是否用nova-network还是neutron纠结的时候，Mark Collier给了大家一个对比数据。
2014年统计的时候只有68%的用户使用Neutron作为生产环境，到现在，这个数据提到了89%。Mark在现场还不断地催促另外11%进行升级使用Neutron。
关于成熟度这个话题，我还比较喜欢社区引入的project 导航网站，地址是http://www.openstack.org/software/project-navigator/。其中列出了核心服务和可选服务的项目的相关信息，比如：使用率，成熟度和项目年限。Neutron的信息如下；
19个sessions到底讲了啥
一开篇我们就提到了今年有19个sessions 是关于neutron的。其中有关于管理模式的，有关于容器网络支持的。关于容器网络支持的neutron项目叫做kuryr，kuryr是courier的捷克语，主要是利用Neutron的网络技术和生态来服务于容器环境。Kuryr本身不会成为一个解决方案，它只是一个桥梁，目的是“deliver”Neutron到容器环境下。目前还处在初期阶段，不要忘了我们的前PTL Kyle Mestery在大庭广众之下Demo演砸的尴尬。如果想把它用于生产，建议要使劲测试。
另外一个项目是networking-ovn，这个项目也是个粘合剂，把neutron和ovn项目集成起来。Networking-ovn是在neutron stadium下的一个项目，实现为Neutron的插件。到目前为止，ovn只实现了二层的功能，而且作为一个独立的插件来实现的，不是作为ML2插件的扩展。很明显，networking-ovn的实现者认为ML2实现得太复杂，容易隐藏bug，不容易维护。这次的OVN演讲主题是：ovn feature complete and ready to test，就是说功能完成了，可以测试了。在我看来，功能上还有一些差距。比如3层的分布式路由还没有，内嵌的DHCP服务还没有。如何处理metadata的问题还没考虑。但是其中OVS来实现security group还是比较令人眼睛一亮的。这个功能需要对比较旧的Linux内核打补丁。OVN方案令我感兴趣的地方有两个：
1.减少了消息数。众说周知，现在neutron的参考实现中，消息数量太多，这造成了系统性能和稳定方面的隐患。OVN方案减少了这个过程。
2.分布式路由。利用流规则来实现分布式路由，省略了现在参考实现中附加在ovs bridge上通过各种消息来实现的DVR中的算法和代码复杂度。
另外的session就是关于Liberty中引入和增强的feature的介绍。这些feature当中，有些只是有BP提交，有些有了初步实现，比如：
1.QoS，目前neutron的QoS还是比较粗糙的，主要是作用在端口上，而且用于限制虚拟机的发送流量。当然，新版本中，我们会引入更多的QoS规则
2.DNSaaS，这个项目名字叫Designate，是一个很早就有的由HP引入的一个项目。在Liberty版本中，有人开始在Neutron中使用它来作为虚拟机的名字提供解析服务。
3.BGP动态路由，目前Neutron的虚拟路由器支持静态路由，但是这些路由不能宣告出去，还有就是多个虚拟路由器之间也不能打通。有了BGP动态路由功能，这些问题就迎刃而解了，也为支持更多的传统网络用例提供了基础。
4.多层次绑定。多层次绑定是为大规模部署准备的利器。这个功能帮助Neutron使用TOR交换机提供隧道服务从而提高系统性能和稳定性。
5.LBaaS。在liberty版本中，新实现了API 2.0，而且把octavia，电信级负载均衡架构后端支持作为缺省支持。
设计峰会
OpenStack 峰会包括两大会议，一是OpenStack大会，目标群体是任何云计算相关人员，由典型的演讲者、胶片和听众组成的一个一个演讲组成，里面有为初级人员准备的教程，也有为架构师而设的最佳实践，还有为参与者准备的案例分析。第二个会议是设计峰会，设计峰会不会有胶片和演讲者，但是有etherpad上文件记录的讨论大纲。大家坐在一起讨论这个大纲，并且提出更多的方法和建议。
这次峰会中给了Neutron 12个session，还有一天的contributor meetup。Neutron的设计峰会以讨论Liberty遗留的BP开始，比如地址范围功能，动态路由功能，AZ调度功能，还有就是neutron客户端命令。每次设计大会中跨项目的协调始终是主题，我们讨论了在stadium管理模式下的tempest和第三方项目的协调，讨论了和horizon，nova，devstack的协调。同时也给了LBaas和FWaas各一个session，讨论各自的发展方向和功能的设计。在这些设计讨论中，Extending the existing networking logical model and protocolssupport最令我记忆深刻，其中有一个是要改变现有的核心资源网络、子网和端口的关系，增加一个ipnetwork的资源类型。如果说现在的网络是个广播域，Ipnetwork应该是个路由域，ipnetwork之间还能嵌套，形成一个树形结构，一个树形结构下的端口是可以三层互通的。当然目前为止这只是概念，具体能在哪个release中落地还得等着瞧。
后记
这些就是我参加这次大会对neutron的印象，当然有人会说，大师兄，NFV和SDN呢，你怎么不谈谈？我个人认为这两个概念都是基于Neuron的高级概念，是Neutron乃至整个OpenStack的衍生品。我希望日后有单独的拙文来剖析它们。
Neutron的发展需要各种人才前赴后继，我喜悦地看到华为、思科等老牌网络企业在里面有越来越多的贡献。最后我以一张NeutronStar中子星的图片结尾，祝愿Neutron在漫漫云计算宇宙中永放光芒。
转载自：trystack微信公众号
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
