前言

本文將從某運營商的一個云資源池案例淺析使用的網絡技術及原因，分享Overlay、SDN、二層DCI技術在云數據中心場景中的實際應用。

關于什么是Overlay，為什么云數據中心需要Overlay，這和云數據中心多業務多租戶的業務特性、新型網絡構架下需要大二層的特性、網絡自動化有比較大的關系，有關的信息和文章有很多，篇幅有限本文就不再贅述。

A省某運營商的資源池作為內部多業務共用的一個基礎設施，與大部分云數據中心一樣，也需要多租戶的特性、自動化的網絡、大二層特性，因此也需要Overlay技術來支撐其業務的云化發展。

先簡單介紹兩種常見的網絡Overlay的實現思路：由服務器實現的主機Overlay和由網絡交換機設備實現Overlay。

l  主機Overlay

圖1.1.▲主機Overlay圖示

如上圖所示，“主機Overlay”的隧道入口建立在服務器的vSwitch上，實現各服務器之間通過VPN來進行業務數據的傳輸。由于云計算業務一般都需要實現全網的二層互通，因此會使用VXLAN、NVGRE等L2 VPN協議。圖1.2為Openstack社區版本主機Overlay的實現邏輯。

圖1.2.▲主機Overlay結構示意

主機Overlay最主要的優點是不需要基礎網絡設備支持任何高級功能，實現與基礎網絡設備無關，TOR、Spine交換機作為該網絡中的P設備，只需要實現基本的轉發即可，表項壓力較小。而且它還是天然的軟件定義網絡，有很好的靈活性。以往被詬病最多的性能問題上，在當下網卡已經支持基本的VXLAN等隧道協議棧offload的情況下已經得到了有效的緩解。

而在裸金屬場景下，服務器無法安裝虛擬化層，但數據中心又需要將OS與網絡策略配置解耦避免安全事件，因此需要使用智能網卡脫離OS層面來提供各種vSwitch提供的隧道封裝、安全過濾、QOS的特性，但智能網卡的方案需要上層應用做開發工作，對數據中心管理者提出了較高的開發要求。

l  網絡Overlay

而另外一種方式即為“網絡Overlay”，是由交換機來實現Overlay的隧道，如下圖所示：

圖1.3.▲網絡Overlay示意

業界最主流通用的做法就是EVPN+VXLAN，其中EVPN作為控制平面，VXLAN作為轉發平面。在TOR交換機上作為隧道入口（VTEP），在整個基礎網絡上構建一個疊加網絡。

此方式最大的優勢是可以做到被接入到Overlay中業務服務器的無關，不管是虛機、裸金屬、小型機，對于接入設備來說不需要關注網絡是怎么實現的。

這里有一張圖可以借鑒MPLS網絡的思路來看分別在服務器和交換機上實現Overlay思路上的區別：

圖1.4.▲MPLS思路理解Overlay實現方式

以MPLS的思路，可以將主機Overlay中vSwitch理解為PE設備，負責封裝隧道和維護控制面，而網絡交換機均為P設備，僅負責轉發。

網絡Overlay可以理解為，Leaf交換機承擔了PE的功能，負責封裝隧道和維護控制面，而上層的Spine交換機為P設備，僅負責轉發，服務器中的vSwitch則在此時承擔MCE的功能。

l  A省某運營商云資源池案例

對于A省某運營商資源池來說，其接入的服務器種類較多，還沒有辦法完全做到所有的服務器全部為虛擬化服務器，其中不乏裸金屬服務器等一些其它還不能云化的服務器。因此，采用主機Overlay無法覆蓋到所有設備。而智能網卡方案對于非研發型運營者來說技術復雜度過高。

因此，該案例中，客戶的實際部署方案為網絡Overlay，使用交換機實現Overlay和SDN，將虛機、非虛擬化服務器接入無差別。

l  SDN如何在云數據中心里發光發亮

SDN在云數據中心里是干什么的？這個要從云計算說起，我們先來看下面一組場景：

A研發部門的老林需要開一個虛機，傳統未云化的情況下的流程是這樣的：

這個流程的時間周期一般為N小時-N天不等，如果需要什么變更，這個流程可能還要再走一遍。資源使用者效率低，運維管理人員工作量也很大。

在實現資源池化后，企業內部完全可以像在阿里云、AWS一樣，自助開通管理自己的虛擬機，還能擁有一個可自行管理的獨立網絡環境，以滿足業務、研發部門的各種IT支撐需求。

如果不實現網絡的自動化、自助化，用戶就無法獲得一個獨立可管理的網絡環境，資源池化的效率及成本收益會大幅度減少。

A省某運營商作為一個IT業務密集型大型國企，云化技術可以大幅度提升其內部IT支撐的服務效率，亦可大幅提高其IT資源的利用率。因此在其資源池中采用SDN技術，通過軟件編程實現網絡自動化，就顯得非常重要。

l  哪種SDN實現手段更適合云數據中心？

在SDN這個概念中，也有著各種實現方式，比如Openflow、Netconf、OVSDB等在網絡設備上實現SDN的方式，也有通過RPC、Openflow、OVSDB等方式控制vSwitch的主機Overlay的實現方式。具體應該采用主機Overlay還是網絡Overlay，本文第一章已經做了淺析。

在云數據中心中已經確定采用網絡Overlay的情況下，選擇哪種實現SDN的網絡設備管理協議的實現方式？

業界大部分采用網絡Overlay的云數據中心，包括A省某運營商的云資源池均采用了Netconf“下發配置型”的SDN實現方式加上EVPN作為VXLAN的控制平面。其中表項維護由BGP負責，配置變更由Netconf進行下發。

為什么不采用Openflow等可以對網絡轉發進行直接控制維護的SDN方式呢？

問題在于Openflow這種純粹的集中控制、分布轉發，并且精細到控制每條流的SDN實現方式對于云數據中心的網絡自動化的需求并沒有過人的收益。反而在某些場景下，大量的流表可能會導致控制平面的瓶頸，因此導致該技術存在著對控制器要求過高，可靠性不足的問題。

而脫胎于MPLS思想，采用分布式控制、分布式轉發的成熟、可靠、可擴展理念的EVPN技術，輔以不會對控制平面造成巨大壓力或者不可靠因素的“下發配置型”Netconf技術的SDN實現方式，將更加切合可靠性為第一要素云數據中心場景。

l  A省某運營商云資源池SDN實踐

A省某運營商的云資源池中有大量對外服務型業務，其中不乏重要業務，可靠性自然是重中之重，因此選擇Netconf+EVPN作為SDN網絡控制平面是符合其業務需求的選擇。

圖2.1.▲SDN對接邏輯示意

客戶實踐中選擇基于Openstack開發的商業產品作為其云管平臺，部署SDN控制器與Openstack進行對接，Openstack通過SDN控制器對交換機、防火墻、負載均衡設備進行自動化控制和業務編排，實現其云計算業務的自動化和自助化，大幅度提高業務開通和變更效率

l  多種L2 VPN技術選擇

不同的數據中心之間需要一個L2 VPN是一個常見的需求，用以滿足虛擬機動態遷移提高資源靈活性、容災等業務需求。而跨數據中心部署需要一個橫跨兩個甚至多個數據中心的二層網絡。

L2 VPN技術的傳統方式包括VPLS、OTV（廠家私有技術）等，其中VPLS要求整個鏈路上的設備都需要支持和部署維護，另外VPLS存在以太網本身泛洪影響面過大的問題，在DCI場景下這些問題就會被放大很多倍。而OTV是一個解決了很多VPLS問題的協議，配置維護起來也非常便捷，但其是一個廠商私有化的協議，沒有被廣泛使用。

使用EVPN VXLAN來實現DCI的二層互聯是一個新的選擇：VXLAN可以同時支持L2\L3的VPN，EVPN控制平面使用BGP路由傳遞MAC信息，也可以解決VPLS中存在的很多小毛病。

l  VXLAN實現云數據中心L2 DCI的多種方法

VXLAN來實現使用數據中心間L2 DCI根據場景不同也有多種方法可以選擇，常見兩種方式為VXLAN L2 Mapping和VLAN Hand-off 的方式。

VXLAN L2 Mapping：

VXLAN L2 Mapping的實現方式如下圖所示：

圖3.1.▲VXLAN L2 Mapping原理圖示

l  這種方式對比傳統的VPLS、裸纖直通的方式的優勢包括：

l  對比兩個數據中心TOR之間直接用VXLAN互通方案，可以將兩個數據中心網絡設備中的VNI規劃及運維規劃解耦，并大幅度減少TOR作為VTEP時的硬件資源消耗。

l  對比OTV等私有協議，EVPN VXLAN為開放協議，具備跨廠商異構部署的優勢。

VLAN Hand-off：

除使用VXLAN L2 Mapping，另一種方式是采用VLAN Hand-off的方式：

圖3.2.▲VLAN Hand-off原理圖示

這種方式是使用獨立的2組或多組交換機建立一個與數據中心內部網絡無關的DCI層。DCI層上的交換機之間通過EVPN VXLAN建立隧道，需要互聯的數據中心出口將VXLAN映射為VLAN后通過DCI層與對端的對應VLAN互通。

VLAN Hand-off 的優勢除VXLAN L2 Mapping 中所描述的對比優勢之外，其組網也非常靈活，對原有數據中心網絡及設備要求更低，并且還可以通過DCI來引入一些公共的外部資源。

l  A省運營商資源池的實踐

A省運營商云資源池因歷史原因存在著部分原有以傳統煙囪方式建設的機房和使用EVPN VXLAN的機房進行互聯互通需求，并且由于集采周期會導致每年入圍的數據中心廠家都有可能不一樣，因此需要一種“解耦”的方式來實現數據中心之間的二層互通。另外直接拉裸纖擴展性差，采用VPLS、私有協議的方式對整體網絡和設備要求過高。因此最終采用VLAN Hand-off方式，構建一個DCI層，實現其多個使用VXLAN的云資源池和原有傳統組網技術網絡之間的二層互通，并且采用SDN控制器及與云平臺互通，實現資源池間DCI互通策略自動化下發。

技術的選擇是由業務驅動的，也許再加上一點其它客觀因素，但每個行業有其獨特的業務背景、每個場景有其特性、每個網絡都有其歷史、管理和運營人員也都有其不同的技術風格和習慣。因此，本文的案例也不代表這些技術在其它類型的云數據中心就一定適合，但希望能通過本文可以讓大家對這些技術和背后的需求有更多的理解，也希望能夠有所幫助和啟發。

如有興趣想要更深入了解云數據中心的真實案例可以關注下一篇《從實戰淺析運營商云資源池網絡—解析流量模型》