Management Network

人們提到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。在之後的文章中，博主會陸續涉及。