Dragonflow的架构、功能及未来发展路线图详解
-
Dragonflow架构由Neutron插件构成，该插件可以将Neutron模型映射到一个新的逻辑拓扑模型中，并与本地Dragonflow控制器进行同步。而这些Dragonflow控制器都分布在使用插入式的分布式DB解决方案的每个计算节点当中。
与其他项目不同的是，Dragonflow自己可以将拓扑和策略分配至本地端（本地控制器），并在每个计算节点中将该拓扑编译成配置和OpenFlow流。
在以下的文章中，Dragonflow项目的发起者Gal Sagie介绍了Dragonflow项目中已经支持的功能，及其未来的发展路线图。Gal Sagie表示，在未来，还将详细撰文独立介绍其中的每一项功能。
下图是目前的Dragonflow架构：
针对Liberty版本的Dragonflow
以下功能是已经实现的功能，其中部分是针对Liberty版本的Dragonflow项目中的功能。你可以使用这个local.conf范例在你的机器上安装带有devstack的Dragonflow。（Dragonflow有自己的devstack插件。）
L2、分布式L3路由（DVR）
Dragonflow使用OpenFlow在每个计算主机上同时部署了L2和使用桥接器（br-int）的分布式L3（DVR）。需要重点指出的是，Dragonflow不需要使用命名空间和除本地控制器之外的任务额外代理。
我们已经定义和优化了在流中执行L2和分布式L3路由的OpenFlow传递路径。
由于连接追踪已经在OVS被支持，因此我们可以在流中整合和执行安全群组规则。
Dragonflow传递路径已针对使用OVS megaflow机制进行了优化，并且使用了一个流安装混合方案，这意味着部分流仅能够根据本地控制器的需求安装，部分流可以前摄性安装。这一路径为更高级别的反应性敞开了大门，本地控制器可以查询分布式DB或是任何其他的外部源。
Gal Sagie表示将在接下来的文章中深入介绍Dragonflow的传递路径。他认为，这种混合解决方案可以帮助减少在计算节点间需要同步的冗余数据的数量，在将外部应用接入Dragonflow传递路径时这一点是非常重要的。
可插入式DB层
这是Dragonflow最有意思的功能之一。从CMS到所有的本地控制器，Dragonflow使用DB框架同步虚拟网络拓扑和规则。基本上，我们会有一个能够将Neutron模型转化为我们DB的Neutron插件。本地控制器会将自身注册到这个DB中，并且创建可通至另外一个DB的隧道。
当设计这个区域时，Dragonflow的团队决定下功夫创建一个可用于生产的DB系统，同时我们还认为由于规模、SLA限制和计算节点上的DB框架费用、延时需求等原因，不同的环境需要不同的DB解决方案。这是我们之所以将这个层设计为一个可插入式的，以及使用著名的、经过测试且已被部署的开源DB解决方案的原因。
团队还提供一个非轻量级的驱动API，任何想与Dragonflow协作的新框架都需要执行这个API和一个通用的安装脚本。但是一旦做了这些工作，用户就能够将Dragonflow插入到这个DB框架中，并使用它们的功能。（例如，集群/HA/性能与延时/ 关于DB写入的 ACL等。）
DB框架能够显示其正在使用驱动API的功能。如果它们支持的话，Dragonflow本地控制器也将尝试使用这些功能。例如，对发布-订阅、关于特定列值的发布-订阅和处理等的支持。
下列图表展示的是DB架构，其中包括与在数据模型语言中被定义的北向API适配器层通信的插件和本地控制器。这个层会将数据模型转译为简单的键/值DB操作，并调用可插入式的DB驱动。这一工作是为了简化新DB驱动的创建工作，每次增加或调整Dragonflow数据模型中的新功能后，不需要再对它们进行调整。
在这一领域中，我们希望未来实现两个里程碑。
1．目前所有的计算节点会同步来自DB服务器的所有拓扑和规则数据。Dragonflow的团队认为，由于租户隔离性的特点，这将不再被需要。部分虚拟端口或虚拟机并不会再与其他的虚拟端口或虚拟机实现互通，所有的这些虚拟机将扩展到整个数据中心。团队希望，能够让本地控制器仅同步本地端口需要的相关数据。
2．由于硬件能力的不断增强，以及在虚拟化环境中大量使用容器，未来的开发将会带来许多端口。这意味着为了能够扩展，以及提供更低的延时和更好的性能，Dragonflow控制器必须只同步关系最为密切的数据。我们相信只通过让DB服务器具有更好的缓存机制和反应性，就能够实现这一目标。
分布式DHCP
Dragonflow传递路线已经完全支持分布式DHCP。每个计算节点上的本地控制器都有一个内部的DHCP应用，这些DHCP应用能够为来自本地虚拟机的DHCP请求提供服务。更多详细信息可以阅读Eran Gampel博客中关于分布式DHCP的文章。
Dragonflow的技术路线图
下列功能虽然仍处于设计过程中，但却是Dragonflow项目计划的重要指标，它表明Dragonflow的主要目的是处理和应对大量受到关注、且会带来帮助的领域。
分布式SNAT/DNAT
分布式DNAT（浮动IP）是Dragonflow正在从事的一项工作，主要设计目的是将其整合到Dragonflow当前的传递路线当中。对于分布式SNAT，我们有一些想法，但是在我们定下想法之前，还需要等待一些额外的反馈意见。
分布式网络功能、拓扑注入与服务链
在这个领域当中，Dragonflow团队有一些令人兴奋和感兴趣的想法。我们希望为外部应用定义一个路线，以在不需要调整Dragonflow内部代码的情况下，能够管理我们的部分OpenFlow传递路径。
我们希望允许对外部应用做出反应，并且能够在除了易于管理和部署的分布式网络服务功能之外对经典服务链进行定义。
智能NIC
硬件卸载并不是新的东西。目前NIC内置了交换机和流分类机制，它可以将一些网络传递路线计算卸载至硬件。许多公司正在研究将OVS能力完全卸载至硬件。我们将NIC中的隧道/封装卸载视为目前可完成的一项重大改进。
我们认为，硬件不可能像软件那样灵活，因为我们提供了一种除硬件能力外的软件OVS混合解决方案。
在我们看来，Dragonflow管理着本地NIC（使用其API）和基于软件的OVS，同时带来了一个经过优化的传递路线。这一传递路线尽管仍在为那些在硬件中不被支持的东西提供软件OVS，但是其正在利用NIC的硬件能力。我们认为，这需要一个能够根据硬件能力正确调整传递路线的本地控制器实体（Dragonflow）。
目前我们已经开始与智能NIC厂商就概念验证展开设计讨论。
分层级的端口绑定——SDN架顶交换机
Dragonflow将支持一个特殊配置选项，以允许其与VLAN标记的指定网络分段id协作，从而让其卸载VXLAN隧道至一个SDN架顶交换机。
容器
Dragonflow将支持在不引入叠加抽象层的情况下，使用虚拟机内部的嵌入式容器。我们将支持多种不同的部署模式，并将其与Kuryr项目进行充分的整合。总结
正如大家所看到的那样，Dragonflow项目既遇到了许多挑战，同时也迎来了许多激动人心的时刻。我们有一个雄心勃勃的计划，并且希望与大家一同携手致力于这一项目。我们希望分享这一项目的愿景和部署挑战，并尽我们的全力创建一个最佳的开源解决方案。
如果你愿意加入我们，像我们在开始时那样感受自由，你可以在Dragonflow github中查看它们的全部代码，也可以点击我们的项目Launchpad（发射台）页面。如果你有任何问题或建议可以在IRC中加入我们。
