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

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

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

下圖是目前的Dragonflow架構(gòu)：

以下功能是已經(jīng)實現(xiàn)的功能，其中部分是針對Liberty版本的Dragonflow項目中的功能。你可以使用這個local.conf范例在你的機器上安裝帶有devstack的Dragonflow。（Dragonflow有自己的devstack插件。）

L2、分布式L3路由（DVR）

Dragonflow使用OpenFlow在每個計算主機上同時部署了L2和使用橋接器（br-int）的分布式L3（DVR）。需要重點指出的是，Dragonflow不需要使用命名空間和除本地控制器之外的任務(wù)額外代理。

我們已經(jīng)定義和優(yōu)化了在流中執(zhí)行L2和分布式L3路由的OpenFlow傳遞路徑。

由于連接追蹤已經(jīng)在OVS被支持，因此我們可以在流中整合和執(zhí)行安全群組規(guī)則。

Dragonflow傳遞路徑已針對使用OVS megaflow機制進行了優(yōu)化，并且使用了一個流安裝混合方案，這意味著部分流僅能夠根據(jù)本地控制器的需求安裝，部分流可以前攝性安裝。這一路徑為更高級別的反應(yīng)性敞開了大門，本地控制器可以查詢分布式DB或是任何其他的外部源。

Gal Sagie表示將在接下來的文章中深入介紹Dragonflow的傳遞路徑。他認為，這種混合解決方案可以幫助減少在計算節(jié)點間需要同步的冗余數(shù)據(jù)的數(shù)量，在將外部應(yīng)用接入Dragonflow傳遞路徑時這一點是非常重要的。

這是Dragonflow最有意思的功能之一。從CMS到所有的本地控制器，Dragonflow使用DB框架同步虛擬網(wǎng)絡(luò)拓撲和規(guī)則?；旧希覀儠幸粋€能夠?qū)eutron模型轉(zhuǎn)化為我們DB的Neutron插件。本地控制器會將自身注冊到這個DB中，并且創(chuàng)建可通至另外一個DB的隧道。

當(dāng)設(shè)計這個區(qū)域時，Dragonflow的團隊決定下功夫創(chuàng)建一個可用于生產(chǎn)的DB系統(tǒng)，同時我們還認為由于規(guī)模、SLA限制和計算節(jié)點上的DB框架費用、延時需求等原因，不同的環(huán)境需要不同的DB解決方案。這是我們之所以將這個層設(shè)計為一個可插入式的，以及使用著名的、經(jīng)過測試且已被部署的開源DB解決方案的原因。

團隊還提供一個非輕量級的驅(qū)動API，任何想與Dragonflow協(xié)作的新框架都需要執(zhí)行這個API和一個通用的安裝腳本。但是一旦做了這些工作，用戶就能夠?qū)ragonflow插入到這個DB框架中，并使用它們的功能。（例如，集群/HA/性能與延時/ 關(guān)于DB寫入的 ACL等。）

DB框架能夠顯示其正在使用驅(qū)動API的功能。如果它們支持的話，Dragonflow本地控制器也將嘗試使用這些功能。例如，對發(fā)布-訂閱、關(guān)于特定列值的發(fā)布-訂閱和處理等的支持。

下列圖表展示的是DB架構(gòu)，其中包括與在數(shù)據(jù)模型語言中被定義的北向API適配器層通信的插件和本地控制器。這個層會將數(shù)據(jù)模型轉(zhuǎn)譯為簡單的鍵/值DB操作，并調(diào)用可插入式的DB驅(qū)動。這一工作是為了簡化新DB驅(qū)動的創(chuàng)建工作，每次增加或調(diào)整Dragonflow數(shù)據(jù)模型中的新功能后，不需要再對它們進行調(diào)整。

在這一領(lǐng)域中，我們希望未來實現(xiàn)兩個里程碑。

1．目前所有的計算節(jié)點會同步來自DB服務(wù)器的所有拓撲和規(guī)則數(shù)據(jù)。Dragonflow的團隊認為，由于租戶隔離性的特點，這將不再被需要。部分虛擬端口或虛擬機并不會再與其他的虛擬端口或虛擬機實現(xiàn)互通，所有的這些虛擬機將擴展到整個數(shù)據(jù)中心。團隊希望，能夠讓本地控制器僅同步本地端口需要的相關(guān)數(shù)據(jù)。

2．由于硬件能力的不斷增強，以及在虛擬化環(huán)境中大量使用容器，未來的開發(fā)將會帶來許多端口。這意味著為了能夠擴展，以及提供更低的延時和更好的性能，Dragonflow控制器必須只同步關(guān)系最為密切的數(shù)據(jù)。我們相信只通過讓DB服務(wù)器具有更好的緩存機制和反應(yīng)性，就能夠?qū)崿F(xiàn)這一目標(biāo)。

分布式DHCP

Dragonflow傳遞路線已經(jīng)完全支持分布式DHCP。每個計算節(jié)點上的本地控制器都有一個內(nèi)部的DHCP應(yīng)用，這些DHCP應(yīng)用能夠為來自本地虛擬機的DHCP請求提供服務(wù)。更多詳細信息可以閱讀Eran Gampel博客中關(guān)于分布式DHCP的文章。

下列功能雖然仍處于設(shè)計過程中，但卻是Dragonflow項目計劃的重要指標(biāo)，它表明Dragonflow的主要目的是處理和應(yīng)對大量受到關(guān)注、且會帶來幫助的領(lǐng)域。

分布式SNAT/DNAT

分布式DNAT（浮動IP）是Dragonflow正在從事的一項工作，主要設(shè)計目的是將其整合到Dragonflow當(dāng)前的傳遞路線當(dāng)中。對于分布式SNAT，我們有一些想法，但是在我們定下想法之前，還需要等待一些額外的反饋意見。

分布式網(wǎng)絡(luò)功能、拓撲注入與服務(wù)鏈

在這個領(lǐng)域當(dāng)中，Dragonflow團隊有一些令人興奮和感興趣的想法。我們希望為外部應(yīng)用定義一個路線，以在不需要調(diào)整Dragonflow內(nèi)部代碼的情況下，能夠管理我們的部分OpenFlow傳遞路徑。

我們希望允許對外部應(yīng)用做出反應(yīng)，并且能夠在除了易于管理和部署的分布式網(wǎng)絡(luò)服務(wù)功能之外對經(jīng)典服務(wù)鏈進行定義。

智能NIC

硬件卸載并不是新的東西。目前NIC內(nèi)置了交換機和流分類機制，它可以將一些網(wǎng)絡(luò)傳遞路線計算卸載至硬件。許多公司正在研究將OVS能力完全卸載至硬件。我們將NIC中的隧道/封裝卸載視為目前可完成的一項重大改進。

我們認為，硬件不可能像軟件那樣靈活，因為我們提供了一種除硬件能力外的軟件OVS混合解決方案。

在我們看來，Dragonflow管理著本地NIC（使用其API）和基于軟件的OVS，同時帶來了一個經(jīng)過優(yōu)化的傳遞路線。這一傳遞路線盡管仍在為那些在硬件中不被支持的東西提供軟件OVS，但是其正在利用NIC的硬件能力。我們認為，這需要一個能夠根據(jù)硬件能力正確調(diào)整傳遞路線的本地控制器實體（Dragonflow）。

目前我們已經(jīng)開始與智能NIC廠商就概念驗證展開設(shè)計討論。

分層級的端口綁定——SDN架頂交換機

Dragonflow將支持一個特殊配置選項，以允許其與VLAN標(biāo)記的指定網(wǎng)絡(luò)分段id協(xié)作，從而讓其卸載VXLAN隧道至一個SDN架頂交換機。
容器
Dragonflow將支持在不引入疊加抽象層的情況下，使用虛擬機內(nèi)部的嵌入式容器。我們將支持多種不同的部署模式，并將其與Kuryr項目進行充分的整合。

正如大家所看到的那樣，Dragonflow項目既遇到了許多挑戰(zhàn)，同時也迎來了許多激動人心的時刻。我們有一個雄心勃勃的計劃，并且希望與大家一同攜手致力于這一項目。我們希望分享這一項目的愿景和部署挑戰(zhàn)，并盡我們的全力創(chuàng)建一個最佳的開源解決方案。

如果你愿意加入我們，像我們在開始時那樣感受自由，你可以在Dragonflow github中查看它們的全部代碼，也可以點擊我們的項目Launchpad（發(fā)射臺）頁面。如果你有任何問題或建議可以在IRC中加入我們。

文章轉(zhuǎn)載自：openstack_plus官方微信