SDN & OpenStack 漫谈（上）

首先，这片文章初衷是为了自我总结，我不会从感情上偏袒其中某个解决方案，但我确实有自己的 Preference 和对未来技术发展的看法。

从真正开始参与 Neutron 开发，已经有近 2 年的时间，起初的半年内（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 的 SDN 方案，到底该如何发展？当前的情况是，不停地修 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，云就更加虚无缥缈了。

作者简介

马力，海云捷迅（AWcloud）架构师，网络专家，2014 年初加入海云捷迅，专注于大规模云计算架构、数据中心基础架构、SDN 和 OpenStack 方向，OpenStack Neutron 社区活跃贡献者。Email： mali@awcloud.com