首先，这篇文章的初衷是自我总结。我不会在感情上偏中一个解决方案，但我确实有自己的想法Preference以及对未来技术发展的看法。
真正开始参与Neutron开发已经近两年了，前半年（Icehouse周期)，一直在修复，Neutron在生产环境中发现的各种生产环境Bug，处理一些核心问题需要时间，甚至没有很好的解决方案。
1. DB模块的稳定性和性能
众所周知，OpenStack所有数据持久化(除了Ceilometer外)，全部依靠官方推荐MySQL（包括Percorna、MariaDB等)，但是开源型数据库引擎的扩展性一直是个问题，从生产环境监测中很容易看出，Neutron读写数据库的压力在于OpenStack在所有组件中，仅次于Nova（Keystone内存数据库可以缓解75%以上的压力)。一方面，数据库引擎单点或HA扩展性问题无法解决，当Neutron-server当过程越来越多时，就会出现，尽管有Galera但其事务处理性能一直是集群方案的瓶颈，乐观的锁定机制也会导致API失败（Nova有db-retry，Neutron当时还没有)。第二个方面是SQLAlchemy框架本身的限制，Python社区一直是一个纯开源的松耦合社区，许多企业级应用所必需的框架没有得到企业级的维护，其中首当其冲的是SQLAlchemy，这个Python世界排名第一ORM解决方案，并不是一个优秀的性能出众的ORM方案(至少和我在一起Java用于世界Hibernate，各方面都不止一次)，记住它在0.90-0.每个版本的99或多或少都存在Bug而且它的ORM引擎对SQL本身的优化也不是特别到位。第三个方面是Neutron社区一直被误用SQLAlchemy在事务处理过程中使用RPC导致不必要的事务内协程切换，间接增加不必要的数据库引擎长期维护事务的压力，往往导致规模环境下的事务Timeout、Deadlock等情况。这些情况集中在ML2和L3RouterPlugin插件的DB模块，每个Release都有大量的Race Condition曝光，然后就是Case by Case尽管这种情况是自从修复以来的Icehouse曝光多达10-20个相同的问题后，慢慢随着Juno、Kilo大部分问题已经修复(我也参与了讨论和修复)Bug），然而，由于初始设计造成的这种情况，在后期，需要200%-300%的时间来分析和修复，让人感到羞愧。
2. RPC系统的稳定性和性能
Neutron基于控制平面RPC基于实现的官方推荐AMQP0.9的RabbitMQ但在大规模环境下，RabbitMQ虽然存在，但集群的扩展也成为障碍Kernel调优和Ram Node-Disk Node优化方案，但一方面RabbitMQ本身对于Devops是黑盒，其次，当时官方指南并不清楚(期官方也在不断完善)Best Practice等文档)。为了处理当时的生产环境，切换到基于ZeroMQ的分布式消息队列，在Neutron更换项目RabbitMQ方案，确实有奇效。
关于这个方案，在Vancouver在峰会上，我有一个演讲，详细描述了一个新的分布式消息队列系统。目前，除了官方推荐外，社区还可以小规模推荐Region稳定运行的RabbitMQ，oslo.messaging团队正在发展三个更有前途的希望，在大规模环境中稳定运行RPC驱动，分别是ZeroMQ、Kafka、AMQP1.0(记是基于的Apache Qpid dispatch router实现的）。
3. Eventlet本身
Eventlet是OpenStack依赖的greenthread管理库，它的优点是开发模型简单，能有效重用iowait时的计算资源，缺点是缺少细粒度的调度控制。在OpenStack世界里，需要显式调度的时候，需要使用eventlet.sleep。
但是基于iowait的调度粒度太粗。某些情况下，我确实需要在iowait下禁止当前协程切换呢？还有些情况下，我需要基于优先级的调度呢？在某些特殊情况下，我需要抢占式调度呢？对于大型系统来说，开发模型简单易学，隐藏了大量细节，并不是好事。
4. 集群资源协调问题
（1）Scheduler
在Neutron中，存在一个并不是特别起眼的模块，Scheduler，这个模块负责把Neutron core Resource和Agent进行绑定和解绑，也就是把资源调度到不同的Agent上去配置。这个Scheduler目前常用的是DHCP、L3、LB（负载均衡）。这个模块存在一个较大的缺陷，就是每个调度器都是独立运行，其中没有任何资源协调，导致在生产环境下，我即便是有针对性地实现了更细粒度调度算法，也无法使得不同的调度器间进行交互，实现更高层次的资源统一调度（比如，把一组资源统一调度到同一台Host，当前无法实现，在写DB时会出现Race Condition）。那个时候，我自己基于Redis开发了一个分布式锁管理器，在各个调度器之间实现了统一的调度控制。
（2）AgentGroup
Neutron目前还没有AgentGroup的概念，没有办法实现统一的集群管理和可靠的健康检查机制（RPC+DB，只能算Demo）。
基于以上两个问题，都是由于Neutron项目内不存在Cluster Coordination机制导致（虽然我实现了一个，但并不通用，当时还没有Tooz），这个机制目前已经有了一个BP（通过Tooz实现，但是只有我觉得可以+1，其他Reviewer并没有反馈），而且其实Nova社区也有了ServiceGroup的参考实现，但是Neutron社区方面却一直Delay，不知道是因为Core Team把握不准，还是觉得这个功能比较复杂，要放到M周期讨论。
5. Agent Loop、External Commands
Neutron中最常用的（User Survey调研占到75%的案例）是Openvswitch和Linuxbridge，其中的Agent框架都是基于Daemon-loop的轮询机制，这套机制在大规模生产环境下，基本不可用，因为一次轮询的时间太长，导致一些需要立即更新的端口配置延时到下一个轮询周期，对于任一端口配置错误都会导致full-sync，系统开销极大。另外，所有对于虚拟网络设备的配置都是通过Subprocess调用外部Command的方式，导致Host Kernel需要维护大量并发的Subprocess，带给Host Kernel很大的压力。幸好在Liberty周期里，已经有人在实现基于事件的Callback机制，并且我也联合另一个Neutron开发者向社区提出了使用Netlink Library Call代替Subprocess的技术方案，还在初期讨论过程中，但是从Icehouse到Liberty，确实够久的。
当然，除了处理Neutron的一系列事故外，我还在思考这么一个问题，就是Neutron的方案，到底该如何发展？当前的情况是，不停地修Bug，平均一个BP的引入会同时带来10+的Bugs（话说回来，DVR的引入带来了30+的Bugs，给HP和Review BP的人狠狠点赞）？OpenStack提供了一个广阔的开放的平台，定义了业界认可的API集合，但是，就如同存储技术需要Domain Knowledge，网络技术同样需要，当前Neutron除了其Plugin框架之外的实现，更多是Reference Design，而不是大规模生产环境下的专用系统。
在这个时候，也有思考过SDN和OpenStack的关系。
1. Neutron到底是不是实现了SDN？
这个问题不是我抛出的，而是去年就有很多云计算架构师和网络架构师，包括一些业界专家一起在QQ群里论战。其实这个问题，需要从两个角度去看。第一，从云计算技术的角度，Neutron实现了租户网络拓扑的自定义，确实是SDN思想的体现。第二，从网络技术的角度看，Neutron仅仅是实现了网络通路（保证网络是通的，汗），还没有针对流量的细粒度管控，职责也没有非常清晰地分离，与现实世界里大量专业的SDN系统所实现的网络功能相比，确实差了很远，所以要说Neutron是SDN的初级起步阶段也未尝不可，所有特别是很多业界的网络专家对Neutron的实现不屑一顾也情有可原。最新Neutron社区主导的项目，像Dragonflow、RouterVM、ML3，以及与外部SDN开源方案的互动更为频繁（OpenDayLight、OVN等），可以看出OpenStack也在朝好的方向努力。
2. SDN技术如何定位？
有网络的地方，就可以有SDN发挥的余地，在我眼里，SDN技术所能应用的领域，囊括了整个CT领域，从范围上讲，包含卫星网、全球互联网、骨干网、城域网、园区网、最后100M接入网，局域网；从传输介质上讲，包含双绞线、光纤（单模、多模）、同轴电缆、无线通信（微波、Wifi、2/3/4/5G移动网）所形成的各类网络；当然还包括IT领域的DCN（数据中心网络）、DCI（数据中心互联），NFV领域，以及在未来DT领域会大力发展的物联网、传感器网络等等。
云计算网络（比如OpenStack Neutron）环境仅仅是SDN众多北向应用中的一个，不需要谈到SDN必谈云。离开了云，SDN技术还是可以在其它领域发亮发光，反倒离开了SDN，云就更加虚无缥缈了。
本文转载自：http://www.infoq.com/cn/articles/sdn-openstack-part01