标签：
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。下面按照优先级的高低依次介绍关于这次讨论的十个方面。
安全组
在本次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
