本周社区的注意力都在 Austin Summit 上，于是我们特别推出 Ausin Summit 特别刊，专门介绍 Austin Summit 上精选的 10 篇网络相关的 Presentation分享给大家。

1、Practical OVN Architecture, Deployment, and Scale of OpenStack

评分：★★★★☆

简介：开头科普了一下 OVN 的架构，一些做的不错的地方，然后着重介绍了这个 Release Cycle 中社区对 Scale 的进展和测试，以及其他一些目标。对 OVN 感兴趣的同学应该看一看。

评论：标题虽叫 Practical，但遗憾的是实践的内容并不多，提到了社区做的 Scale 测试，主要是利用 Sandbox 在 20 台物理机上做 2000 个 Hypyervisor 的控制平面模拟，IBM 在实际物理环境中部署过 90 个 Hypervisor 的 Scale，下一步要测试 300 台和 700 台的规模。

关于最近的进展，Scale 上有一定提升，例如 ovsdb-nb 和 ovsdb-sb 分拆到两个进程等，但遗憾的是比较受人关注的 ovsdb 的多进程还在开发中，原生 NAT、摆脱 MQ 等一些关键 Feature 也还没有做完。部署上已经支持了 Puppet OpenStack，同时社区对 Rolling Upgrades 也比较重视，这方面做的也不错。下一步的目标主要还是 OVSDB 的 HA（关键 Feature）、L3 Gateway 和 NAT 的支持（关键 Feature）、Native 的 DHCP、MetaData 等等，还有一段路要走啊。

OVN 刚推出很多人看好，原因最主要是强大的社区，其次刚开始给出的设计文档也不错，遗憾的是刚拿出来的版本距离长期设计目标就差的很远（OVSDB 的 HA 问题，甚至目前还是单进程的！大量的非分布式实现等等），所以就让很多人忧虑 OVN 是不是太晚了。一年多过去了，OVN 社区确实做出了很多努力，但遗憾的是前有 DragonFlow，后有 OpenDaylight OVSDB Netvirt 各种竞争，而且前者发展时间长、已有部署案例，后者在 HA、各种功能（SFC、VxLAN Gateway 等）也有所擅长，而且两者对如何解决数据库/资源同步问题都提出了自己的方案（versioned object、async sync）等，而 ovn 社区目前还没有考虑过这个问题，只能说留给 ovn 的时间已经不多了啊。

2、OpenStack and Opendaylight The Current Status and Future Direction

评分：★★★★☆

简介：开头科普了一下 OpenDaylight 的架构，然后介绍了在 OS M 版和 ODL Beryllium 版上的进展，特别是 V2 版 Driver 的情况，值得一看。

评论：V2 Driver 是一个关键性但复杂的事情，主要是增强了 HA 和 Scalability，这也得益于 OPNFV 的不断测试。其中的关键问题之一是数据库的不同步。做过类似 SDN 与 OpenStack 对接的开发者都知道，因为事涉两个系统，两个数据库，所以保持数据一致性是一个很麻烦但有很重要的问题，一旦处理不好，轻则状态不一致，重则大量脏数据充斥两个系统还无法轻易删除，最终无法维护。ODL 选择了一个相对简单一些的方案，就是将一个 Sync 操作拆开，拆一部分为独立的循环，这个思路可能是和以前的 Neutron agent 学的？

我们可以看到 API 返回过程实际是没变的，仍然是直接写数据库然后就返回，但此时状态时 Pending 的，由另一个独立线程周期去取 Pending 的数据，然后交给 ODL，这样来保证 API 操作的即时性和状态的一致性。

轻量测试框架看起来对用户不会有很大的影响，但是对开发真会方便很多，跑和 OpenStack 的集成测试不需要专门跑 ODL 了，简化很多。支持了基于 Port binding 的 OVS DPDK 集成（这样你可以混布 DPDK 和 非 DPDK 了！），100% 通过 Tempest 测试。在新版的 ODL 上，HA、稳定性、各种 Feature 也增强很多，可以认为 ODL 和 OpenStack 集成已经很靠谱了。

在下一个版本中，一方面是 v2 的继续增强，一方面是 SFC、FD.io、BGPVPN、L2GW 等这些的增强。按照 FD.io 的文档，FD.io 社区的计划也是通过 ODL 与 OpenStack 集成，按照目前的资料 FD.io 的性能特别是多流性能上就超出 OVS DPDK 一大截，值得期待。SFC 有其他 Session 做介绍，这里就不多说了。最后做一点科普，OpenDaylight 可以作为纯软的 OpenStack SDN 后端，具体的模块式 netvirt，也是以 OVSDB 来控制 OVS 完成网络功能，目前功能的完善程度还是比较高的。

3、Dragonflow – Neutron Done the SDN Way

评分：★★★★★

简介：开头科普了 DragonFlow 的架构和意义，然后介绍了最新的进展，其中重点是 Plugable DB （你将可以愉快的使用 ETCD、RamCloud、Redis 等作为分布式的数据库后端）、Plugable 消息后端（你可以愉快的使用 0MQ）、分布式的 DNAT、DHCP 和 OVS 实现的安全组均已完成！

评论：在去年的 Vancouver Summit 会后总结上，笔者就向国内同僚介绍过 DragonFlow 这个生机勃勃架构的项目，主要 Contributor 中 Gal 和 Eran 都是很有创造力的人，最近随着国内的马力的加入让这个“小社区”更加充满活力，从他们的 Feature 介绍中也能看出里其发展之强。演讲着重介绍了关于数据库一致性的问题解决，和 ODL 重点讨论的那个事情是一样的，区别是二者的方法，DragonFlow 目前采用的是基于锁实现，类似于两步提交，但计划修改成基于版本的对象控制，这个计划其实和 ODL 的实现也是有类似的，但是这里不用状态这个字段，而是用版本，确实看起来更优雅但实现难度还是比较高的。

OpenStack 与 SDN 集成的两大痛点，一个消息问题，一个数据库问题，不同的社区给出了不同的解决方案（弃用 MQ 还是采用分布式 MQ？基于 CAS 的比较还是基于状态的异步处理？），很让人拭目以待。此外 DragonFlow 还公布了他们在 Scale 上的路线图，随着 0MQ 的引入，他们把理论的 Scale 已经提高到 4000 节点，但这还是不是终点，目前的目标是 10000 台节点！

DargonFlow 在更新速度上、架构上（他们在架构上在不断进化）都绝对不输目前 Neutron 几个其他 SDN 方案，唯一遗憾的是社区和声音都小了些，希望未来能有更多的慧眼识珠之人参与进来。

4、Deploying Neutron Provider Networking on Top of a L3 Provider Network Using BGP-EVPN

评分：★★★★☆

简介：这是一个 Walmart 出品的其网络结构设计 Case Study，主要技术是 MPBGP EVPN，对大型的 OpenStack 网络设计（VxLAN 网络设计）还是很有价值的，演讲附有珍贵的实际性能数据。

评论：Walmart 首先谈了他们的痛点：
一、目前数据中心建设过程太过漫长，需要6-12个月
二、流程长、重复工作多、缺乏进度可视、相互依赖
三、传统网络架构需要很多网络工程师维护，应用喜欢二层而网络工程师喜欢三层，网络和安全由不同的人负责
据此，Walmart 希望一个支持裸机和虚机、支持大二层、安全、可靠、无厂商锁定的网络方案。最终他们选择MPBGP EVPN VxLan组网。

MPBGP EVPN 在网络界已经不是新技术了，但和 OpenStack 结合其实不多，一来设备支持不那么丰富，二来社区有L2 POP+ARP Responder的解决方案（当然也有 MPBGP EVPN 的软件实现方案，BaGPipe!），此外 OpenContrail 作为开源软件 SDN 界的技术担当也一直支持，所以这个话题在 OpenStack 社区圈内讨论的不多，但是如果你想真的解决 VxLan 的广播问题，或者想扩展 VxLan 到 DCI，那 MPBGP EVPN 确实值得考虑。此外通过设备解决分布式路由？Ancast Gateway（简单的说就是分布式的 VRF）。网络架构整体是和 Spain-leaf 没什么区别，但重要的是 VxLan de/encap 是在 ToR 上做的。

最后 Walmart 给出了其性能测试数据，基于 Dell 和 Cisco 的硬件。有意思的是他们还有一个测试项叫 AppMix，混合了各种应用来模拟真实情况。另外还有 Walmart 给出的小包性能一般，瓶颈应该在软件或虚拟机上，不应该是 ToR 的问题。

对了，笔者在会上问了 Walmart 使用的控制器或自动换软件是什么，答案是目前在用 VTS，将来计划迁移到 Ansible 上，网络资源全部是预配置的。

5、Skydive, Real-Time Network Topology and Protocol Analyzer

评分：★★★★☆

简介：如上所述，我们缺乏一个好用的开源 Overlay 网络监控、运维工具，于是 RedHat 的开发者开发了 Skydive 这个工具，功能简洁、WebUI酷炫，做了一个 Demo，大概就是这样。
评论：如果能真的解决 Overlay 网络的监控运维那真是所有 OpenStack Overlay 网络使用者的大福音，目前 OVS 组网运维基本靠手，很麻烦，传统的监控工具如 Zabbix 完全不适用，靠谱的只有额外购买工具（例如 BigSwitch 的解决方案、Gigamon 的解决方案），Skydive 就是来填补这一空白的，自动扫描 Linux 网络和 OVS，自动展现拓扑还可以抓包，通过整合 ElasticSearch，你还可以比较清楚的看到报文在哪里丢掉了：

这个项目笔者很久以前就关注过，最重要的的问题是，目前没有做过 Performance 和 Scale 的测试，要知道大型的 OpenStack 云目前已经有成百上千个 Namespace 和 Port，包量可能有上兆的 PPS，节点数量可能也是成百上千，如果性能和 Scale 达不到的话，那就成为小实验室的玩具了。

6、Neutron DSCP Policing your Network

评分：★★★★☆

简介：Neutron QoS 的最新进展、实现、和实现上遇到的挑战与解决方案。
评论：Neutron QoS 进展不快是事实，但是令人欣慰的是毕竟一直还有进展。这场 Session 介绍了一些人比较关心的 QoS 中 DSCP 的功能。先介绍了 DSCP 是什么，然后介绍了在 OpenStack 中如何使用，如何在 OVS 中被实现。遇到的挑战主要有几个，一个是下面介绍的为了解决 L2 Agent 重启的问题，每个 Flow 增加了 cookie，QoS 需要保证其规则在重启时不被刷掉，解决方案时 Agent Extension 获得自己的 cookie 值，自己维护。另一个是 Feature 的隔离。目前我们在 L2 Agent 上可能实现了很多功能，例如安全组、Vlan、QoS，都通过 OVS Flow 实现，那么如何保障这些 Flow 可以正常同时工作，或者其中一些功能关闭时保证开启的功能正常工作？解决方案是 table 0 会给 packet 的 metadata field 打 0，然后送到 feature table 上，feature table 处理完把相关的 metadata field 打非 0，然后送回，有点像一个小 SFC 似的。

最后一个问题是 Server、Agent 的 RPC 版本不同步的问题，解决方案是后面会提到的 OVO。

下一步的 Roadmap 是实现 ECN、最小带宽保障、进流量限制等等。

7、Tired of Iptables Based Security Groups? Here s How to Gain Trem

评分：★★★★☆

简介：介绍了新的 OVS 实现的安全组。
评论：安全组其实是个比较简单的基本功能，之前基于 iptables 实现，问题是虚拟网络拓扑比较复杂，性能一般。另外就是功能也有限，这个演讲提出 Firewall 发展的三级，第一级是实现基本的 ACL、第二级是实现状态防火墙、第三级是实现完整的 OSI 防火墙，可以做 DPI。那么防火墙能否用 OVS 实现呢？第一级很好做，第二级的关键问题是实现状态。如何实现状态？一种思路是用 openflow 中的 learn 动作，记录送出去的流量，效果不错，但流表不好看：

另一个思路是通过 conntrack 记录状态，在 OVS 流表中增加 cs_state 字段，性能有提升，但远不如 learn 的实现：

大家都比较郁闷 conntrack 实现的性能提升有限，所以下一步会将 conntrack 移到用户态提升性能，以及提升测试和易用性等等工作。

8、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。

9、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 提出来（见 Neutron 社区每周记），敌人虎视眈眈，不能掉以轻心啊！

10、Service Function Chaining Technology Analysis and Perspective

评分：★★★★★

简介：对 SFC 的实现方法、现状和未来做了详细的阐述，做了一个 Demo 演示了目前通过 Tacker 可以做到的程度。
评论：对 SFC 还一知半解的同学有福了，这个 Presentation 详细介绍了 SFC 的实现方法，考虑到 Demo 演示的是 NSH 的方法，这里放一下 NSH 的实现原理以及与 Tacker、ODL 的集成原理：

 

可以看到现在的设计还有些混杂，所以最终还会有所变化，详见视频。最后简单描述了所有相关项目，为科普再一次做出巨大贡献。
介绍高屋建瓴、Demo 具体实际，好评。