码迷,mamicode.com
首页 > 其他好文 > 详细

Neutron新进展|DragonFlow在Mitaka版本中的Roadmap

时间:2016-04-11 10:03:07      阅读:297      评论:0      收藏:0      [点我收藏+]

标签:

OpenStack网络在Mitaka版本中将有哪些新变化?1月11日到12日,DragonFlow的PTL——Eran Gampel,Kuryr的PTL——Gal Sagie,和他们的老大从以色列来到杭州,参加DragonFlow Meetup。UnitedStack有云的网络组同事苌智和康敬亭参与了这次讨论,并整理出Dragonflow在Mitaka版本中要完成的工作以为未来的Roadmap。

背景介绍
Dragonflow是OpenStack网络组件Neutron的子项目,由华为以色列技术团队提出,在开发者中备受瞩目。项目提出的时间是在2014年,2015年开始提交代码。
Dragonflow可以理解为Neutron的3层的控制器扩展组件。它实现了Neutron的L3 Service API,还为Neutron提供了分布式虚拟路由器功能。从设计理念上讲,Dragonflow使用的是可插入式无状态化轻量级SDN控制器,实现了租户子网间(东-西)流量的完全分布化,避开了网络节点,减小了故障域,避免单点故障。
按照Dragonflow的设计理念,它可以提升OpenStack Neutron L3的可扩展性、弹性、性能和可靠性。它可以支持数千个计算节点,为实现动态增长而保持控制器的无状态化,没有中央瓶颈,通过避免使用iptables和命名空间减少计算节点开销。
本次DragonFlow Meetup,主要讨论了在未来的一个周期内(Mitaka)要完成的工作以及DragonFlow的Roadmap。下面按照优先级的高低依次介绍关于这次讨论的十个方面。

  • 安全组
  • 性能测试
  • 保持数据库的一致性
  • 分布式DNAT
  • 消息队列的发布/订阅
  • 分布式数据库
  • 支持Vlan网络
  • 实现Zookeeper的DB Plugin
  • 实现ML2 Mechanism driver
  • 多层绑定与TOR
  • Dragonflow VS OVN

安全组
在本次Meetup中,关于安全组在DragonFlow的实现,讨论的最为激烈,实现的优先级也最高。在讨论安全组之前,需要指出的是,安全组是有状态的,也就是说,不管outbound traffic( egress )的规则如何限制,只要inbound traffic( ingress )的规则允许了某些流量进入,那么相应的回复流也允许了。对于安全组的实现,在原生的Neutron中默认是通过IPtables来实现的。示意图如下:技术分享

如上图所示,虚拟机的TAP设备被桥接在了Linux Bridge上,在这个桥上通过IPtables实现了安全组。这样的实现本身没有什么问题,但是当在一个安全组里创建/更新虚拟网卡的时候,就会向该安全组里所有成员广播该消息,使得消息队列中充斥大量的广播消息,从而拖垮消息队列。

在DragonFlow中,虚拟机的TAP设备直接桥接在了OVS Bridge上,从而通过使用OVS流表实现安全组功能。

核心的思想是,一条流(Flow)对应一个安全组规则。每个虚拟机网卡(Port)绑定一个安全组,匹配条件只限定源安全组ID,目的安全组ID,同时可以增加安全策略(例如限制端口80,8080等)。

具体的技术要点:

1 利用 ovs conntrack实现基于状态的规则。

2 当port有更新时,避免流表的变化。

3 尽量最小化流表的条目数。

4 安全组更新时,影响范围要尽可能小。

性能测试
主要性能测试包括数据平面和控制平面: 数据平面主要测试主要是对比DVR的性能优势,控制平面主要测试分为以下3个方面:

1 测试pub/sub性能,主要测试local controller对neutron资源变化的响应能力。

2 在存在大量port的情况下,主要测试controller的packetout/packetin的性能,这种测试场景主要是reactive模式的性能测试,一般会在arp responser,icmp,router路由首包上送等应用场景。

3 neutron DB和dragonflow DB的一致性压力测试。目前有一个bugfix还在讨论。

保持数据库的一致性
由于DragonFLow采用了分布式数据库,产生了Neutron数据库和DragonFlow本身数据库之间的数据一致性问题。

目前尚未有统一的解决方案。对于数据一致性问题,我认为在OVN中这个问题会显得更为突出。在OVN中,有三类数据库:

NorthBound DB,SouthBound DB和Neutron DB,这样的架构当产生单点故障时,无疑是非常麻烦的。

分布式DNAT
目前,DragonFlow在网络节点上使用Neutron的L3 agent作为集中式的SNAT和DNAT,目前DragonFlow尚不支持分布式SNAT,依然需要L3 agent提供SNAT功能。我们知道,在现在的DragonFlow中,有两个OVS Bridge,br-int作为计算节点的内部网桥,br-ex作为该节点的外部网桥。在外部网桥上会实现分布式DNAT。

分布式DNAT和分布式SNAT有什么不同?对于公网IP绑定在虚拟机上时,也就是1:1的NAT,DNAT和SNAT只起到了地址转换的作用。对于公网IP绑定在路由器上时,也就是1:N的NAT,必然会用端口表示连接,如何保证连接不被复用?在L3 agent中,使用Linux Namespace作为虚拟路由器,在路由器内通过conntrack记录连接状态。

因此分布式DNAT和分布式SNAT才会在实现方式上有不通。目前DragonFlow对于分布式DNAT的优先级比较低,而分布式SNAT目前没有时间规划。

消息队列的发布/订阅
在DragonFlow中,使用ZeroMQ作为默认的消息队列。与其说ZeroMQ是消息队列,倒不如说ZeroMQ是一套基于Socket API之上实现的网络通讯库。

ZeroMQ内置四种消息模型:Request-reply (请求回复模型),Pub-sub(发布/订阅模型),Pipeline(管道模型), Exclusive pair(一对一结对模型)。

DragonFlow使用发布/订阅(pub/sub)模型,目前该feature已经全部实现了,正在review中。

分布式数据库
DragonFlow使用了分布式数据库,示意图如下: 技术分享

如图所示,会有一个数据库集群,这个集群可以采用OVSDB,ETCD,Cassandra,RAMCloud等实现。

每个计算节点上会运行相应的DB driver,通过ZeroMQ进行消息的订阅和发布。

支持Vlan网络
目前DragonFlow尚不支持vlan网络,也没有相应的spec,在后续的版本里会支持。

实现Zookeeper的DB Plugin
Zookeeper作为一个高一致性的分布式NoSQL数据库,能够实现集群管理,也可以作为DB使用,目前这个feature正在review中。

实现ML2 Mechanism driver
Neutron Server由Core Plugin和Service Plugins组成。在当前的DragonFlow中,使用DFPlugin作为Core Plugin嵌入到Neutron Server中。

在此次的Meetup中,讨论将DFPlugin作为Mechanism Driver嵌入Neutron Server。目前只有这个计划,还没有开始。

多层绑定与TOR
目前的Neutron代码中已经支持了多层绑定,在以后的版本中,DragonFlow也将考虑支持多层绑定。多层绑定的好处是,在软件架构上适应各种网络方案,软件方案以及硬件offload方案等,在硬件offload方案中,需要TOR Switch提供ovsdb,OpenFlow等,提供高性能的SDN组网方案。

Neutron目前不具备这种功能,dragonflow的local controller可以胜任,同时在对比HW的agile(控制器)方案,dragonflow local controller可以支持各种APP,例如DHCP, DNS也可实现VPN,GW,FW等高级服务,总之就是一个控制器的解决方案。

Dragonflow VS OVN
最后讨论的dragonflow与OVN谁能走的更远,在dragonflow项目开始时,OVN还不存在,后面OVS团队启动了OVN项目,希望接管整个的网络数据平面和控制平面。

他们观点如下:

1 在dragonflow和OVN这种分布式架构下,分布式数据库,以及多级数据库一致性是很头疼的问题,dragonflow需要维护neutron DB和每个local DB的一致性,而OVN需要维护Neutron DB,North DB,South DB的一致性。两个数据库一致性已经很难处理,维持三个数据库一致性的难度可想而知。

2 dragonflow的local controller 可以提供各种APP plugin,提供更灵活,高级的服务,而OVN显然不行。

3 dragonflow和ovn相比而言,一个明显的优势就是dragonflow支持插件式的DB。

4 猜测OVN或许就是vmware NSX的一个虚拟化的解决方案。

5 关于DF对OVN的态度,在午餐尾声,Gal说了一句话:To Destroy OVN

关于作者:
苌智,SDN 工程师,2015年1月加入 UnitedStack有云,专注于虚拟网络和 SDN 方向,OpenStack Neutron 社区活跃贡献者。

https://www.ustack.com/blog/neutron-dragonflow/

Neutron新进展|DragonFlow在Mitaka版本中的Roadmap

标签:

原文地址:http://www.cnblogs.com/allcloud/p/5377115.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!