人們提到SDN，邏輯往往是這樣的：控制和轉(zhuǎn)發(fā)平面分離，由于有了SDN控制器的中心控制，我們可以做各種天花亂墜的事情。那么SDN控制器和交換機之間是通過怎樣的網(wǎng)絡(luò)進行通信的呢?一個與之相關(guān)的更大的問題是：作為一個完整的SDN解決方案，我們應(yīng)該如何規(guī)劃Management Network呢?這個問題也是所有客戶最關(guān)心的前三個問題之一。博主想通過這篇文章拋磚引玉，聊聊在設(shè)計數(shù)據(jù)中心Management Network時要考慮的問題。

在沒有SDN和orchestration系統(tǒng)之前，數(shù)據(jù)中心里往往只需要兩張網(wǎng)：management network和data network。前者用于讓管理員登陸到各個設(shè)備上進行配置，后者用于轉(zhuǎn)發(fā)業(yè)務(wù)流量。本文不會涉及任何關(guān)于power network和console port network的討論，因為那已經(jīng)是太成熟的技術(shù)了。在orchestration系統(tǒng)大行其道的今天，網(wǎng)絡(luò)的規(guī)劃變得復(fù)雜了很多。

我們不妨腦補一下這樣一個場景：一個數(shù)據(jù)中心的租戶連接到Openstack的GUI[1]，在GUI上配置了一個network和一臺VM，這臺VM被nova安排在了一個compute node上[2]，對network的配置則通過neutron plugin轉(zhuǎn)換成為了對SDN控制器的一系列配置并發(fā)送給SDN控制器[3]。SDN控制器將收到的配置轉(zhuǎn)化為OpenFlow message或者對交換機的配置下發(fā)到各個物理交換機與OVS上[4]。這樣，那臺vm就可以與外界進行通信了[5]。

以上這個例子是一個非常典型的由orchestration系統(tǒng)所驅(qū)動的數(shù)據(jù)中心(Openstack只是一個例子)。在這個例子里，博主標出了五個數(shù)字，每一個數(shù)字都表示有信息從數(shù)據(jù)中心的一個部分流向另外一個部分，也就意味著每個數(shù)字背后都一定要有一張網(wǎng)來傳遞信息。這五張網(wǎng)可能彼此獨立，也可能幾張網(wǎng)合并成一張網(wǎng)。不同廠家會有不同的解決方案。

對于[1]，博主更愿意僅僅把它叫做Management Network，因為這張網(wǎng)承擔(dān)的任務(wù)就是：讓管理員與用戶登錄orchestration系統(tǒng)，對整個數(shù)據(jù)中心進行管理。這張網(wǎng)一定得存在并且往往會是客戶已有的Management Network的一部分。幾乎所有orchestration系統(tǒng)的服務(wù)節(jié)點(service node)和SDN控制器都要有管理端口接入這張網(wǎng)。由于這張網(wǎng)上流動的幾乎全部是控制信息，數(shù)據(jù)量不大，[3]和[1]可以是一張網(wǎng)。

對于[2]，不同的廠家有不同的解決方案。有些廠家把每一個compute node的管理端口都接入到了上一張management network當中，這樣做***的好處是可以充分共享management network當中已有的各種基礎(chǔ)服務(wù)，比如PXE和DHCP。但博主個人不太喜歡這樣的方案，主要是因為這樣的方案不獨立，絕大多數(shù)情況下它甚至依賴于客戶去擴容已有的management network。比如有客戶要部署一個數(shù)據(jù)中心，并且已經(jīng)采購了服務(wù)器和SDN交換機，開始興沖沖的連線了，忽然發(fā)現(xiàn)如果要把每一臺新服務(wù)器的管理端口都接入到現(xiàn)有的management network當中，端口會不夠用，怎么辦?只能再去采購幾臺傳統(tǒng)的交換機接入到management network當中，配置STP...當這一切發(fā)生的時候，所有的客戶都會質(zhì)疑：我們不是在部署SDN嗎，為什么還要配置STP?我們不是從你家采購了那么多SDN交換機嗎，為什么還要采購額外的并且是傳統(tǒng)的交換機來擴容management network呢?當客戶拋出這些問題的時候，生意基本就黃了一半。博主更傾向的方案是把[2]直接安排在SDN網(wǎng)絡(luò)的數(shù)據(jù)平面，比如在SDN網(wǎng)絡(luò)中直接配置一張網(wǎng)(比如一個vlan)來處理所有的orchestration系統(tǒng)和compute node之間的控制信息。這樣做就***程度的避免了繁雜的布線以及對management network的擴容。

終于講到了[4]，這張才是屬于OpenFlow message(或者其他南向API)的網(wǎng)。其實我們也可以將這張網(wǎng)和[1][3]一起放到management network上，但是這張網(wǎng)上的控制信息往往會比較繁重，包括所有的FlowMod, packet-in, 甚至是stats collection。于是這張網(wǎng)往往采用傳統(tǒng)交換機，2/3層協(xié)議以及必要的path redundancy來確保南向API準確快速的傳遞和執(zhí)行?？吹竭@里，也許有兄弟會質(zhì)疑：博主不是在[2]中剛剛反駁了采用傳統(tǒng)交換機擴容management network的方案嗎?怎么在這里就大張旗鼓的用起來了呢?事實是這是一個雞和雞蛋的問題：在[2]中博主建議采用SDN控制器在SDN交換機上部署一張專門用于orchestration的網(wǎng)絡(luò)，問題是SDN控制器如何將OpenFlow message發(fā)給SDN交換機呢?在這里，我們一定得借助傳統(tǒng)網(wǎng)絡(luò)，不然就是一個無止境的遞歸。于是一定又會有兄弟質(zhì)疑：那豈不是說SDN控制器也要通過傳統(tǒng)網(wǎng)絡(luò)給每個OVS發(fā)送openflow message了?那樣的話，每一臺compute node就又要有一個端口接入到傳統(tǒng)網(wǎng)絡(luò)上，在[2]中的努力不就白費了?這個問題引入了SDN數(shù)據(jù)中心設(shè)計中的一個難題：inband management，也就是說：如何在數(shù)據(jù)平面上配置一張屬于控制平面的網(wǎng)，讓SDN控制器通過這張網(wǎng)控制OVS甚至是物理交換機。關(guān)于這個問題，博主會在以后專門討論。

對于[5]，其實沒有太多可講的，因為它就是數(shù)據(jù)平面，我們之前所做的所有努力都是為了讓這張網(wǎng)容易管理，暢通無阻。

關(guān)于由orchestration系統(tǒng)驅(qū)動的數(shù)據(jù)中心網(wǎng)絡(luò)規(guī)劃，這篇文章僅僅開了一個頭。還有兩個特別重要也特別有趣的話題博主還沒來得及展開：數(shù)據(jù)中心的first boot以及inband management。在以后的文章中，博主會陸續(xù)涉及。