作者：Umberto Manferdini 譯者：TF編譯組

最近我參與了一個專案，我們在Tungsten Fabric（ 注：原文為Contrail，本文將以功能一致的Tungsten Fabric替換）叢集中部署了虛擬行動網路。移動鏈虛擬網路的功能類似於Packet Gateway和TCP最佳化。

同時，該專案還使用另一個SDN解決方案部署和測試了相同的應用程式鏈。Tungsten Fabric是L3 SDN解決方案，而另一個是L2 SDN解決方案。

於是有個大問題跳了出來：哪個方案更好？

如何看待pps效能資料

通常，我們傾向於透過效能來回答這個問題。例如“嗯，A方案可以達到10M pps，而B方案只能達到7M pps，所以……”。

毫無疑問，這很重要，它會對整體解決方案產生影響。例如，如果一種解決方案比另一種快兩倍，則可以將虛擬機器的數量減少一半（假設虛擬機器可以處理所有流量），從而節省了伺服器，減少了要管理的裝置數量，縮減了許可費用（取決於許可模型）等等……

是的，pps所代表的效能很重要，而且將永遠如此……但是，這並不是全部！

我認為，在某些情況下，pps所代表的的效能會變得根本不重要。

考慮在某個計算節點上的情況。通常，你會將它透過以鏈路聚合（LAG）方式多歸屬到兩個葉子節點（Leaves）的鏈路連線到IP Fabric。該LAG鏈路為你提供的總頻寬為N*X，其中X是你使用的介面型別（通常為10G或40G）。假設我們使用由2x10G製成的LAG。還要考慮平均資料包的大小（700B）。

現在，A方案可以達到10M pps效能。透過一些簡單的數學運算，我們得到10^7 pps * 7 10^28 b = 56 Gbps！很高！B方案僅達到7M pps，從而提供約39 Gbps的頻寬。在這種情況下，多出來的3M pps將不起作用。因為兩種方案都能填充我的LAG，這對我來說足夠了……至少在使用平均資料包大小的情況下是這樣。

如果是比較小的資料包（46B），則A方案將達到3.6 Gbps，B方案B僅為2.5 Gbps。這裡，我們離LAG 100％的利用率還差得很遠，因此pps就更為重要。但問題是，我們是否有必要考慮只有小資料包的網路？

我們應該確定平均資料包大小，並檢視使用這兩種解決方案的速度。如果兩者都允許達到100％的LAG利用率，那麼比較pps並不能幫助我們確定最佳的SDN解決方案。

“僅僅看原始效能數字還不夠”，於是我開始思考其它方面起什麼作用，並且是否可以告訴我們A方案和B方案哪個更好。

為了解決這個問題，我分析了體系架構的各個方面，並從“解決方案角度”而非“純粹效能角度”進行了研究。

Overlay的角色

Tungsten Fabric透過overlay mesh在計算節點之間執行，並且連往SDN閘道器。MPLSoUDP 或 VxLAN隧道用於承載VM流量。

這些隧道將傳送到虛擬機器或從虛擬機器發出的實際流量“隱藏”起來。在vRouter內部，每個虛擬網路均配置為眾所周知的VRF。就像經典VPN一樣，向每個VRF分配MPLS標籤，並且VM資料包以封裝在DC Fabric中的方式傳播（MPLSoUDP是新的MPLSoMPLS，而IP Fabric是新的主幹）。

結果，IP Fabric看不到實際的流量，它只能看到MPLSoUDP（或VxLAN流量）。在這些資料包內部，透過不同的MPLS標籤標識了不同的虛擬網路，但這對fabric是完全透明的。

從fabirc的角度來看這意味著什麼？主要是，你只需要配置與Tungsten Fabric資料平面網路關聯的單個VLAN。在這個VLAN內有MPLSoUDP，正如我們所說，它隱藏了所有虛擬網路。

與之不同的是，其它的SDN解決方案使用了另一種方法。不同的虛擬網路作為不同的VLAN退出計算節點。計算節點面向fabric的介面，就像一個經典的中繼埠。這意味著每個虛擬網路都成為IP Fabric上的一個VLAN。沒有overlay隱藏這種“複雜性”，一切都在那裡！

歸根結底，VM和SDN GW之間的端到端通訊在兩種情況下均有效，但成本又是多少呢？

成本與效用

不要僅僅考慮端點是否可以通訊，還要考慮一下配置工作和服務建立的工作量。

透過使用Tungsten Fabric，你可以一開始就在fabric上建立控制資料平面VLAN。然後，在建立移動鏈時，不需要在fabric上進行任何更改。

另一方面，在沒有Tungsten Fabric的情況下，每次建立新服務（移動鏈或其它）時，都必須在SDN和IP Fabric上都配置網路。

這意味著複雜性增加，出錯的機率增加，需要更多的工具實現自動配置（除非你可以接受手動配置fabirc……使用Tungsten Fabric時不建議你這麼做），並且通常來說，業務投產並開始從中盈利的週期更長。歸根到底，錢永遠是很重要的事情。

這是第一個方面，它幫助我們理解了，當我們以超越純pps數值來看問題時，兩個SDN解決方案會有怎樣的不同。

我說過計算節點使用LAG連線到IP Fabric。理想情況下，你是希望在LAG成員之間平衡流量的。

使用Tungsten Fabric時，這已經是事實了，我們能夠在測試過程中觀察到它。

相反，另一個SDN解決方案使用LAG模式，其中基於源地址對傳出流量進行雜湊處理。結果，這導致了流量的不均衡。這也意味著不可能完全利用所有LAG頻寬。

從這個角度來看，實際的pps數量的影響甚至更小，甚至不可能100%地使用LAG。

比較結果表明，Tungsten Fabric解決方案能夠提供更好的資源利用率，這意味著整個DC基礎架構的投資回報率更高。

路由功能的不同

正就像我們在電信雲中一樣，處理移動核心應用程式時，虛擬機器不是通常在企業中的那種虛擬機器：Web伺服器、資料庫、前端等……用例不同，因此工作負載也不同。這裡的虛擬機器使用所需的路由！路由對於交換路由並提供快速收斂至關重要。例如，P-Gateway需要路由至通告地址池。

Tungsten Fabric原生使用BGP：它使用BGP進行內部通訊，使用BGP與SDN GW進行通訊，並且將BGP與虛擬機器一起使用。最後一個用例通常稱為BGPaaS，在VM和vRouter之間建立BGP會話。

這是可能的，因為Tungsten Fabric是L3 SDN控制器，因此它具有L3功能並且可以識別L3。

那麼，L2 SDN解決方案又有什麼不同？

讓我們考慮一個用例：SGi網路。該網路是P-Gateway出口網路。該網路又連線到移動鏈的下一個元素：在我們的示例中，是TCP最佳化VNF。

P-Gateway透過BGP通告使用者池……但是去到誰那裡呢？

在Tungsten Fabric當中，P-Gateway透過BGPaaS與TF建立BGP會話。BGPaaS還用於透過TF和TCP最佳化器之間的另一個BGPaaS會話，將這些路由重新發布到TCP最佳化器。

一切都在Tungsten Fabric內部解決和管理了……請記住這一點。

同樣的問題，其它解決方案又是如何面對的呢？

由於VNF的限制，無法在P-Gateway和TCP最佳化器之間建立直接會話。結果就是，需要有中間對等節點。由於這是虛擬機器之間的對話，因此客戶不想讓流量流出fabric……因此fabric必須進行路由。這意味著在Spine裝置上配置BGP。此外，為了最佳化流量，P-Gateway傳送了數千條“小”路由，所有這些路由都需要在Spine上儲存和管理。

將路由功能遷移到Spine，意味著給本來不作為這個目的的裝置帶來巨大負擔。Spine應該是簡單地轉發資料包的交換機。在這種情況下，它變成了一個路由器……但是它效能足以成為路由器嗎？如果你購買了效能優異的路由器，那麼答案是肯定的。而這意味著增加CAPEX，並且花了更多的錢購買功能更強大、價格更高的裝置來作為Spine。這是可以接受的嗎？沒有絕對的答案，但我認為多數時候是“不”會是一個正確的答案。

另一方面，使用Tungsten Fabric時在fabric上看不到路由：只是在帶Tungsten Fabric隧道的單個VLAN上轉發資料包。所有這些“小”路由仍然存在，但它們只存在於vRouter上（vRouter作為一種L3裝置比交換機更適合這一場景）。那些“小”路由將被進一步通告給SDN GW——這是一個非常合理的路由器，對嗎？

配置上的差別

如圖所示，在使用Tungsten Fabric時，fabric不參與到控制平面。利用TF內部訊號機制，一切都在Tungsten Fabric級別進行管理。

從fabric上卸下控制平面還意味著更容易建立服務。就像我們之前談論VLAN時所說的那樣，建立服務時不需要在fabric上進行其它配置。整個服務是透過簡單地定義一個列出所需虛擬資源的模板（Heat模板）來建立的。如果沒有Tungsten Fabric，則需要在fabric上同時具有Heat模板和其它配置……以及我們之前提到的所有後果和考慮因素。

類似的路由考慮因素都可以對SDN GW執行。在這裡，我們考慮的是TCP最佳化器的出口側，它釋出地址池給SDN GW（此處Fabric僅提供L2）。

如果沒有Tungsten Fabric，則需要配置多個BGP會話（N個TCP最佳化器和M個SDN GW，即N*M個BGP會話）。

而在Tungsten Fabric當中，我們可以利用控制節點和SDN GW之間的基礎設施BGP會話。在這個會話中，Tungsten Fabric為其所有的虛擬網路釋出路由。然後，SDN GW根據VRF中已配置的路由目標將其匯入（記得嗎？Tungsten Fabric只是DC中的VPN ...）。

這個過程將會是這樣的：VM透過BGPaaS將路由釋出到Tungsten Fabric，然後TF透過單個BGP會話將路由重新發布到SDN GW。如果你新增了更多虛擬網路或更多BGPaaS會話，與SDN GW的會話數量也不會改變：始終為1！

在這種情況下，差異不在於配置的大小層面。兩種情況下，你都需要在SDN GW上進行一些配置：是配置一堆VRF，還是一堆路由例項和BGP會話。

此處的區別在於SDN GW上執行的BGP會話的數量，這可能會影響我們所不能低估的可擴充套件性。

我們可以看到，Tungsten Fabric和SDN GW之間只有一個BGP會話，而在vRouter和TF控制器之間有多個XMPP（類似BGP協議）。的確如此，但這是Tungsten Fabric體系架構的一部分。Tungsten Fabric啟動並執行後，它將自動處理所有這些XMPP內容，對使用者是完全透明的。

從運營人員的角度來看，你只需配置一次Tungsten Fabric-SDN_GW BGP會話，然後就可以在部署應用程式時建立BGPaaS物件。

運營的視角

到目前為止，我們已經看到了Tungsten Fabric在服務提供及配置上的優勢。當然，SDN解決方案也可以從實際運營的角度進行比較。

為了獲得更高的效能，計算節點使用DPDK進行部署。

沒有Tungsten Fabric的話，很難監視特定的虛擬機器介面。

那麼，如果使用Tungsten Fabric，將有一組cli工具，包括類似tcpdump的工具，它們可以識別在dpdk埠上執行的特定VM埠並嗅探透過該埠的流量。

在故障排除的情景中，使用Tungsten Fabric的解決方案會更加友好。

故障排除還包含映象實現的問題。

TF vRouter支援內建映象。你可以在一個給定的虛擬機器介面上有選擇地映象資料包，並將該流量傳送到外部分析器（DPI）。

如果沒有Tungsten Fabric就沒法實現了，映象不得不依賴在IP Fabric上配置的臨時解決方案。這意味著給IP Fabric加上了額外的負擔，增加了其整體複雜性。

運營不僅意味著進行故障排除，還意味著監視叢集中發生的事情。

除了OpenStack本地提供的所有元素外，Tungsten Fabric還提供了一個名為Analytics的元件，該元件透過REST API為運營人員提供了大量資訊，並能夠實時接收警報，以便在出現問題時迅速做出反應。

這有助於在Tungsten Fabric基礎架構上實現更好的控制。

在這種情況下，基於Tungsten Fabric的SDN解決方案，實際上豐富了由另一個基於L2 SDN的解決方案提供的工具集。

總之，從更廣泛的角度比較這兩種解決方案，得出了一些有趣的觀點。

Tungsten Fabric允許使用更薄的IP Fabric——只需要較少的配置更改，並且可以更加專注於其主要目標：以無阻塞並且冗餘的方式轉發資料包。

此外，所有與應用程式相關的路由都從fabric上移除了，避免了購買更昂貴的交換機來滿足路由所帶來的需求的風險。

節省CPAEX也可以節省OPEX，因為它具有“更穩定的fabric配置”，所需的時間更少。

由於所有配置都只限於Tungsten Fabric和SDN GW（如果需要），因此可以更快地實施服務。

同時，基於Tungsten Fabric提供的其它工具，故障排除和監視整個基礎設施變得更加容易，這使運營工作更加輕鬆，因為不再需要為所有事情構建或購買定製化工具，而又降低了成本，。

“哪種解決方案更好？”一個看起來很簡單的問題，實際上包含了很多方面和考慮因素，僅僅比較原始pps數值的做法極易產生誤導。

以上，我主要介紹了由Tungsten Fabric的優點和Tungsten Fabric驅動的解決方案提供的優勢。我是站在TF一邊的，所以，我得承認我並不是中立的。

無論如何，我想表達的核心觀點是，對比涉及整個DC的SDN控制器之類的複雜解決方案，或者不限於此的方案，不能簡化為僅對pps數值進行簡單比較。