转载

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

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

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

嘉宾简介

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

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重启的时候，会进行如下两步操作：

初始化OVS的流表，主要指VLan网络用的OVS Bridge和OVS的Tunnel Bridge（这样就产生了冲刷）
重新从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版变化特别大，我们希望通过自身代码的重构，最大程度的降低与社区代码的藕合度，以方便后续的大版本升级。

正文到此结束