Neutron升级、SFC实现、ML2架构丨8大最热门OpenStack网络开发话题讨论

今天有关奥斯汀OpenStack Summit网络技术主题的演讲评论关注开发主题。这是UnitedStack有云SDN网络部PTL王为在奥斯汀峰会期间对36个Session进行介绍和评论的第三部分。

说明：这些网络技术讲座的观影指南涉及架构、功能与工具、开发与其他四大领域。我们将分主题系列发布，希望帮助国内的开发者、架构师和用户更好地了解OpenStack在SDN网络领域的最新发展。本文所介绍的相关讲座在 YouTube 均有完整视频（详见：https://www.youtube.com/user/OpenStackFoundation/videos，在 Youtube 上搜索对应名称即可）。

1. Understanding ML2 Port Binding

评分：★★★★

简介：这是一个 Cisco 的开发人员介绍 ML2 Port Binding 的专业演讲，简单介绍了 ML2 的架构以及 Port Binding 的作用、开发原理、需要考虑的因素和 case 等，对开发者来说是一个不错学习材料。 

评论： 有人说拿 Neutron 做一个 API Server，网络实现走外边的控制器或其他方案那么 Neutron 的任务是不是就很轻，就简单了呢，实际不是这样的。如果只是适配 OVS 一个实现，那自然很简单，但随着大家的需求增多，要能支持 SR-IOV、要支持 DVR、要支持 Hierarchical Port Binding 等，对 Neutron 提出了很高的资源抽象要求，所以现在你能看到 port 上如今有vif_type、vnic_type、vif_details等属性：

如果你想安全的完成 Neutron 与其他系统的对接，或者 Neutron 的一个 L2 Agent 的实现，你必须很清楚的了解 Nova 的 VIF 如何产生，如何通知到 Neutron，Neutron 如何为其配置流表、修改属性等过程。

很多人对 Hierarchical Port Binding 这一功能不大了解，我在这里简单介绍一下，Kilo 版刚出来时，很多人说这个功能带来了 Neutron 对 ToR 交换机的支持，这个说法是欠妥的，Neutron 所能带来的其实是一个逻辑的抽象和代码的可能性。我们知道过去的 Port Binding 里，关键是 L2 Agent 会随机分配一个“本地 Vlan”来解决同一宿主机下虚拟机间网络的隔离问题，然后在统一转成 VxLan 送出去。

那么如果 VxLan 在 ToR 上实现怎么办呢？过去我们在 Server 测是看不到本地 Vlan 这个数据的，现在随着 Hierarchical Port Binding，多了一个ml2_port_binding_levels的表，配合ml2_network_segments，我们可以保存 Port 在一个 Host 上多级的绑定关系，从而配置 ToR 的 Mechanism Driver 就可以获得这些信息，正确的配置 ToR。

2. Deep Dive into Neutron Upgrade Story

评分：★★★★☆

简介：介绍了 Neutron 升级中控制平面和转发平面目前的挑战和应对。 

评论： Neutron 升级是一个挺揪心的问题。因为目前 Neutron 的参考实现导致 Neutron 和转发平面紧紧关联，特别对于一个私有云，控制平面的短暂不可用是还可以接受的，但是如果转发平面发生问题，那简直是 horrible。 

这个演讲先介绍了整体的一个升级过程：代码升级、数据库升级、Neutron Server 升级、网络节点的 L2、L3、DHCP 升级、计算节点的 L2、L3（DVR）升级。

具体的来说，Neutron Server 是无状态高可用的，但因为数据库升级的问题，所以必须得有一段时间关掉 Neutron Server，目前第一个解决措施是将 expand 和 conract 两类数据库操作分开，前者不会影响 Neutron Server 在旧的模式下运行，后者会，所以前者可以提前运行而不干扰 Neutron Server。

那么后者呢，是否无解了呢？不是的，关键是引入 oslo.versionedobject，演讲者没有说太多 OVO 如何实现把数据 lazy migrate 到数据库，但是 it works，不需要太担心…… 另外一个 OVO 解决的问题是 RPC 的版本问题，这样你在写代码的时候就不需要额外担心 RPC 的版本问题了（以往 Neutron Server 中有一些比较丑陋的探测 RPC 版本的代码，比如尝试一个调用看看会不会由 exception，或者后来尝试 hardcode 一个版本号之类的）。OVO 目前还有很的路要走，而且需要所有开发者都按新的开发守则撰写代码，路漫漫啊。

如果涉及到数据库 Schema 的 Drop 的话，简单的说如果要保证 API 的可用的话需要两次升级过程才能将 Schema drop 掉。具体见 Presentation 的演示。

关于数据平面，目前在 L2 Agent 上做了很多，例如对每个 flow 做一个带 UUID 的 cookie，那么重启时，我就可以先生成一把，再把旧的根据 cookie 删除了。如果你对 cookie 没印象的话，我来帮你一把：

然而这个只涉及 br-tun，vlan 网络呢？很遗憾，目前还没解决…… 此外社区为了保障之后的重启问题，还增加了 Grenade CI、Partial CI、DVR Testing 等。 

总结下来，我们做了很多工作，你说做完了吗？其实没有，Vlan 网络、L3 等还没解决完，而且即使是 L2 Agent，也时常有 Patch 提出来（具体参见UnitedStack有云微信公众号定期发布的Neutron 社区每周记），敌人虎视眈眈，不能掉以轻心啊！

3. Service Function Chaining Technology Analysis and Perspective

评分：★★★★★

简介：对 SFC 的实现方法、现状和未来做了详细的阐述，做了一个 Demo 演示了目前通过 Tacker 可以做到的程度。 

评论： 对 SFC 还一知半解的同学有福了，这个 Presentation 详细介绍了 SFC 的实现方法，考虑到 Demo 演示的是 NSH 的方法，这里放一下 NSH 的实现原理以及与 Tacker、ODL 的集成原理：

可以看到现在的设计还有些混杂，所以最终还会有所变化，详见视频。最后简单描述了所有相关项目，为科普再一次做出巨大贡献。 

介绍高屋建瓴、Demo 具体实际，好评。

4. Case Study Neutron IPAM APIs and External IPAM Integration

评分：★★★☆

简介：IPAM 算是 L 版的新功能，但是怎么用很多人都没概念，这个 Presentation 介绍了 IPAM 的意义、工作原理和Use case。 

评论： 实际上只有前 10 分钟介绍的是 IPAM 本身，有了 IPAM 之后，分配 IP 将可以由外部系统控制：

后面介绍的其实如何与 Romana，一个纯三层网络实现相集成，以及如何在上面再搞一个 Kubernets。

5. Neutron Address Scopes

评分：★★★☆

简介：介绍了 Address Scopes 的功能、作用和实现原理。 

评论： Address Scopes 主要作用会在 IPv6（IPv6 没有 NAT 这个东西）、L2/L3 VPN 中，目前的应用场景其实很有限，大概也就划分“路由域”之类的。

实现原理主要是基于 IPTables，之后如果不在一个路由域，即使在同一个路由器下流量与会被 Block：

总结：中规中矩，看头不大。

6. Evolving Virtual Networking with IO Visor

评分：★★★★

简介：一个 BoF 会议，所以没有视频资料。介绍了 IO Visor 能起到的作用、Linux 网络目前遇到的挑战等。 

评论： IO Visor 是一个笔者也比较关心的项目，Linux 网络最近收到很大的挑战，一方面是高速网络的兴起，如今万兆网络在数据中心已是标配，20G、40G 也在不断发展，更甚至有 100G 的以太网；另一方面是 NFV、Overlay 的发展，服务器上再跑大量的网络基础设施，这对性能、监控等都提出了巨大的挑战。

解决方法之一是，放弃传统 Linux 网络协议栈，另起炉灶，例如 DPDK。Linux 内核的网络实现不够高效？基于中断的数据包收取不够迅速？那就另在用户态实现一套吧。然而所带来的问题就是 Linux Kernel 自带相当丰富、良好的技术生态圈，上面有 socket 这么好用的接口，上面有 netfilter、tc 这么好用的框架，上面有 systemtap、perf 这么好用的工具，你真的要重来一遍吗？

如果不放弃内核的话，如何改造？Linux 3.15 开始引入 eBPF，其特点是 JIT、指令集丰富。你可以在用户态愉快的写代码到内核执行，既完成了高效（无需用户态、内核态拷贝）又做到内核安全（你可以理解为在虚拟机执行，不会轻易造成 Kernel panic）。

目前大家拿来主要做的事情在 monitor 和 trace 上，IOVisor 的一个项目叫 bcc，主要作用是帮助开发者减少 eBPF 本身的一些 dirty work 和复杂性，提供了现成的工具链和脚本，甚至提供了 Python SDK！你可以用 Python 去获取内核 softirq、TCP 连接、连接延时等等内核数据。将一些工具组合在一起，你可做出来一个很好看的 Overlay 网络展现工具（bcc 的一个 example）：

目前 eBPF 只被 PLUMgrid 的商业产品使用，PLUMgrid 用其实现了完整的 PLUMgrid 网络功能。

eBPF 前景如何呢？我是比较看好的，因为目前确实内核缺乏高性能而安全的网络工具链，eBPF 带来这一可能性，特别是现在严重缺乏 Overlay 层面的监控、trace 工具，前面介绍过 skydive 确实不错，但是为了发现拓扑需要用那么多工具，做 flow 分析的话 libpcap 性能低下而 sflow 不准确？或许 eBPF 将拯救世界。 

7. MidoNet Scalability Testing with Neutron and Open Source Tools

评分：★★★

简介：介绍了 Midonet 如何做测试和发布，特别是 Scale 测试。 

评论： MidoNet 的测试过程大概是这样的，主要工具是 ovs-sandbox、tempest、rally 这些：

比较重要的是 Rally 只测试了 API 层面，怎么保证做 Scale 测试时 Agent 正常处理了呢？主要靠日志和其他监控。

8. Mapping Real Networks to Physical Networks, Segments, and Routed Networks

评分：★★★☆

简介：介绍了 Neutron 里一些网路概念，比如 Segments、Network、Phynets、Routed Work。 

评论： 基本可以用这个图解释所有内容：

有很大篇幅介绍 Routed Networks，有兴趣的话可以看下。

编者注：本文作者为UnitedStack有云SDN网络部PTL王为。有关此次奥斯汀OpenStack Summit各个技术主题的演讲视频，可以在YouTube上完整观看。