Dragonflow架構由Neutron插件構成，該插件可以將Neutron模型映射到一個新的邏輯拓撲模型中，并與本地Dragonflow控制器進行同步。而這些Dragonflow控制器都分布在使用插入式的分布式DB解決方案的每個計算節點當中。

與其他項目不同的是，Dragonflow自己可以將拓撲和策略分配至本地端（本地控制器），并在每個計算節點中將該拓撲編譯成配置和OpenFlow流。

在以下的文章中，Dragonflow項目的發起者Gal Sagie介紹了Dragonflow項目中已經支持的功能，及其未來的發展路線圖。Gal Sagie表示，在未來，還將詳細撰文獨立介紹其中的每一項功能。

下圖是目前的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傳遞路徑時這一點是非常重要的。

這是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的主要目的是處理和應對大量受到關注、且會帶來幫助的領域。

分布式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中加入我們。

文章轉載自：openstack_plus官方微信