1 介紹
網(wǎng)絡(luò)功能(NFs),或中間件是以復(fù)雜方式檢測和更改數(shù)據(jù)包和流的系統(tǒng)。比如:入侵檢測系統(tǒng)(IDSs),負載均衡器,緩存代理等。NFs在確保安全性,提高性能和提供其他新網(wǎng)絡(luò)功能方面起著關(guān)鍵性的作用。
最近,我們發(fā)現(xiàn)利用運行在通用計算資源上的基于軟件的NFs來替代專用網(wǎng)絡(luò)功能硬件越來越引起人們的興趣,即被稱為網(wǎng)絡(luò)功能虛擬化(NFV)的趨勢。同時,SDN被用來通過適當(dāng)?shù)腘Fs引流,從而執(zhí)行決策和共同管理網(wǎng)絡(luò)和網(wǎng)絡(luò)負載。
結(jié)合NFV和SDN可以實現(xiàn)一類重要的管理應(yīng)用,這類應(yīng)用需要在多個網(wǎng)絡(luò)功能實例(如網(wǎng)絡(luò)負載均衡,彈性網(wǎng)絡(luò)伸縮)之間進行動態(tài)分組包處理。在此類應(yīng)用場景下,“NFV+SDN”可以幫助實現(xiàn)以下三個重要目標:(1)、在NF性能和可用性方面滿足嚴格的服務(wù)等級協(xié)議(SLAs);(2)、精確地監(jiān)控和處理網(wǎng)絡(luò)流,比如,對所有包含惡意軟件的網(wǎng)絡(luò)流,IDS都應(yīng)該報警;(3)、最小化NF運營成本。然而,目前同時實現(xiàn)三個目標是不可能的,從根本上說需要比“NFV+SDN”能提供的更多的控制功能。
要知道為何?我們考慮這樣一個場景,一個IDS過載,為了在吞吐量上滿足SLAs,必須進行網(wǎng)絡(luò)擴展(圖1)。通過NFV,我們可以輕易地創(chuàng)建一個新的IDS實例,通過SDN,我們可以將一些正在進行的流網(wǎng)絡(luò)路由到新創(chuàng)建的實例。然而,由于內(nèi)部NF狀態(tài)是不可見的,可能發(fā)現(xiàn)不了攻擊。為了解決這個問題,SDN控制應(yīng)用可以等待現(xiàn)有流的終止,且只重新路由新的流,但這樣就延遲了過載的緩解,并且增加了破壞SLA的可能性。由于一些NF內(nèi)部狀態(tài)的不可復(fù)制或共享性,NF精確度也可能被破壞。
?
圖1 需要擴展和負載均衡來滿足吞吐量的SLAs和最小化運營成本的場景
在這個例子中,為了避免NF精確度和性能之間的權(quán)衡,唯一的辦法就是允許一個控制應(yīng)用能快速并且安全地對一些流的內(nèi)部IDS狀態(tài)從原始實例轉(zhuǎn)移到新的實例,同時更新網(wǎng)絡(luò)轉(zhuǎn)發(fā)狀態(tài)。類似的需求也出現(xiàn)在其他依賴動態(tài)重分配和分組處理的應(yīng)用場景中,比如,快速升級NF和遠程處理的動態(tài)調(diào)用。
在本文中,我們提出一種控制平面架構(gòu)OpenNF,它提供內(nèi)部NF狀態(tài)和網(wǎng)絡(luò)轉(zhuǎn)發(fā)狀態(tài)的高效、協(xié)作控制,使得NF實例之間的流能夠快速、安全和細粒度的重分配。采用OpenNF,運營商能夠創(chuàng)建豐富的重分配處理控制應(yīng)用,這些應(yīng)用能最佳地滿足性能、可用性、安全性和成本目標,這樣就避免了麻煩的權(quán)衡決策。
設(shè)計OpenNF的三個主要挑戰(zhàn)如下:
C1: 解決競爭條件。這是重分配在線流時產(chǎn)生的最基本問題:當(dāng)一些內(nèi)部NF狀態(tài)被轉(zhuǎn)移時,數(shù)據(jù)包可能在轉(zhuǎn)移開始后到達源實例,或者在狀態(tài)轉(zhuǎn)移完成之前到達目的源。除非特別小心,不然,基于這些可能丟失的或者亂序的數(shù)據(jù)包來更新NF狀態(tài),破壞了轉(zhuǎn)移安全性。同樣地,當(dāng)從NF實例間復(fù)制狀態(tài)時,同時發(fā)生的更新可能導(dǎo)致狀態(tài)不一致,這些問題都可能降低NF的精確度。
為了說明競爭條件,我們引入兩個新的結(jié)構(gòu):(1)、一個從外部觀察的抽象事件,防止內(nèi)部NFs的本地狀態(tài)改變。(2)、一個用于更新網(wǎng)絡(luò)轉(zhuǎn)發(fā)狀態(tài)的兩階段方案。我們展示了如何將兩者結(jié)合起來以確保狀態(tài)更新不會丟失,或者在狀態(tài)轉(zhuǎn)移時重新排序和共享狀態(tài)保持一致。
C2:限制開銷。第二個問題是保證重分配是高效的。NF實例之間的狀態(tài)轉(zhuǎn)移和共享會消耗NF CPU和網(wǎng)絡(luò)資源。此外,為了避免丟失,重排和狀態(tài)不一致,需要數(shù)據(jù)包緩沖,這會引入延遲和內(nèi)存消耗。如果這些性能和資源消耗是無限制的,就無法滿足嚴格的SLAs和有限的運營成本。
為了限制開銷,我們提出了一個靈活的北向接口,用于控制應(yīng)用明確地指定哪些狀態(tài)進行轉(zhuǎn)移,復(fù)制和共享,以及哪些保證執(zhí)行(例如,無損耗)。
C3:以最小變化適應(yīng)各種NFs。最后一個問題是確保我們的架構(gòu)能適應(yīng)以大量非入侵方式的各種各樣的NFs。給NFs提供接口來創(chuàng)建/更新狀態(tài)是一種方法,但是這種方法限定了內(nèi)部NFs轉(zhuǎn)態(tài)的結(jié)構(gòu),可能也不適合需要一些數(shù)據(jù)包處理邏輯的狀態(tài)分配/訪問。相反,我們?yōu)镹Fs設(shè)計了一種新的南向接口,允許控制器請求NF狀態(tài)的進出口,而不改變NFs內(nèi)部是如何管理狀態(tài)的。
我們使用Floodlight實現(xiàn)了我們的北向接口API,利用這個API,我們開發(fā)了幾個控制應(yīng)用。我們也增加了四個NFs—Bro, Squid, iptables, 和PRADS,用于支持南向接口API。
? ? ?
我們對OpenNF評估表明:(1)、OpenNF可以消除虛假警報,并且和使用電流控制框架需要的數(shù)十分鐘相比,我們能及時縮減NF規(guī)模;(2)、狀態(tài)可以高效地轉(zhuǎn)移,復(fù)制和共享,即使是需要一些特定的要求,比如:對于500規(guī)模的流進行無丟失狀態(tài)轉(zhuǎn)移,在這個操作過程中,只需要215ms加上50ms的包接收延遲;(3)、添加對OpenNF南向接口API的支持,最多只增加9.8%的代碼量,在NFs狀態(tài)進出的過程中,包處理時間增加將少于6%。
2 為何使用 OpenNF?
當(dāng)分組處理是被一個NF的多個實例統(tǒng)一進行處理時,NF的部署通常需要滿足以下三個重要目標:(1)、在性能和可用性上滿足嚴格的SLAs——比如,大部分時間的總吞吐量應(yīng)該超過1Gbps,用于處理流的宕機時間應(yīng)該少于10分鐘/每年;(2)、精確地監(jiān)控和處理網(wǎng)絡(luò)流量,比如,對所有包含惡意軟件包流的HTTP流,IDS應(yīng)該發(fā)起警報,RE解碼器應(yīng)該能夠正確地恢復(fù)由RE編碼器消除的冗余;(3)、最小化運營成本。例如,當(dāng)不需要額外的容量時,資源應(yīng)該關(guān)閉。
目前,同時實現(xiàn)這三個目標是不可能的,除了結(jié)合NFV和SDN能提供的功能之外,我們需要更多的控制機制。下面,我們描述若干個具體實例,并突出以上三大目標是如何轉(zhuǎn)化成控制平面需求的。我們也會討論當(dāng)前的一些NFV和SDN控制框架,以及如何簡化和增加它們以滿足需求。
2.1 動機實例
總是選擇最新的NFs。為了最大程度的保證安全,移動手機用戶可能希望本次的數(shù)據(jù)能夠被最新的NF軟件處理。舉個例子說,SLA要求流量每年被過時的NF實例處理的時間不超過10分鐘。幸運的是,NFV允許在我們幾毫秒內(nèi)使用更新的NF實例,同時SDN允許我們在相同的時間內(nèi)重新路由到那個更新的NF實例。然而由于缺少新實例的內(nèi)部NF狀態(tài),這種簡單重路由流量可能會降低NF準確性:舉例來說,將一個活躍的HTTP流重新路由到一個新的IDS,由于缺少流中先前報文的原數(shù)據(jù),會造成入侵檢測系統(tǒng)錯過對一些惡意軟件的檢測。為了克服這個問題,我們可以等到正在處理的流終止,只對新的流重新路由。然而,由于流的持續(xù)時間是不受控制的,這個方法不能保證滿足SLA,舉個例子,蜂窩網(wǎng)絡(luò)中超過40%的流的超過10分鐘。同時滿足SLA協(xié)議以及維持網(wǎng)路功能正確性的唯一方法就是控制面提供將NF狀態(tài)和它的更新轉(zhuǎn)化為網(wǎng)絡(luò)傳遞狀態(tài)的功能。此外,操作必須在限定的時間內(nèi)完成。
為了保證NF在狀態(tài)傳輸期間以及狀態(tài)傳輸之后的正確(目標2),沒有數(shù)據(jù)包或者更新在傳輸過程中丟失以及沒有重新排序的更新發(fā)生是很重要的兩點。舉個例子,IDS對一個復(fù)制的報文處理,此時如果一個復(fù)制的流量在狀態(tài)傳遞時丟失,IDS實例將沒有機會請求重傳該報文。這個可能會導(dǎo)致沒有進行安全報警,因為IDS在一個連接上僅僅收到部分用于惡意軟件檢測的數(shù)據(jù)。同樣的,IDS可能會錯誤報警如果它沒有按順序收到請求建立報文(SYN)和數(shù)據(jù)處理報文。因此,控制面必須提供對于諸如無損傳輸和順序保持傳輸?shù)闹匾WC。(我們將在5.1節(jié)正式定義無損傳輸和保持順序)。
高效的網(wǎng)絡(luò)控制。移動電話用戶也很關(guān)心網(wǎng)絡(luò)的性能。舉個例子,SLA可能要求NF部署吞吐量在大多數(shù)時刻超過1Gbps。由于數(shù)據(jù)包處理的復(fù)雜性,僅僅依靠單一的NF實例去滿足SLA的要求困難太大。幸運的是, NFV允許NF在網(wǎng)絡(luò)負載增加的時候動態(tài)擴展,同時SDN允許流被重新路由到新的NF。然而,正如在第一個方案中說的那樣,流必須被快速重新路由—一直等到流的終止會導(dǎo)致網(wǎng)絡(luò)功能持續(xù)負載過重并且破壞SLA(目標1),而關(guān)于安全性,不移動內(nèi)部NF狀態(tài)的重新路由方式會降低NF的正確性(目標2).(以一種不丟失和不亂序的方式)。相似的,在事先考慮快速重路由和安全性的情況下,當(dāng)網(wǎng)絡(luò)的負載降低時,網(wǎng)絡(luò)功能應(yīng)該收縮來減少操作消耗(目的3)。為了達到這個目的,我們還是需要將NF狀態(tài)以及它的狀態(tài)更新轉(zhuǎn)化為網(wǎng)絡(luò)傳遞狀態(tài),并且這種轉(zhuǎn)化必須在限定時間內(nèi)完成并且有重要保證。
當(dāng)重新平衡負載時,我們可能要考慮到NFs用于多個流的情況。舉個例子, IDS為每個終端主機保持連接計數(shù)器。如果以主機或者子網(wǎng)為粒度,網(wǎng)絡(luò)是平衡的,一個主機所有的流經(jīng)過相同的IDS實例,計數(shù)器可以交給這個實例。然而,當(dāng)主機上的流被平衡到不同的實例,所有的實例必須有該計數(shù)器。更進一步的說,如果一個處理流的實例終止了,主機的在該實例上的流被移動其它剩余的實例上,那么這兩個實例的計數(shù)器需要合并。因此,控制面必須提供轉(zhuǎn)移、復(fù)制或者共享、以及合并到多個流相關(guān)的NF狀態(tài)。
網(wǎng)絡(luò)功能故障只占用少量資源快速恢復(fù)。當(dāng)一個NF實例發(fā)生故障時,我們可以通過重路由正在處理的流到一個正常的實例來減少故障時間。為了讓這些流能夠正確的被處理,被選中的實例必須能夠獲得關(guān)鍵的NF狀態(tài)。達到這個目的的方法之一就是為所有的NF實例周期性的備份;這對于在該NF實例的CPU和存儲帶寬的消耗不可忽略(目標3),由于各個備份之間的延時會導(dǎo)致備份中有大量的過時狀態(tài)。第二種方法只備份NF狀態(tài)更新的部分。這種方法會消除過時狀態(tài)的問題,并且資源的占用和狀態(tài)更新的頻率以及被備份狀態(tài)的數(shù)量成比例增長。為了支持這種方式,我們需要能夠復(fù)制NF狀態(tài),同時需要能夠跟蹤狀態(tài)何時以及如何更新。
基于對本地NF的前期觀察,一個企業(yè)可能想對當(dāng)前正在處理的流的某個子集進行更深層次更高級的處理(目標2的變體)。舉個例子,當(dāng)IDS檢測到內(nèi)部的主機正在向一個被列入黑名單的域名發(fā)送HTTP請求,企業(yè)要啟用對惡意軟件的分析會進行回復(fù)的數(shù)據(jù)包處理功能。由于本地IDS的資源限制,企業(yè)可能會利用云端更加強大的遠程IDS.更進一步說,為了避免將所有流量重定向到云端的帶來的消耗(目標3),其它主機的流量必須在本地處理。這個需要在先前的例子強調(diào)的特性的支持(例如將特定流的狀態(tài)無損耗傳輸)。除此之外,更高級的處理實際上需要獲得更多的狀態(tài)細節(jié):舉例來說,云端的IDS可能要為與一些已經(jīng)眾所周知的攻擊庫比較簽名,為新的流創(chuàng)建額外的狀態(tài)。因此,網(wǎng)絡(luò)控制面不能限制NF創(chuàng)建額外狀態(tài)的能力。更進一步說,如果這個被處理的流之后會傳回到原來的NF實例,那么這個額外的狀態(tài)必須要能夠被自動捕獲。
2.2 相關(guān)工作
現(xiàn)有的控制平面,如PLayer, SIMPLE, Stratos, FlowTags, 和一些連接技巧,僅僅提供控制,協(xié)調(diào)和流量轉(zhuǎn)發(fā)。如已經(jīng)討論過的,在不降低NF精度的條件下,單獨的轉(zhuǎn)發(fā)變化是不能滿足各種各樣需求目標的。
VM或者進程的復(fù)制只允許一整個地克隆NF實例。額外的,包含于克隆中的不需要的狀態(tài)不僅浪費內(nèi)存,而且更為嚴重的是能導(dǎo)致不良的NF行為。比如,IDS可能產(chǎn)生錯誤的警報。此外,這種方法阻止了多種NF實例的狀態(tài)的轉(zhuǎn)移和合并,妨礙了快速彈性收縮。由于他們固有的限制,結(jié)合現(xiàn)有的控制平面和VM遷移/過程復(fù)制技術(shù)不能滿足上述的需求。
供應(yīng)商提供的控制器在多個NF實例之間進行狀態(tài)轉(zhuǎn)移,復(fù)制和共享時,可能影響NFs的內(nèi)部工作信息。但是,他們不能以一種方式控制網(wǎng)絡(luò)狀態(tài)來滿足所有的目標。例如,很難通過網(wǎng)絡(luò)鏈路提供優(yōu)化的負載均衡。
拆分/合并和輕量復(fù)制是唯一提供一些對內(nèi)部NF狀態(tài)和網(wǎng)絡(luò)狀態(tài)控制的系統(tǒng)。他們提供一個共享庫,NFs使用這個共享庫,可通過預(yù)先定義的API來創(chuàng)建,訪問,和更改內(nèi)部狀態(tài)。編排器通過調(diào)用一個簡單的遷移操作(重新路由流f并轉(zhuǎn)移相應(yīng)的NF狀態(tài))來協(xié)調(diào)負載均衡。在輕量復(fù)制中,NF加進一些模塊來管理進出各個實例的分組流,并且根據(jù)預(yù)先定義的頻率進行狀態(tài)的克隆。
不幸的是,遷移操作可能會導(dǎo)致NF狀態(tài)更新的丟失和亂序,因為遷移之后到達NF實例的分組將被丟棄,應(yīng)用網(wǎng)絡(luò)轉(zhuǎn)發(fā)狀態(tài)更新和重新恢復(fù)網(wǎng)絡(luò)流之間仍然存在競爭。此外,編排器和NF模塊式針對特定問題的,使得他們不能很好地支持復(fù)雜的控制應(yīng)用。最后,NFs必須使用API來創(chuàng)建和訪問狀態(tài),通過使用不是基于流狀態(tài)的秘鑰,使得當(dāng)流被重新路由時,很難知道存在狀態(tài)的轉(zhuǎn)移和復(fù)制。API值允許每種流一種狀態(tài)分配,需要重建一些內(nèi)部NF狀態(tài)和分組處理邏輯。我們在本文的后面章節(jié)更詳細地討論這些問題。
3 OpenNF概述
OpenNF是一種新的控制平面架構(gòu)(圖2),這種架構(gòu)滿足上述需求和挑戰(zhàn)。本節(jié)中,我們將列出關(guān)鍵思想,§4 和 §5中詳述細節(jié)。
?
圖2 OpenNF架構(gòu)
OpenNF允許控制應(yīng)用直接管理NFs的行為和性能,以滿足高標準的要求。基于NF輸出和外部輸入,控制應(yīng)用:(1)、確定特定NF實例應(yīng)該處理的流集,(2)、指示控制器提供每個實例所必須的狀態(tài),包括流特定狀態(tài)和流之間的共享狀態(tài),(3)、讓控制器提供狀態(tài)和狀態(tài)操作的特定保障。
相應(yīng)地,OpenNF控制器封裝了分布式狀態(tài)控制的復(fù)雜性,當(dāng)被請求的時候,為狀態(tài)和狀態(tài)操作保證不丟失、不亂序和一致性。我們設(shè)計了兩個新的方案來克服潛在的競爭條件:(1)、一個抽象的事件,控制器用來直接監(jiān)視狀態(tài)的更新,或者阻止更新但是知道哪些更新是預(yù)期的,(2)、一個兩階段的轉(zhuǎn)發(fā)狀態(tài)更新方案。使用前者,控制器可以確保轉(zhuǎn)移操作部丟失,和狀態(tài)副本最終的一致性。通過利用方案2中的步驟,仔細測序狀態(tài)更新或更新一致性(方案1),控制器可以確保轉(zhuǎn)移操作的不丟失和不亂序;我們在技術(shù)報告中提供了正式的證明。最后,通過緩沖與預(yù)期更新相應(yīng)的事件,并一次一個地處理狀態(tài)的副本,控制器可以確保狀態(tài)副本的嚴格一致性。
OpenNF的南向接口API為控制器定義了一個標準的NF接口,用于請求事件和內(nèi)部NF狀態(tài)的進出。通過一個出口調(diào)用,NFs用它來完成所有狀態(tài)的過濾器匹配,和確定如何將現(xiàn)有狀態(tài)和進口調(diào)用提供的狀態(tài)合并。這需要對NFs進行適當(dāng)?shù)墓δ芴砑樱P(guān)鍵的是不能限制,或者需要對NFs維持的狀態(tài)數(shù)據(jù)結(jié)構(gòu)進行更改。此外,我們使用已定義好的流的概念(比如,TCP連接)作為基礎(chǔ),來指定哪個狀態(tài)進和出。這就自然和NFs已經(jīng)創(chuàng)建,讀取和更新的狀態(tài)保持一致了。
評論