OpenStack 与 SDN：UnitedStack 在提升网络稳定性与实现高级网络功能融合方面的经验分享

在 2014 年底的一次 SDN 技术沙龙上，UnitedStack 资深网络开发工程师马啸对 OpenStack 的 SDN 实现情况进行了介绍。在当天的一次访谈中，马啸提到了OpenStack 社区当时的几个主要的优化方向，一个是用L2Population 优化广播报文，另一个是改善DVR（分布式路由器）的成熟度，还有一个是进行Service Chaining 等能够提供更为灵活的NFV 功能的技术。

两个月前，OpenStack 的大版本更新到Kilo ，网络方面对于LoadBalancer 和NFV 场景支持都做出了改进。具体到UnitedStack 这样的托管云和公有云运行环境，过去这几个月又有怎样的变化？生产环境中的OpenStack SDN 部署已经进展到怎样的程度，正在面临哪些挑战？InfoQ 中文站带着这些问题采访了马啸，以下是他的最新分享。

InfoQ：请 Zebra 先简单介绍一下你们组过去几个月做了什么，有哪些成果，以及面临哪些挑战？

Zebra：SDN 组在今年到目前为止的主要工作包括：

• 稳定性问题的解决（典型代表为 OVS 流表冲刷问题）
• 高级网络服务的开发（LoadBalancer、GRE 隧道、OpenVPN、IPSec VPN、HA Router）
• OVS 底层性能的优化

另外，最近我们这边比较关注网络的融入性这块，就是利用 ServiceVM 的架构提供网络高级服务的融入以及与厂商方案（Cisco ACI）的融入。

目前为止，UnitedStack 网络架构主要依然是社区的 VxLAN+VLAN 方案和底层的 OVS、Linux 协议栈，其他网络服务也都是类似社区的纯软实现。对于用 ServiceVM 融入厂商提供的高级网络服务这一块研究更加成熟之后，我们未来会融入更多的厂商方案。

网络的融入性是我们目前的主要工作，也是面临的主要挑战之一。此外，社区代码整合、Service Chain 也是我们当前的工作重点。

InfoQ：请描述一下你提到的 OVS 流表冲刷问题。这个问题表现为什么症状，在怎样的场景下出现？

Zebra：Neutron 中对于 OVS 的使用是通过 Neutron OVS Agent 来完成的。原始逻辑中 OVS Agent 重启的时候，会进行如下两步操作：

1. 初始化 OVS 的流表，主要指 VLan 网络用的 OVS Bridge 和 OVS 的 Tunnel Bridge（这样就产生了冲刷）
2. 重新从 Neutron Server 侧抓取 Port 的信息，并针对每个 Port 的 Network 分配 Vlan ID，下发对应的流表（这样就重新建立）

这个逻辑在 Port 数目较少的情况下，由于流表重建较快，不会被感知到；然而在大量 Port 存在的情况下，会导致业务的中断。

我们是由于在每次重启 OVS Agent 服务的时候，发现会出现用户业务中断而注意到的这个问题。

InfoQ：你们目前是用什么方式解决这个问题的？这种方式的好处是什么，还有哪些不足？

Zebra：根据 VxLAN 方案的特征和 Neutron 对 VxLAN 的实现，我们知道一个 Network 对应的节点的本地 VLAN 是不能重复的。

基本思路是，只要本地 VLAN 前后一致、Port 也一致，则对应的 OVS 流表就不需要重新初始化再重新建立。

OVS Agent 重启前后，Port 一般是一致的。同一个 VxLAN ID（Network）对应的 VLAN 是 OVS Agent 本地进行的分配，因此在 OVS Agent 重启的时候，我们只需要保持 VLAN 不变就可以了。

如何保持 VLAN 一致？我们在 OVS Agent 重启的时候，根据之前的 Port 的 VLAN ID（在 OVS DB 中），建立 Network 和 VLAN ID 的对应关系，对应的 Network 不再进行 VLAN 分配而使用重启前的 VLAN ID，即可不再需要重建流表。

其实 VLAN 本地分配，在各种 VPN 方案中是一种通用方式。在 SDN 的趋势下，有些实现的思路是在 SDN 控制器侧完成对应的节点的上 Network 的 VLAN 分配，但是如果这样改动，则与 Neutron 差别较大，显然不是好的改动方式。我们采用的这种 Agent 本地分配、保持 Agent 重启前后 VLAN 不变的思路，则无需对 Neutron 进行太大的改动。

关于稳定性问题我想再补充两个：

1、iptables 安全组规则的泄漏。我们知道 Neutron 安全组是一个虚拟机的 Port 对应下发 iptables 规则实现的，OVS Agent 存在一个 BUG，即在某种时序下 Port 删除了，安全组规则被残留下来；残留的规则过多的情况下，则会导致 iptables 规则下发变慢，而在 OVS Agent 的逻辑中，iptables 规则下发后，才会配置 Port 的 Vlan tag。最终的表现是：有时候，如果用户创建一个 network 并且立即创建一个属于该 network 的虚拟机则这个虚拟机可能不能通过 DHCP 立即获取到 IP 地址。这类问题隐藏的很深，只有长时间运行 OVS Agent 才会体现出来。

2、IPtables 在 L3 Agent 重启的时候，重刷 iptables 规则问题。我们知道，Neutrons 社区的原始路由和 NAT 是通过网络节点做的，由 L3 Agent 所管理。当 L3 Agent 重启时，代码在收到 router add 事件时，会做一次内存中存储的 iptables 规则和实际网络节点的 iptables 的规则的同步，而这个时间点，该 Agent 还没有将该路由的 NAT 规则写入到内存中，如果进行同步，自然导致 iptables 规则的冲刷，引发业务中断。这个问题和 ovs 流表问题属于同种类型。也是极难发现的隐藏 BUG。

从上述这三个问题可以看到，社区代码在稳定性的潜在风险集中在对时序问题的考虑不全，各个场景下的 sequence 图没画好。稳定性问题实际体现的是对社区代码的驾驭能力，没有长时间的运维、不认真阅读社区的代码（比如上述 OVS Agent 的代码）是不能查清楚的。

InfoQ：可否介绍一下你上面提到的 ServiceVM 架构？

Zebra：有关 ServiceVM 架构，可以查看这个 OpenStack Tacker 项目的文档。简单来说，Tacker 是用来管理提供高级服务的虚拟机，进行虚拟机服务的动态操作的管理。

官方文档的简介如下：

Tacker 是一个基于 OpenStack 的 VNF 管理服务，是一个用于在 OpenStack 搭建的 NFV 平台上部署运维 VNF 的框架。它基于 ETSI MANO 架构，为 VNF 的端到端管理提供了一套完整的功能栈。

ETSI 是欧洲电信标准协会，NFV 相关标准制定工作主要由该协会推进。MANO 是 网路功能虚拟化管理与协调流程 (NFV Management and Orchestration, NFV MANO) 的意思。 ETSI MANO 架构中（Tacker 项目链接中有架构图），NFV 被分为三个功能模块：

• NFV 协同器，用于上线新增网络服务与 VNF 包，管理网络服务的生命周期，进行全局资源管理，以及 NFVI 资源请求的权限认证工作
• VNF 管理器，用于进行 VNF 实例的生命周期管理，以及在 NFVI 和 E/NMS 之间进行协调与事件报告
• 基础设施管理器（VIM），用于对 NFVI 用到的计算、存储与网络资源进行控制管理

我们对于移植 ServiceVM 的代码以进行虚拟机管理这方面的工作目前还处于概念验证阶段，主要仍然是参考社区的开发。

InfoQ：去年你介绍了 OpenContrail 以及 Floodlight、RYU 等控制器的情况。现在过了大半年，SDN 控制器现在是个什么状况，哪些发展的更成熟？

Zebra：OpenContrail 已经具有较强的商用价值。Floodlight、Ryu 只适合学习。

InfoQ：OpenStack 用于 NFV 场景的部署现在被越来越多运营商关注，不少网络厂商和软件厂商现在都在这块发力，这似乎对于 Neutron/Nova 带来很多影响？你对此有何看法？

Zebra：运营商网络毕竟和云网络有所不同，我们也关注 NFV 的应用，但是用例的关注点会有较大差异。

InfoQ：现在我们跟进社区代码的更新是怎样的频率？跟随大版本，还是按照每日或其他的频率更新？

Zebra：这个问题确实也是困扰我们的问题。我们现在是 Juno 版，之前跟社区会半年做一次同步。我们自己开发了一些适合中国市场的功能，打算这次做 Kilo 合并之前进行一次我们自身代码的重构，因为我们知道 Kilo 版变化特别大，我们希望通过自身代码的重构，最大程度的降低与社区代码的藕合度，以方便后续的大版本升级。

关于受访者

马啸（Zebra）现在担任 UnitedStack 资深网络开发工程师，SDN 网络研发负责人。对 SDN 网络架构有独到深刻的理解，曾经参与 NEC 通用控制器 PFC、Floodlight 等项目的开发。2013 年开始研究 SDN 控制器与 OpenStack Neutron 的集成，2014 年开始深入研究 Neutron 的代码，致力于解决 Neutron 的稳定性、服务多样性、性能、融合性。