NFV系統跨數據中心網絡連接管理機制

石 峰，藺婧娜

(1.太原學院 計算機科學與技術系，山西 太原 030032；2.山西工程科技職業大學 信息工程學院，山西 太原 030031)

0 引 言

對于企業用戶而言，大規模網絡功能部署面臨以下幾方面的挑戰：網絡功能數量繁多、網絡功能種類多樣、網絡功能處理邏輯復雜。網絡功能的日常運維工作包括網絡功能升級、監控診斷、配置調試等多種復雜操作[1-3]。

考慮到本地部署的高昂開銷以及復雜操作，越來越多的中小型企業將網絡功能外包到云平臺，在云服務提供商內部署虛擬網絡功能服務。目前已經有大量的云服務提供商為中小型企業提供豐富的網絡功能服務，包括運營商(例如：AT&T)以第三方云服務提供商(例如：Akamai，Amazon)等[4,5]。

NFV技術是云計算催生的下一代網絡變革。NFV技術可以有效地在云平臺進行部署實現，實現虛擬網絡功能的按需訂購、靈活調度以及便捷管理。目前已經有大量的研究工作致力于實現基于NFV的云平臺網絡功能高效部署[6-8]。

網絡功能調度管理的基本要求是：按照服務功能鏈信息，實現網絡功能連接關系的靈活配置。然而，目前大部分的NFV系統[9,10]均在單一數據中心場景下進行設計，以網絡功能為獨立單元，在通用數據平面上利用控制器的集中調度管理實現服務功能鏈部署。

為了實現數據中心靈活連接，用戶必須手動建立一個轉發表確保數據包在數據中心之間得到正確轉發。除此之外，如FlowTag[11]所分析，現實部署存在大量的網絡功能在完成數據處理之后輸出一些必要的標簽，用于保證數據包在之后的正確轉發。

本文提出了一個跨數據中心的網絡功能連接管理機制——NFVMP(network function virtualization for multiple providers)。NFVMP將每一個數據中心的子鏈視作一個單元，在每個數據中心內建立與其它數據中心的連接關系，支持跨數據中心服務功能鏈自動靈活部署，有效提高了網絡功能調度管理的靈活性。

1 理論分析

NFVMP系統的基礎功能是保障正確性，確保數據包按照服務功能鏈以正確的轉發路徑被多個網絡功能處理。在本文中，對多數據中心場景下的數據流進行理論建模，并且與傳統單一數據中心場景的數據流進行對比分析，從而得出NFVMP系統的設計原則。

1.1 系統模型

(1)

(2)

…

(3)

因此，獲得了如下等式

(4)

1.2 正確性分析

企業網用戶將網絡功能f1,f2,…,fn部署在p1,p2,…,pm數據中心。根據系統正確性，NFVMP必須與傳統NFV系統產生相同的數據包處理結果。因此，總結得出了以下的等式

(5)

其中，等式左邊代表了NFVMP的數據包結果，等式右邊代表傳統NFV系統生成的數據包結果。傳統的NFV系統將每個網絡功能視作獨立單元，并致力于解決網絡功能部署以及網絡功能連接問題。為了讓上述公式成立，NFVMP需要將每個數據中心的子鏈視作獨立單元，并且實現以下兩步操作：①每一個數據中心生成各自的子鏈，使得數據包在數據中心內部能夠正確地進行處理和轉發；②實現子鏈之間的正確連接。

2 NFVMP設計

在本文節，分別對子鏈生成、子鏈連接以及子鏈更新機制進行具體介紹，其中第2.1節介紹了子鏈生成機制，第2.2節展示了子鏈連接機制，第2.3節展示了子鏈更新機制。

2.1 子鏈生成

全局服務功能鏈被分解為兩個部分：數據中心A的服務功能子鏈以及數據中心B的服務功能子鏈。子鏈生成算法計算得到的子鏈需要滿足兩個要求：①表明數據中心內部實現的網絡功能及其轉發關系；②表明與其它子鏈的連接關系。設計了一個子鏈生成算法，以全局服務功能鏈為輸入信息，計算生成所有相關數據中心的子鏈。除此之外，為了方便描述輸入以及輸出信息，設計了一個服務功能鏈描述語言，能夠兼容多數據中心場景。

2.1.1 服務功能鏈描述語言

在之前的工作中，E2[13]已經設計了一個服務功能鏈描述語言，能夠有效描述所有網絡功能以及它們之間的連接關系。然而，出于以下兩點考慮，它并不能直接應用在NFVMP系統中：①未說明數據中心相關信息；②未能表達與其它服務功能鏈之間的連接關系。

這里設計了一種新的服務功能鏈描述語言，能夠有效兼容多數據中心場景。下面展示了服務功能鏈描述語言的示例。

NF_set: NF1 {DC А}, NF2 {DC B},

NF3 {DC B}, NF4 {DC B};

rule-set { input->NF1,

NF1[cl]-> NF2,

NF2[c2]->NF3,

NF3[c3]->NF4,

NF2->NF4,

NF3->NF4,

NF4->output;]

服務功能鏈描述語言主要由兩個部分組成：NF_set以及rule_set。NF_set包含了所有的網絡功能以及它們對應的數據中心信息。rule_set 描述了網絡功能之間或者與上流、下流數據中心之間的轉發關系。每一條rule都通過以下的格式進行定義：src_node[condition]->dst_node。

與傳統描述語言相比，src_node/dst_node可能是上流或者下流數據中心，從而描述與其它數據中心之間的連接關系。例如：“dc A[c1]->NF2”表示從數據中心A發出并且攜帶cl標簽的數據包發送到NF2進行后續處理。如果condition為空，那么表示在默認情況下并不需要對數據包進行過濾處理。

2.1.2 子鏈生成算法

算法1展示了提出的子鏈生成算法。根據輸入的全局服務功能鏈，該算法為所有相關數據中心生成各自的子鏈。其中第(2)行～第(3)行用來生成所有數據中心的NF_sets。剩下的部分用于生成rule_sets。對于rule_set中的規則符合以下任何一個條件：①src_node以及dst_node隸屬于同一個數據中心；②src_node是input；③dst_node是output，則直接添加該規則到唯一存在的數據中心的子鏈中。如果src_node與dst_node不隸屬于同一個數據中心，那么將產生兩條規則并分配到兩個子鏈中。第一條規則加入到src_node的數據中心子鏈中，dst_node被dst_node的數據中心代替。第二條規則加入到dst_node的數據中心子鏈中，src_node被src_node的數據中心代替。

客戶端通過上述子鏈生成算法得到所有相關數據中心的子鏈，并將其通過特定的接口下發到各個數據中心進行后續子鏈部署。

算法1：子鏈生成算法

輸入：全局服務功能鏈描述(NF_set and rule_set)；

輸出：每個數據中心的子鏈描述(NF_set and rule_set);

初始化：每個數據中心子鏈：NF_set, rule_set?，?;

(1)functionChainPartition(NF_set, rule_set)

(2)forNF∈NF_ENF_setdo

(3) 添加NF到NF.dc的NF_set;

(4)forrule∈rule_setdo

(5) src_node, dst_node←rule.src_node, rule.dst node;

(6)ifsrc_node = input or src_node.dc= dst_node.dcthen

(7) 添加rule 到dst_node.dc的rule_set;

(8)elseifdstNode = outputthen

(9) 添加rule 到src_node.dc的rule_set;

(10)else

(11) 添加(src_node[rule.condition]→dst_node.dc)到

(12) src_node.dc 的rule_set;

(13) 添加(src_node.dc[rule.condition]→dst_node)到

(14) dst_node.dc 的 rule_set;

(15)return每個數據中心的NF_set and rule_set;

2.2 子鏈連接

對于傳統的NFV系統，網絡功能全部部署在通用數據平面上，控制器通過數據平面交換機配置網絡功能之間的連接關系。然而，在多數據中心場景下，獨立自治的數據中心使得通用數據平面以及集中控制器均無法實現。除此之外，現實部署中存在大量狀態相關的網絡功能，其輸出的狀態信息決定后續的數據包轉發路徑。這類網絡功能使得子鏈連接更加復雜。下面小節，將對以上兩個挑戰進行具體分析，并提出相應的解決方案。

2.2.1 數據中心間轉發策略

由于缺乏集中控制器以及通用數據平面，無法采用集中式的方法實現子鏈連接。采取分布式的方法將此問題分解為兩個子問題：①上流數據中心將數據包轉發到正確的下流數據中心；②下流數據中心將數據包轉發到正確的網絡功能。下面，將分別對兩個子問題進行具體說明。

當上流數據中心內的所有網絡功能完成數據包處理之后，數據中心需要將數據包轉發到下流數據中心進行后續處理。因此，在出口處安裝轉發器來建立數據包標簽與下流數據中心的轉發關系。數據包標簽能夠唯一確定下一個網絡功能，也就可以唯一確定下流數據中心。當數據中心從網卡收到數據包時，在入口處安裝分類器，從而正確地將數據包轉發到下一個網絡功能。分類器建立了上流數據中心、數據標簽與下一個網絡功能之間的綁定關系。上流數據中心與數據標簽能夠唯一地對下一個網絡功能進行確認。

算法2：分類表和轉發表生成算法

輸入：子鏈描述(NF_set and rule_set);

輸出:分類表和轉發表;

(1)functionTableGeneration(NF_set, rule_set)

(2)forrule∈rule_setdo

(3)ifrule.src_node ?NF_setthen

(4) 添加(rule.src_node, rule.condition, rule.dst_node)到分類表;

(5)elseifrule.dst_node?NF_setthen

(6) 添加規則(condition, rule.dst_node)到轉發表;

(7)else

(8) 跳過這條規則;

(9)return分類表和轉發表；

算法2展示了分類表和轉發表生成算法。該算法根據下發的子鏈信息，生成每個數據中心的分類表和轉發表。其中，第(3)行～第(4)行用于分類表的生成，第(5)行～第(6)行用于轉發表的生成。如果一條規則的src_node不屬于本地數據中心并且dst_node屬于本地數據中心，那么一條分類表的表項生成。上流數據中心由src_node的地址表示，標簽通過規則的condition信息生成，網絡功能由dst_node生成。同理，如果一條規則的dst_node不屬于本地數據中心并且src_node屬于本地數據中心，則生成一條轉發表的表項。其中，標簽由規則的condition生成，下流數據中心由dst_node生成。

2.2.2 數據包標簽處理策略

如FlowTag所述，現實部署中存在大量的網絡功能在對數據包處理之后生成一些標簽信息，用于指導數據包的后續轉發路徑。對于NFVMP，生成的數據包標簽可能會影響到數據包在其它數據中心內的轉發路徑。本文基于FlowTags設計了數據包標簽處理策略，從而支持多數據中心場景。

數據包標簽需要考慮以下3個方面的問題：①網絡功能生成狀態標簽；②網絡標簽對網絡功能數據處理的影響；③網絡標簽對轉發策略的影響。對于第一個方面，NFVMP采用了FlowTags類似的策略進行標簽存儲。對于IPv6協議，利用20比特的flow label字段來存儲；對于IPv4協議，利用8比特的TOS字段進行存儲。對于第二個方面，生成的網絡功能可能對下流網絡功能的數據處理產生影響。因為，在整個數據處理的流水線中，生成的數據包標簽始終保存并且不會刪除。對于第三個方面，數據包的標簽信息可能對數據中心之間的轉發產生影響。在NFVMP設計中，在分類器和轉發器中包含標簽信息，從而支持數據中心之間根據狀態信息進行轉發。

2.3 子鏈更新

上述子鏈生成與子鏈連接策略均基于靜態不變的服務功能鏈進行實現。然而，在現實部署中，服務功能鏈會隨著時間動態變化，從而滿足用戶的不同時刻需求。NFV系統設計需要支持靈活變化的服務功能鏈，包括動態增加或者刪減的網絡功能或者轉發關系變化。

一種簡單直白的解決方案是按照更新的服務功能鏈，將所有網絡功能重新在底層進行部署，重復之前的子鏈部署與子鏈連接過程。然而，這種方式導致大量的時間消耗與資源浪費。在本文，設計了一種增量策略更新方法，計算每個數據中心需要變更的策略，包括刪除的規則以及增加的規則等。客戶端根據新舊服務功能鏈分析計算子鏈更新內容并進行下發，數據中心則對接收到的更新策略進行實際部署。下面部分，將從這兩方面進行具體分析。

2.3.1 子鏈更新策略分析

客戶端負責分析所有子鏈的更新策略，也即網絡功能集變更NF_set(包括added_NF_set和expired_NF_set),以及規則集變更rule_set(包括added_rule_set和expired_rule_set)。算法3展示了子鏈更新算法，輸入是兩個服務功能鏈(原服務功能鏈與新服務功能鏈)的子鏈更新策略算法，輸出是所有相關數據中心的增量更新策略。其中第(2)行～第(5)行根據算法1生成兩個服務功能鏈的子鏈。第(7)行～第(11)行通過GetExpiredAddedSet函數生成所有數據中心的子鏈更新信息。其中GetExpiredAddedSet函數的功能是通過old_set與new_set的對比，生成expired_set與added_set。GetExpiredAddedSet通過如下的方法進行計算(見算法3的A1至A18行)：首先，old_set與new_set分別按照字典序進行排序，然而對其中的每一條規則同步進行瀏覽。如果old_rule與new_rule相同，那么做跳過處理，將兩條規則都在集合中刪除。如果old_rule小于new_rule，那么將old_rule添加到expired_set中。否則，將new_rule添加到added_set中。

2.3.2 子鏈更新策略部署

上述算法生成了所有數據中心的子鏈更新策略，包括add_NF_set、expired_NF_set、add_rule_set以及expired_rule_set。每個數據中心基于接收到的子鏈更新策略進行增量部署，包括以下幾方面：①添加或者移除網絡功能；②修改網絡功能之間的轉發關系；③修改與其它數據中心之間的轉發關系。如果src_node與dst_node全部是網絡功能類型，那么做第一類或者第二類重新配置，在每個數據中心內進行完成配置。如果src_node屬于input、output或者dc類信息，那么需要進行第三類更新配置，對分類表和轉發表進行修改，改變與鄰居數據中心之間的數據包轉發關系。

算法3：子鏈更新算法

輸入：舊服務功能鏈描述(old_NF_set and old_rule_set);

新服務功能鏈描述(new_NF_set and new_rule_set);

輸出：每個數據中心的增量更新子鏈

(expired_NF_set, expired_rule_set, added_NF_set, added_rule_set);

初始化：每個數據中心的增量子鏈：

expired_NF_set, expired rule_set, added_NF_set, added_rule_set←?, ?, ?, ?;

(1)functionChainUpdate(old_NF_set,old_rule_set,new_NF_set, new_rule_set)

(2) ChainPartition(old_NF_set, old_rule_set)

獲得dc_set_old以及子鏈;

(3) ChainPartition(new_NF_set, new_rule_set)

獲得dc_set_new以及子鏈;

(4) dc_set←(dc_set_old)∪(dc_ set_ new);

(5)fordc∈dc_ setdo

(6) dc.expired_NF_set, dc.added_NF_set ←

(7) Comparison(dc.old_NF_set, dc.new_NF_set);

(8) dc.expired_rule_set, dc.added_rule_ set)←

(9) Comparison(dc.old_rule_set, dc.new_rule_set);

(10)return每個數據中心：expired_NF_set, added_ NF_ set,

(11) expired_rule_set, added_rule_set;

A1：functionComparison(old_set, new_set)

A2： expired_set, added_set←?, ?

A3: old_sorted_queue = SortInLexicographicOrder(old_set);

A4: new_sorted_queue = SortInLexicographicOrder(new_set);

A5:while(old_sorted_queue != ?)and

(new_sorted_queue!= ?)do

A6: old, new←old_sorted_queue.first,

new_sorted_queue.first

A7:ifold == newthen

A8: 從old_sorted_queue 移除old;

A9: 從new_sorted_queue 移除new;

A10:elseifold < newthen

A11: 添加old 到expired_set;

A12: 從old_sorted_queue 移除old;

A13:else

A14: 添加new到added_set;

A15: 從new_sorted_queue移除new;

A16: 將old_sorted_queue的所以規則添加到expired_set;

A17: 將new_sorted_queue 的所以規則添加到added_set;

A18:returnexpired_set, added_set;

3 原型系統實現

在DPDK[16]以及OpenNetVM[14]的基礎上，對NFVMP進行了原型系統實現。在一系列的服務器上進行了開發部署，以下是每個服務器的硬件信息：兩塊Intel(R)Xeon(R)E5-2620v3 CPU(2.40 GHz,12核)，64 G RAM以及兩個10 G網卡。這些服務器都運行在Linux操作系統，其內核版本為3.10.0。

在實現的原型系統中，每一個服務器作為一個單獨的數據中心，與其它的數據中心進行直連。在每一個數據中心內，基于OpenNetVM運行一個單獨的NFV系統。在每個NFV系統內，采用Docker[14]技術進行網絡功能實現，從而保證每一個網絡功能在單獨的核內運行。除此之外，將分類器和轉發器也在Docker內運行，分別占用一個物理核。Docker方式能夠保障物理核不會被操作系統等其它任務所占用。

針對原型系統性能測試，基于MoonGen[15]進行流量生成。MoonGen是一個基于DPDK的流量生成器，在單獨的服務器上運行并且與其它服務器進行直連。流量生成器發送與接收生成的數據包，從而對系統的性能包括時延和吞吐量進行測量。

為了驗證NFVMP原型系統的性能，對以下4個網絡功能進行了實現：虛擬專用網絡、深度包檢測、網絡緩存以及網絡監控。上述網絡功能采用圖1的方式進行部署與連接。其中數據中心A負責前兩個網絡功能，數據中心B負責后面兩個網絡功能。從數據中心A流出的數據包如果目的端口是80，那么發送到網絡緩存，否則發送到網絡監控進行后續處理。

圖1 NFVMP原型系統部署的服務功能鏈

將NFVMP系統與OpenNetVM進行對比。對于OpenNetVM系統而言，所有的網絡功能在一個數據中心內運行，可以作為最佳模式。通過對比，可以得知NFVMP系統與最佳模式之間的差距。

4 驗證與評價

在本文中，從以下幾個方面對NFVMP系統進行了性能評價：

驗證了NFVMP可以跨數據中心實現數據包的正確轉發，與傳統的NFV系統產生相同的數據包處理結果。

評估NFVMP加入的3種算法運行時間開銷，包括子鏈生成算法、分類表和轉發表生成算法和子鏈更新算法。

評估NFVMP在數據層的性能開銷，包括變化的數據包大小、網絡功能數量以及數據中心數量對性能結果的影響。

驗證NFVMP系統在數據中心真實流量條件下的系統性能，包括數據包處理時延和吞吐量。

4.1 正確性驗證

生成一系列的數據包，并且在數據包負載中標記序列數字。將生成的流量分別發送到NFVMP以及OpenNetVM系統中，并且將最終的數據包結果進行對比分析。最終結果表明，NFVMP與OpenNetVM系統能夠得到相同的數據包結果，符合正確性準則，有效地提高了網絡功能跨數據中心調度的靈活性。

4.2 算法性能

在本節，對3種算法運行時間進行了評估，包括子鏈生成算法、分類和轉發表生成算法以及子鏈更新算法。

圖2展示了上述3種算法的運行時間與連接數之間的對應關系。兩種算法的運行時間均在毫秒數量級。例如：對于一個1000條連接數的服務功能鏈，子鏈生成算法消耗1.69 ms進行服務功能鏈分解，分類表和轉發表生成算法花費1.21 ms進行表生成，子鏈更新算法則花費6.45 ms來生成所有子鏈的增量更新策略。除此之外，網絡連接數與運行時間呈現線性增加的趨勢。上述時間開銷均發生在系統運行之前。對于NFV系統若干分鐘啟動時間而言，毫秒級別的時間是微不足道并且可以忽略不計的。

圖2 控制層算法性能

4.3 數據層性能

相比于傳統的NFV架構，NFVMP系統在數據層帶來調度管理靈活性優勢，使得服務功能鏈跨數據中心靈活部署。但是，NFVMP方案也給數據層性能帶來了一定的負載，并主要體現在以下兩方面：①數據中心間的數據包轉發；②數據中心內的表查詢。第一點的主要決定因素在于數據中心間的網絡通信資源，與NFVMP機制的設計無關，必須通過改良網間通信資源來提升性能。第二點的主要決定因素則是NFVMP設計帶來的分類器和轉發器。因此，在本文節，對表查詢造成的性能負載進行測量，并與最佳模式進行性能對比分析。

4.3.1 數據包大小的性能影響

使用64字節到1500字節的數據包來測試數據包大小對系統性能的影響，包括數據包處理時延和吞吐量。圖3的實驗結果表明：對于任意數據包大小，NFVMP均只引入極小的時延大約1.8μs。圖4表明了數據包大小與吞吐量之間的對應關系。隨著數據包大小的增加，NFVMP引入的網絡擁塞被緩解，與最佳模式的性能越來越接近。對于最差的結果(對應于64字節)，吞吐量下降比例是2.24%。如果數據包大小超過512字節，NFVMP與最佳模式的性能幾乎相同。

圖3 數據包大小對時延的影響

圖4 數據包大小對吞吐量的影響

4.3.2 網絡功能數量的性能影響

在此實驗中，采用了2個～6個相同的網絡功能，分布在兩個數據中心內進行部署。所有的網絡功能全部都是網絡緩存，并且數據包大小全部采用256字節。如果網絡功能的總數是偶數，兩個數據中心進行均勻分布，如果是奇數，那么數據中心A比數據中心B多部署一個網絡功能。圖5和圖6分別展示了網絡功能數量與時延、吞吐量之間的對應關系。在時延方面，對于所有的功能數量，NFVMP的時延開銷均為1.8μs。在網絡功能數量為4時，吞吐量下降率為3.51%。隨著網絡功能數量的增加，NFVMP與最佳模式的性能越來越接近。網絡功能數量越多,系統性能瓶頸在于多個網絡功能的數據處理，而不是分類器和轉發器造成的數據查詢工作。

圖5 網絡功能數量對時延的影響

圖6 網絡功能數量對吞吐量的影響

在此實驗中，驗證了NFVMP向多個數據中心擴展的能力，并測試了數據中心數量變化帶來的性能開銷。采用圖1的服務功能鏈，以及256字節的數據包進行實驗測量。對于4個網絡功能的服務功能鏈，最小的數據中心數量是1，最大的數據中心數量是4。圖7和圖8展示了網絡功能數量與時延、吞吐量之間的關系。每增加一個數據中心，系統時延增加1.8μs，吞吐量下降0.82%～26%。對于NFV系統而言，為了更好地滿足用戶需求提高網絡功能調度靈活性，這些微小的性能負載是可以忽略不計的。

圖7 數據中心數量對時延的影響

圖8 數據中心數量對吞吐量的影響

4.3.3 真實網絡流量測試

在本文節，在數據中心的真實網絡流量上進行了性能測試以及性能比較。根據數據中心測量工作中分析的數據包大小分布情況，生成大量符合真實數據包大小分布的流量進行測試。與最佳模式系統相比，NFVMP僅僅引入了1.8μs的網絡時延，對于真實系統部署是可以忽略不計的。兩個系統的吞吐量幾乎相同，并沒有帶來明顯性能下降。

綜上所述，對NFVMP系統從幾個方面進行了驗證工作：

正確性：NFVMP實現了數據包在多個數據中心之間的正確路徑轉發，有效地提高了網絡功能調度靈活性；

系統性能：與最佳模式相比，NFVMP在控制層以及數據層引入的性能負載極小，幾乎可以忽略不計。

5 結束語

本文設計了一個跨數據中心的網絡功能連接管理機制——NFVMP。通過理論分析，得出NFVMP的設計原則是將每個數據中心的子鏈視為一個獨立單元，并且實現子鏈生成、子鏈連接與子鏈更新。對于子鏈生成，NFVMP設計了一個子鏈生成算法用來計算所有相關數據中心的子鏈。對于子鏈連接，考慮到沒有集中控制器以及通用數據平面實現網絡功能連接，采用了分布式方法進行網絡功能靈活連接。每個數據中心通過分類器和轉發器建立與上流、下流數據中心之間的連接關系。除此之外，設計了一個增量式的策略更新算法來動態地對子鏈進行更新。基于OpenNetVM系統對NFVMP進行原型系統實現。實驗結果表明,NFVMP在多數據中心場景下能夠實現網絡功能靈活連接，其帶來的性能開銷非常微小，幾乎可以忽略不計。