转载请注明：
http://yeasy.blogspot.com/2014/12/openstack-neutron.html
历史
OpenStack 作为最热门的云计算开源项目，自 2010 年 10 月发布第一个版本 Austin 以来，到 2014 年 10 月 发布 Juno 版本，已经经历了 10 个主要版本。基本稳定为每年 4 月和 10 月各发布一次大的版本更新。
网络功能实现是自第二个版本，即 Bexar 版本引入，最初作为 Nova 项目的一个功能 Nova-Network，仅支持所有用户共享一个底层网络（即所谓的 Flat 网络），后面自 2012 年 9 月发布的 Folsom 版本开始，将网络功能剥离出来，作为一个新的 Quantum 项目。2013 年 10 月发布的 Havana 版本中，项目改名为 Neutron。最新的 2014 年 10 月发布的 Juno 版本中，更引入了分布式路由（DVR）机制，并停止对于 Nova-Network 的支持。
各个关键版本的更新情况如下：
- Bexar 版本：
- 引入 Nova-Network
- Cactus 版本：
- IPv6 支持
- Diablo 版本：
- FlatDHCP 网络下的 HA
- Essex 版本：
- 网络功能数据模型开始从 Nova 中剥离，为独立项目做准备
- Folsom 版本：
- 正式从 Nova 中剥离，成为新的独立项目 Quantum
- 多租户隔离的支持
- 插件式结构支持多种网络后端技术，包括 Open vSwitch、Cisco、Linux Bridge、Nicira NVP、Ryu、NEC
- 支持 IP 地址的 Overlapping
- 支持 provider networks
- 支持基本的 L3 转发、SNAT、Floating IP
- Grizzly 版本：
- 多网络节点支持，提高可靠性
- 安全组
- 支持 LBaaS
- Havana 版本：
- 项目名称从 Quantum 改名为 Neutron
- 多种物理网络（Linux Bridge，Hyper-V，OVS）类型同时支持
- 引入 Fwaas、VPNaas
- 引入 ML2 支持多种类型二层网络实现
- IceHouse 版本：
- 一些新的插件
- 新的 LBaaS 驱动
- Juno 版本：
- 初步支持分布式路由（DVR）机制
- 完整的 IPv6 支持
- L3 agent 的 HA 支持
- 一些新的厂商的功能插件
从上面的过程可以可以看出，网络功能从 Folsom 版本开始引进，经历了 Folsom、Grizzly、Havana、IceHouse 四个版本才形成了比较稳定的集中式网络模型。自最新的 Juno 版本开始，才开始采用分布式路由模型。
现状
作为云计算平台的基础之一，网络服务的实现无疑是最能体现技术实力之处。无论是功能全面与否、性能高低、稳定性，每一项想做到满足生产环境的众多要求，都不是那么容易的。这也是现在很多围绕 OpenStack 的创业公司立足之根本。
OpenStack 在宣传上，一直明确表明自身的网络是完全按照软件定义网络（SDN）的理念来设计的。实际上，即使是从网络已经正式成为独立项目的 Folsom 版本开始看，这种说法也是不准确的。这个不明确的设计理念也是目前 OpenStack 在网络项目上收到大量抱怨的重要原因之一。
我们知道，SDN 有几个特点，最基础的一点是以松耦合的方式来处理好控制平面与数据平面的关系。
OpenStack 在设计上的确做到了控制平面与数据平面的分离，所有的数据都存放在数据库，所有的 agent 监听来自 Neutron-Server 的消息，根据这些消息来执行本地的操作。从这个简单的模型上看，Neutron 确实采用了 SDN 的模型。
但是将控制平面与数据平面分离，这仅仅是漫漫长途的第一步。后面的如何设计数据平面，以及如何设计和实现控制平面，才是最为核心的地方。
目前，OpenStack 在这两点上是怎么实现的呢？
2009 年诞生的 OpenvSwitch 项目，提供了足够支持生产环境应用的虚拟交换机实现，可以无缝替换掉 Linux 自身的 bridge，并且还支持一系列额外的功能。看起来，这是个不错的项目。于是，在最初几个版本中，网络就同时支持了 Linux Bridge 和 OpenvSwitch。但是很可惜的是，从一开始，大家在使用 OpenvSwitch 的时候，仅仅是当作一个 Linux Bridge 替代品，在设计新的功能的时候，也局限于 Linux Bridge 所支持的功能。这导致理论上可以充当任意转发组件的 OpenvSwitch，在今天的 Neutron 项目中，大部分时候只是作为一个二层交换机在使用。
那么， 更为重要的控制平面呢？很遗憾，在这点 OpenStack 上的表现差强人意。虽不至于说存在技术漏洞，但至少控制平面缺乏统一的规划，以现代众多控制平面的实现角度去看，只能说是一堆功能放在了一起。为了解决一个部分功能，先用已有技术解决掉，而不管其它功能的实现。这也导致经常出现不同功能模块的冲突。分布式路由机制在 SDN 中是个很自然的事情，但现有的实现先后用了固定的地址映射、ARP 代理、多级的转发表、隧道、L2 Population……并不是说不能用这些技术，但是实现的复杂与紧耦合将给未来的扩展带来更多的困难。并且同时启用路由跟高可靠性、多类型服务链等等功能，现有的设计很难在不提高复杂度的前提下实现。
可能做网络研发出身的人比较难理解为何要这样设计。实际上，换个角度，从 Linux 系统自身管理的来看，这样的设计是有其合理之处的。在没有 SDN 的年代，用 Linux 自身做路由器或防火墙是很常见的事情，通过 IPtables、Linux Bridge 进行各种配置，总能满足局域网内的各种需求。然而，到了云时代，一台物理机动不动就上数十台虚拟机，甚至现在几百成千个的容器，同时是多租户的、有计费需求的、对安全可靠性需求很高的……这里面很多的场景，是之前简单应用 Linux 做服务器或网关时候所难以想象的。即使通过各种技术手段勉强解决了基本的需求，也只能造成今天这样复杂的局面。也可以想象，为何将网络接口接到交换机上这样的操作，在 OpenStack 里面是由 Nova 计算服务来负责的。
在这里也稍微感叹下，如果 OpenStack 当年没有 NASA 项目的代码基础、如果没有选择“生命苦短，我选 Python” 的 Python 语言开发，可能到今天的情况会更加不能让人满意。
当然，使用 OpenStack 除了上面的模式，还有另外一种用法：仅把 Neutron 作为一个框架，让后端的各种插件自己来实现各种网络的服务。这种情况下无疑对于现有代码的依赖最小，也无疑最为广大有自己成熟网络解决方案的厂商所推崇。但是这样的模式，肯定也不是社区能接受的情况。毕竟，仅作为一个壳子转发下各种调用，这失去了作为一个成熟云平台开源项目的意义。
未来
虽然指出了网络项目在设计上的诸多问题，笔者对于 OpenStack 仍然是推崇的。并非出于盲目喜爱开源项目的原因，更多的，自 Linux 项目后，这些年很难见到这么多业界巨头和开源届的紧密合作，一起进行一项解决实际需求的项目。
实际上，思考 Linux 项目之所以能成功的原因，很重要的一点，是 Linus 本人。并非只是因为他在操作系统内核方面的技术境界，不可缺少的一点是 Linus 本人是比较“偏执”的，他认定的事情就轻易不会改变。同时，在很长一段时间里 Linux 系统内核的维护只是由 Linus 说了算。这或许能给今天的 OpenStack 社区一些启发。OpenStack 已经成功了，再宣传赞助基金之巨、参与人数之多其实意义没那么大了。一个真正透彻理解云计算需求和技术的小团队，往往胜过大量自觉或不自觉站在各种立场上的参与者。
从目前的情况推测，在很长一段时间内，网络项目还将沿着现在的路子走下去，一方面是在分布式模型下的新的网络功能实现，以及解决与已有功能的冲突；另一方面仍然是各个厂商以插件的形式支持自己的网络方案。这两种方式发生冲突是迟早的事情，只是希望那个时候 OpenStack 中的网络已经选择了更为高效和可扩展的框架，可以真正地实现“任意替换”的软件定义网络。
附：OpenStack 发布历史（摘自官方 wiki）
Series Status Releases Date Kilo Under development Due Apr 30, 2015 Juno Current stable release, security-supported 2014.2 Oct 16, 2014 Icehouse Security-supported 2014.1 Apr 17, 2014 Havana EOL 2013.2 Oct 17, 2013 Grizzly EOL 2013.1 Apr 4, 2013 Folsom EOL 2012.2 Sep 27, 2012 Essex EOL 2012.1 Apr 5, 2012 Diablo EOL 2011.3 Sep 22, 2011 Cactus Deprecated 2011.2 Apr 15, 2011 Bexar Deprecated 2011.1 Feb 3, 2011 Austin Deprecated 2010.1 Oct 21, 2010
恩 控制平面还是很弱。
ReplyDelete