萬臺規模下的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訊息，這樣就可以保證了最終資料的同步。

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

嘉賓簡介

王颶，華三研發副總裁，從事資料通訊裝置軟體開發長達14年，作為資深的網路協議專家和軟體系統架構師，熟悉多個層面的資料通訊協議，擅長做通訊協議設計以及實現，對嵌入式系統和複雜軟體系統設計，以及對實時系統的效能優化有著十分豐富的經驗。此外，對網路安全有著比較深入的研究，對各種網路攻擊和防護有著豐富的經驗。近年來開始關注並投入SDN相關領域的研究和開發。對OpenStack、OpenDaylight、OpenVswitch、NFV等都有一定的研究，對雲端計算時代的網路通訊有著深刻的理解。

在這個雲端計算的時代，很多傳統的通訊技術都會經歷一個痛苦的解構重建的過程，如何把已有的網路經驗融合到現在的SDN世界當中，充分利用歷史的積累，是他目前最為關心的問題。