微信号:infoqchina

介绍:有内容的技术社区媒体

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

2015-07-15 11:27 杨赛

题图:来自电影《国王的演讲》


在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进行太大的改动。


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


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


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版变化特别大,我们希望通过自身代码的重构,最大程度的降低与社区代码的藕合度,以方便后续的大版本升级。



版权归属InfoQ,禁止私自抄袭转载。

回复关键词React | 架构师 | 运维 | 云 | 开源 | 物联网 | Kubernetes | 架构 | 人工智能 | Kafka | Docker | Netty | CoreOS | QCon | Github | Swift | 敏捷 | 语言 | 程序员




有话想说?!戳“写评论”👇

 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 理解究竟什么是RESTful架构? 传智/黑马合并(2016各学科学费价格表--大优惠) JQuery 之父: 好好学习,天天编码 ios入门教程丨第一章:helloworld概述及简单的教程 c#官方微信公众号-首篇语