人們提到SDN，邏輯往往是這樣的：控制和轉發平面分離，由于有了SDN控制器的中心控制，我們可以做各種天花亂墜的事情。那么SDN控制器和交換機之間是通過怎樣的網絡進行通信的呢？一個與之相關的更大的問題是：作為一個完整的SDN解決方案，我們應該如何規劃Management Network呢？這個問題也是所有客戶最關心的前三個問題之一。博主想通過這篇文章拋磚引玉，聊聊在設計數據中心Management Network時要考慮的問題。
在沒有SDN和orchestration系統之前，數據中心里往往只需要兩張網：management network和data network。前者用于讓管理員登陸到各個設備上進行配置，后者用于轉發業務流量。本文不會涉及任何關于power network和console port network的討論，因為那已經是太成熟的技術了。在orchestration系統大行其道的今天，網絡的規劃變得復雜了很多。
我們不妨腦補一下這樣一個場景：一個數據中心的租戶連接到Openstack的GUI[1]，在GUI上配置了一個network和一臺VM，這臺VM被nova安排在了一個compute node上[2]，對network的配置則通過neutron plugin轉換成為了對SDN控制器的一系列配置并發送給SDN控制器[3]。SDN控制器將收到的配置轉化為OpenFlow message或者對交換機的配置下發到各個物理交換機與OVS上[4]。這樣，那臺vm就可以與外界進行通信了[5]。
以上這個例子是一個非常典型的由orchestration系統所驅動的數據中心(Openstack只是一個例子)。在這個例子里，博主標出了五個數字，每一個數字都表示有信息從數據中心的一個部分流向另外一個部分，也就意味著每個數字背后都一定要有一張網來傳遞信息。這五張網可能彼此獨立，也可能幾張網合并成一張網。不同廠家會有不同的解決方案。
對于[1]，博主更愿意僅僅把它叫做Management Network，因為這張網承擔的任務就是：讓管理員與用戶登錄orchestration系統，對整個數據中心進行管理。這張網一定得存在并且往往會是客戶已有的Management Network的一部分。幾乎所有orchestration系統的服務節點(service node)和SDN控制器都要有管理端口接入這張網。由于這張網上流動的幾乎全部是控制信息，數據量不大，[3]和[1]可以是一張網。
對于[2]，不同的廠家有不同的解決方案。有些廠家把每一個compute node的管理端口都接入到了上一張management network當中，這樣做最大的好處是可以充分共享management network當中已有的各種基礎服務，比如PXE和DHCP。但博主個人不太喜歡這樣的方案，主要是因為這樣的方案不獨立，絕大多數情況下它甚至依賴于客戶去擴容已有的management network。比如有客戶要部署一個數據中心，并且已經采購了服務器和SDN交換機，開始興沖沖的連線了，忽然發現如果要把每一臺新服務器的管理端口都接入到現有的management network當中，端口會不夠用，怎么辦？只能再去采購幾臺傳統的交換機接入到management network當中，配置STP...當這一切發生的時候，所有的客戶都會質疑：我們不是在部署SDN嗎，為什么還要配置STP？我們不是從你家采購了那么多SDN交換機嗎，為什么還要采購額外的并且是傳統的交換機來擴容management network呢？當客戶拋出這些問題的時候，生意基本就黃了一半。博主更傾向的方案是把[2]直接安排在SDN網絡的數據平面，比如在SDN網絡中直接配置一張網(比如一個vlan)來處理所有的orchestration系統和compute node之間的控制信息。這樣做就最大程度的避免了繁雜的布線以及對management network的擴容。
終于講到了[4]，這張才是屬于OpenFlow message(或者其他南向API)的網。其實我們也可以將這張網和[1][3]一起放到management network上，但是這張網上的控制信息往往會比較繁重，包括所有的FlowMod, packet-in, 甚至是stats collection。于是這張網往往采用傳統交換機，2/3層協議以及必要的path redundancy來確保南向API準確快速的傳遞和執行。看到這里，也許有兄弟會質疑：博主不是在[2]中剛剛反駁了采用傳統交換機擴容management network的方案嗎？怎么在這里就大張旗鼓的用起來了呢？事實是這是一個雞和雞蛋的問題：在[2]中博主建議采用SDN控制器在SDN交換機上部署一張專門用于orchestration的網絡，問題是SDN控制器如何將OpenFlow message發給SDN交換機呢？在這里，我們一定得借助傳統網絡，不然就是一個無止境的遞歸。于是一定又會有兄弟質疑：那豈不是說SDN控制器也要通過傳統網絡給每個OVS發送openflow message了？那樣的話，每一臺compute node就又要有一個端口接入到傳統網絡上，在[2]中的努力不就白費了？這個問題引入了SDN數據中心設計中的一個難題：inband management，也就是說：如何在數據平面上配置一張屬于控制平面的網，讓SDN控制器通過這張網控制OVS甚至是物理交換機。關于這個問題，博主會在以后專門討論。
對于[5]，其實沒有太多可講的，因為它就是數據平面，我們之前所做的所有努力都是為了讓這張網容易管理，暢通無阻。
關于由orchestration系統驅動的數據中心網絡規劃，這篇文章僅僅開了一個頭。還有兩個特別重要也特別有趣的話題博主還沒來得及展開：數據中心的first boot以及inband management。在以后的文章中，博主會陸續涉及。
