本文根據華三通信研發副總裁王颶在2014年QCon上海的主題演講《SDN控制器集群中的分布式技術實踐》整理而成。

　　目前在網絡世界里，云計算、虛擬化、SDN、NFV這些話題都非常熱。今天借這個機會我跟大家一起來一場SDN的深度之旅，從概念一直到實踐一直到一些具體的技術。

　　本次分享分為三個主要部分：

• SDN & NFV的背景介紹
• SDN部署的實際案例
• SDN控制器的集群部署方案

　　我們首先看一下SDN。其實SDN這個東西已經有好幾年了，它強調的是什么？控制平面和數據平面分離，中間是由OpenFlow交換機組成的控制器，再往上就是運行在SDN之上的服務或者是應用。這里強調兩個，控制器和交換機的接口——我們叫做南向接口；另一個是往上的北向接口。

　　SDN的核心理念有三個，第一個控制和轉發分離，第二個集中控制，第三個開放的API——可編程、開放的API接口。單純看這三個概念，我們很難理解為什么SDN在網絡業界現在這么火。這三個概念就能夠支撐起SDN的成功嗎？所以我們要探尋一下SDN背后的故事。

　　SDN背后的故事

　　其實SDN在誕生之初，我們這些做網絡的人對它不重視，最開始認為就是大學的教授搞出來的實驗室里的玩具，并不認為會對產業界有大的影響，可是幾年下來以后讓我們每個人都大吃一驚，它發展太快了。這個背后有什么呢？

　　實際上在SDN的發展的幾年當中有另外一個技術在迅速的發展，鋪天蓋地來到每個人的身邊，就是云計算。說云計算我還想跟大家分享一個小故事，我前幾天在公司準備QCon的膠片，我們公司的負責保潔的師傅說了，你做云計算啊？我說是啊，你也知道云計算？他說當然知道了，我經常用云計算，那我問他，你都怎么用的？他說上淘寶啊，經常買東西。然后我就問他了，那你知道淘寶應該算什么云嗎？其實我問他這句話背后的含義是因為，在我們這個圈子里面把云分為公有云、私有云、混合云，我想問問他，結果他的答案非常讓我震驚，淘寶你不知道嗎？馬云啊！所以我就深深的體會到了，起一個好的名字是非常重要的。

　　剛剛這個只是個笑話，體現了兩個問題：第一個就是云計算現在地球人都知道，第二個就是每個人對云計算的理解又是不同的。我給云計算下了一個定義，就是使計算分布在海量的分布式節點上并且保持彈性，這么說可能比較抽象，再說的稍微形象一點就是說使資源池化，在你需要的時候可以按需索取、動態管理。

　　當人們圍繞著按需索取動態管理做文章的時候，什么技術能達到這個要求呢？虛擬化技術。所以現在看云管理平臺，OpenStack、CloudStack也好，都是圍繞這三個方面——計算、存儲還有網絡的虛擬化做文章的。

　　在這股虛擬化的浪潮前面，計算虛擬化發展的最早也發展的最快，網絡和存儲的虛擬化就相對滯后一點。當人們把目光聚焦到網絡虛擬化的時候，人們尋找解決網絡虛擬化的方法和工具，這個時候SDN就出現在人們的視野里了。

　　剛剛講的SDN三個理念：控制和轉發分離可以使控制層面脫離對網絡設備的依賴，可以快速發展；集中控制就很方便對資源進行池化和控制；開放的API——南向和北向接口——可以催生產業鏈，推動整個產業的快速發展。

　　開放的云計算數據中心解決方案都離不開SDN，從某種程度上講，是云計算架構里面的基石，再講另外一個話題，NFV也是比較熱的話題，是網絡功能虛擬化，和剛剛我講的網絡虛擬化就差一個字母，但是實際上闡述的是兩個不同層面的概念。

　　我們講了云計算需要網絡虛擬化，實際上不是今天才有的，像我們做網絡的人都知道在很久以前人們就有這種網絡虛擬化的要求了，不過在那個時候我們管它叫VPN，虛擬專用網，以前使用的都是在一個公共的網絡上虛擬出來一個專用的網絡，讓使用者以為這個網絡就是給我專用的。

　　那么到了云計算時代，在我們討論云數據中心的時候，就不再用原先的詞了，現在說multi-tenant，多租戶，其實道理是一樣的，也是在一個公共的網絡里隔離出來各個專用的網絡。這個技術是什么？就是Overlay。數據層面看這倆技術沒有本質的區別，都是實現了數據封裝，方式就是在網上建立隧道把各個網絡隔離開。

　　回頭看NFV這個概念，就有點區別了：NFV是歐洲電信聯盟提出來的。我們知道在運營商的機房里面看到成片的服務器、存儲設備、還有大量的不同廠商不同的網絡設備，云計算的時代這些運營商也不干了，這么搞太煩了，維護起來成本高，部署起來復雜，新業務上線很慢，他就強調能不能把這個世界搞得干凈一點，機房當中只剩下三個設備：標準的交換機，標準的服務器還有標準的存儲設備，除了這些設備，其他通通消失，把所有功能挪到標準的服務器上實現，強調網絡功能的虛擬化。

　　所謂功能的虛擬化就是說把這個功能從傳統的網絡設備里拿出來。這個是歐洲電信聯盟給出的NFV的架構圖，我們看這個架構圖的時候發現，這個下面的部分稱為NFVI，就是基礎設施，進行管理和虛擬化，目標是為了在上面提供這些他稱之為VNF的功能。強調一下，這是一個一個的功能單元，這些功能單元運行在虛擬化出來的虛擬機或容器里。最右邊這一塊就是整個系統的管理。

　　我們看這個圖可能會感覺很熟悉，這個就是OpenStack的架構圖。云管理平臺玩的就是虛擬化，管理的是計算、存儲和網絡。對比前后這兩張圖我們發現，其實NFV的架構就是云計算的架構，只不過它所強調的僅僅是運行在云計算上的服務，而不像我們普通的比如Hadoop服務為了大數據，或者WEB和數據庫等等。NFV的服務都是為網絡功能服務的，包括DHCP地址分配、NAT地址轉換、防火墻、無線接入、寬帶接入、3G核心網等等，都可以用虛擬的容器實現。所以其實網絡功能和我們大家平時所熟悉的這些標準的APP或者是這些服務都是一樣的，都可以一樣的進行虛擬化和云化。

　　所以從這個層面上講，一個廣泛意義上的網絡虛擬化會看到幾個熱門技術：SDN、NFV、Overlay，都是從不同的層面支撐虛擬化——SDN定義了一種控制和管理的網絡架構，Overlay提供了一種解決數據平面轉發和多租戶隔離的技術手段，NFV指出了我的網絡功能如何借助這個架構實現虛擬化。這里就有一個循環：網絡虛擬化包含了網絡功能虛擬化，網絡功能虛擬化又依賴于云計算的架構，一旦這個循環形成了，這些新技術在彼此之間不停的碰撞，相互結合也相互競爭，也構成了我們今天這樣一個網絡世界變革的大時代。

　　SDN的部署案例

　　下面給大家介紹一下我們在SDN領域的實際的案例。

　　在講實際的案例之前，想先跟大家分享一下我們公司對未來網絡發展的一個理解。我們知道現在SDN、NFV很熱，但是傳統的網絡并不會消失，在很長的時間內這些技術會并存。我們強調一個什么概念呢？就是一個虛擬的融合架構。

　　這個圖是一個三橫三縱的結構，我們從三縱開始。最右邊就是云，解決的是計算存儲的問題；最左邊是端。有人最近提出來一個概念，說現在的網絡是云計算和移動互聯網的時代，云計算就是云，而移動互聯網就是端。對端的管理，不管是什么樣的網絡，我們最終檢驗網絡質量的標準是什么？最終用戶的體驗。如果你的網絡解決不好這個問題，你這個網絡就很難說是成功的網絡——所以中間就是云和網的結合體，就是網絡的主體。

　　我們再橫向看三層。底下一層就是基礎的設備，包括終端設備、網絡設備還有計算存儲，包括NFV虛擬出來的網絡單元也可以當成邏輯的網絡設備放這里。第二層就是所謂的融合控制層：我們認為在網絡上應該有這樣一個層次，既可以管網，也可以管云，也可以管端，這些都需要進行一定的集中控制。最上邊的一層就是所謂的資源管理層，在這個里面第一要對所有的資源進行池化，比如OpenStack這樣的管理平臺；在這個之上要提供一個業務編排的系統，把這些邏輯的分散的資源單元串在一起，才能夠為用戶提供服務；再之上就是針對不同的網絡服務提供一些管理組件。

　　這個VCF架構強調每個層次都要對上一層次提供開放的接口，最終對最上面用戶的應用提供可編程、可控制的能力。這實際上強調的是什么？就是對端和云中的應用提供了一種自動化的編排和管理的能力。

　　這么說可能比較抽象，我舉個具體的例子，比如說你的手機拿起來了要上網，當你的手機上網的時候，傳統的網絡就是AC，無線控制器做Wifi認證；但是在我們這樣一個融合架構里面，對這個手機進行認證的設備就不再是AC控制器了，而是VCF的網絡控制器。在這個網絡控制器對這個手機進行認證、允許上網以后，就知道這個手機是誰的，應該有什么權限，可以獲取什么資源，這個時候就要執行一個我們稱之為user profile的服務模板，執行之后會控制整個網絡里面所有的設備，根據這個用戶上網這一個動作，它就可以對這個用戶所需要的所有的資源進行調整。這在傳統的網絡里是很難實現的。

　　另一個例子，在云數據中心一款APP上線，一般就是VM或者是一個容器的創建。一般情況下在云管理平臺里面，容器創建的時候就要分配和指定資源，包括什么資源呢？CPU、內存、硬盤、網絡出口帶寬、還有這個服務前面要不要加防火墻、是不是大的集群中的成員前面要放負載均衡、要不要給它備份管理等等等等，這些功能實際上存在一個叫做app profile的文件里。這樣在整個云里面，不論是存儲還是計算資源還是網絡資源都被這個APP上線調動了，他會根據你預先編排好的需求，動態對所有的資源進行調整。我們以前做應用的人對網絡施加一些控制是很難的，只能對網絡管理員提出要求，讓他實現；但是現在，我們就具備一種動態管理的能力，這就是這樣一個概念帶來的一個變革。

　　所以說，我們認為VCF這樣的概念實際上就是我們對SDN這個概念的發展和補充，是我們認為未來網絡發展的趨勢。

　　像這樣一個整網融合的方案會比較大，我們真正在商用的時候往往只會使用一部分。比如說我們在給一個數據中心做方案的時候，可能重點關注于你的云和網；如果給一個城域網做方案，可能就是關注網；如果是給園區做網，就是關注端和網的管理。

　　下面我就給大家講兩個實際的案例。

　　第一個，浙江政務云。這個項目包含兩個部分，一個是公有云，一個是政務云，公有云由阿里云承擔，政務云由我們公司承建。我們看一下結構，在這個圖里面我們會發現，有計算、存儲，中間是一個由核心交換機和邊緣交換機構成的網絡把這些全部連接起來，同時還有網絡的管理控制器和云的管理控制器，之上就是iMC——一個更高層的資源編排和管理軟件。上面的OpenStack沒有直接管理交換機，而是通過往OpenStack里面注入插件，把控制功能轉給了控制器，包括云控制器和網絡控制器，然后再去管理物理的設備。這樣有什么好處呢？保留了開源云管理平臺OpenStack的開放性，第三方應用可以用同一個API來做控制；而同時因為使用了專用的控制器，效率會有進一步的提升。

　　這個專用控制器就是SDN和Overlay技術的實現，可以對外控制三種網絡角色：VxLAN VTEP控制虛擬化的vSwitch，VxLAN GW控制數據中心內的邊緣交換機，VxLAN IP GW控制對外界連接的網關——核心交換機。

　　Overlay這個技術有一個特點，就是它初始化的時候，所有節點上的流表是空的。在什么時候才形成轉發控制的能力呢？是隨著業務的部署形成的。比如說當有一個VM想跟另外一個通訊的時候，第一個報文就被vSwitch捕獲，然后分析一下，就知道應該從哪個虛機到哪個虛機，在源和目的的之間建立一個隧道下發流表，把這個初始的報文返給vSwitch，這樣就過去了。

　　這樣處理有甚么好處呢？最大的好處是節約資源。我們知道像這樣的數據中心可能有幾千或者幾萬個節點，就是幾十萬個虛擬機，如果讓任意兩個VM之間都可以通的話，大家算一下要多少的流表——這個資源是有限的。實際上不會所有的VM之間都有通訊的要求，根據業務部署可能只有很少數量的VM之間才會通信的要求，所以這樣的方案很節省流表的資源。這個方案如果說有缺點的話是什么呢，因為它的這個首包上送給了控制器，越到后期在控制器這塊的壓力就會越來越大。這個問題怎么解決我們后面講。

　　再看騰訊的這個方案。騰訊數據中心的情況是，他們自己已經有云管理平臺，有自己的vSwitch，只是需要我們的物理交換機和控制器。這個方案展開一看大家會發現跟我剛剛講的這個浙江政務云的方案其實是很類似的，也是SDN加Overlay的方案。只不過在這個方案里面，第一，不是所有的設備都是我們的，所以需要我們在我們的控制器上面有一些東西跟騰訊的云管理平臺進行對接；第二，就是規模的問題，騰訊讓我們建立這樣的數據中心到什么規模呢？物理的服務器一萬五千臺。這給我們整個管理帶來了很多的挑戰，我們怎么才能部署控制器管理一萬五千臺的服務器，幾十萬的虛機？下面講一下我們這個集群管理的部署方案以及具體的優化。

　　SDN Controller集群部署方案以及優化

　　講解控制器部署之前，我們花一點時間進入控制器軟件的內部，看看這個Controller的軟件架構。可以看到我們也用一些開源的工具，然后之后呢還有一些各種層面的模塊。我們去看一下具體的邏輯圖，可能看的更清楚一點。

　　我們把控制器分成不同的層次：最下面我們稱之為南向接口層，有OpenFlow、NetConf/XMPP、BGP等等不同的數據協議，這是因為控制器往下要管理不同的節點，這些不同的角色（vSwitch或物理交換機）使用的協議不一樣。

　　第二層是SAL適配層，這一層屏蔽了不同的廠商/不同的設備對南向提供接口的差別，讓上層的模塊運行起來可以僅僅針對他關心的業務處理，而不用關心不同廠商的API有什么差別。

　　再往上就是基礎的網絡功能模塊，這一塊沒什么說的。再往上就是內置應用。在SDN里面有兩種應用，一種是內置的應用——就運行在SDN的控制器上，還有一種外置的應用——在上面。我們看到這里有Overlay模塊：最關鍵的計算都是由這個Overlay模塊完成的。

　　再往上就是北向接口層了，就是可編程的控制器要對外提供一個良好的編程接口。

　　還有一部分就是管理層，有軟件的管理、軟件自身的升級、增加模塊，還有生命周期管理、集群的管理，還有一些UI的界面。

　　講完這個層次圖以后，回到剛剛的問題上。我們Overlay的過程——送給控制器，下發流表把這個包返回給vSwitch進行轉發，這個是一次首包上送。這個方案所造成的問題就是對控制器的計算能力提出挑戰。所以我們在這個方案里面重點優化首包上送的處理能力，對剛剛的結構不停的優化、進行重構。

　　最后我們做到什么性能呢？標準的Intel i7 4核處理器上，可以做到500k的處理能力。在這個基于Java的架構上，我想再做出質的提升恐怕就很困難了。

　　那么這一個控制器能管理多大的網絡？瓶頸在首包上送的能力，我們可以計算一下：一個服務器有1個vSwitch，跑20-30個VM，每秒大概可以產生500以上的新流，就是每秒有500次跟一個新的、不同的設備通信。那么用我們剛剛的首包上送一除就知道，500K的TPS性能，一個控制器大概可以管理一千個Host；當一個數據中心規模在15k的時候，單節點控制器肯定搞不定了，就需要控制器集群。

　　我們把所有的控制器就是稱之為一個團隊（team），一部分成員是領導者（leader），一部分是成員（member）。Leader對上提供北向的訪問接口，負責對cluster進行管理；Member就負責管理控制交換機，連接交換機的方式就是剛剛講的南向接口。

　　單一的節點可能會不安全或者是不可靠，所以就提供了另外一個東西就是Region。我們把所有的leader放在一個Region里，作為主集群，其他的作為備份，這樣就保持這個集群有一個持續的不間斷的對外提供北向接口的能力。下面這些member劃了一個一個Region，一個Region中有多個Member，Switch要同時連接到一個 Region中的所有Member上，并選取一個作為主。這樣的好處是什么呢？一個switch有多個member，如果我的主域宕掉了，這個switch發現了以后就可以從剩余的里面選擇一個新的，備變為主，這樣就可以提供一個不間斷的服務能力。

　　我們拿兩臺服務器做主，然后劃分15個Region，一個控制器可以管理一千臺的服務器，15個正好是15000臺。總的來說就是對控制器進行分層的設計，讓leader提供向北接口，member提供向南接口。

　　簡單介紹一下我們實現這個集群采用的技術。Team管理功能，是在Zookeeper之上封裝的，這個Team實現了成員管理、leader選舉、上報Team事件，具體的方式是很標準的Zookeeper使用方式，這個就不多說了。

　　那么還有一個重要的問題，不是說你的成員加入集群就完事兒了，我剛剛講騰訊的方案的時候，騰訊的云管理平臺上有大量的VM的信息，這些需要你做一個模塊抓取過來，要在你所有的控制器之間共享，所以說就需要有一些數據在所有的控制器間共享，也就是HA。按照我們做網絡的習慣，我們把HA分成兩種功能，一個是實時備份，一個是批量備份，目標就是希望這個HA系統對上述的APP是不可見的，具體看一下實現。

　　第一個就是BUS，它提供通訊的通道，當你寫入一個數據的時候，就在主那里創建一個單元，發現這個節點發生變化，就把這個單元讀出來，這個數據就傳過去了。

　　KeyStore，實現了一個非常簡單的數據庫功能，采用Key-Value機制，不支持范圍查找，只提供了設置和獲取接口，沒有通知接口。有的同學會問了，說你們跟Zookeeper干上了是吧？那我們做開發的人都知道，當我們熟悉一個工具的時候，就會很自然的重復使用，盡量用熟為止。

　　實際使用當中的實時備份過程就是這樣的，很簡單，集群中某個成員業務數據變化時，發送bus消息通知其他成員，同時將本成員的運行數據以key&value的形式保存在KeyStore中。

　　批量備份就是當新的控制節點加入時，KeyStore就會自動將其他節點的數據備份到本地，App需要先從KeyStore中恢復數據，當恢復完成后，再開始接收bus消息。做keyStore數據恢復時，要求bus可以從批備開始的時間點開始緩存bus消息，等恢復完成后補報這些bus消息，這樣就可以保證了最終數據的同步。

　　今天跟大家分享的話題就到這里，謝謝大家！