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

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

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

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

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

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

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

對(duì)于[5]，其實(shí)沒(méi)有太多可講的，因?yàn)樗褪菙?shù)據(jù)平面，我們之前所做的所有努力都是為了讓這張網(wǎng)容易管理，暢通無(wú)阻。

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