專欄《網路與SDN》開通

02-01

申請了一個專欄來寫一些與軟體定義網路（SDN）相關的內容，畢竟作為一個程序員，只懂數學、物理、法律、經濟……是不夠的，還得在本職工作上多進行學習交流。

說到網路，對大部分人來說，我們今天的網路使用起來是很方便的，插上網線，連上WIFI，DHCP協議就會自動為你分配IP地址，接入點為為你提供NAT與防火牆的服務；或者連上4G網路，由運營商為你提供無線服務，讓你隨時隨地暢通無阻訪問Internet，讓網路變成一種拿來就用的資源，而不需要費太多的工夫來做很多配置操作。

但是在數據中心當中不是這樣的，這裡有成千上萬的伺服器，通常只有幾個工程師來維護，這些伺服器不僅要能夠正確訪問網路，還要對內、對外提供服務，這成千上萬的伺服器可不是隨便配個IP就了事的，要經過仔細的規劃，哪些伺服器需要互相訪問要放在相同網段內，哪些伺服器需要分隔成不同的IP段來提供隔離性，這些不同網段的機器還需要路由來相互連通，接入公網時，又要通過防火牆來防止未授權的訪問，畢竟那頭可是無數的黑客在盯著你呢。有一些要求高的，甚至內網也要做大量的訪問控制，在內網中創建出不同級別的安全區域。這過程中涉及到的通常都不是同一家廠商的設備，可能有華為的防火牆，華三的交換機，F5的負載均衡，思科的核心路由器，每家的設備都有不同的配置方法、配置命令，苦讀手冊十年終於配置完成，卻被告知——需求變了，要改。對於網路工程師來說一定會很絕望。

對於雲計算數據中心，這個問題就更複雜了，虛擬伺服器的數量規模會是物理伺服器的十倍以上，程序猿開發部署是變簡單了，網路工程師頭可就大了，不僅設備壓力增大，配置也遠遠變得複雜了，每台宿主機都相當於一個接入交換機，這可怎麼配得過來啊。而且雲計算數據中心中，虛擬機的創建和刪除都在不斷快速進行，如果故障不斷，這可是分分鐘出人命的節奏啊。

既然普通用戶可以享受簡單便捷的網路服務，為什麼數據中心就不可以呢？我們軟體工程師是網路運維工程師的好朋友，自然是看不下去這種簡單重複勞動的，既然這個工作這麼繁瑣，我們當然要盡量用程序、用軟體來幫助人做這些事情。僅僅把配置寫成腳本是不夠的，我們的目標是建立起一套系統，它有統一的對外界面和API，同時向下延伸到數據中心中每一台網路設備，當需要修改配置的時候，在統一的界面上操作，系統會自動計算出需要下發的配置，然後發送給每一台設備，將它們統一配置上需要的設置，然後運維工程師只要喝著茶等完成就行了。

能做到這一步已經非常困難了。然而，這還不夠。

廠商的設備實在是太多了，不僅不同廠家的配置方法完全不同，連不同型號配置起來也有差別，這樣我們不斷需要適配新的設備，治標不治本。

更可怕的是，運維工程師一個電話把軟體工程師大半夜叫起來了，「你來看看撒，我剛一點，網路就不通了」軟體工程師睡眼朦朧調試了半天，把配置打出來一看，「你看這個配置，不是發的對的嘛？」「那為什麼不通嘞？」大眼瞪小眼。網路設備是個黑盒，我們只知道怎麼配置它應該可以生效，但是如果這麼配置了它還真的就沒生效，那可是真沒辦法了，只有廠家的技術人員可以從一般人沒法查看的內部信息里找到原因，不幸的是，這種事情還真的不是什麼少見的事情，運維工程師把所有配置都刪掉再重新配回去一次，直接就恢復了，只能跟軟體工程師抱在一起痛哭流涕。

軟體定義網路（SDN），就是從這裡再往前走一步。

我們的自動配置系統現在放下身段親臨前線了，她把所有的交換機都叫到了一起：

「喂，你們都給本小姐過來，本小姐不管你們姓甚名誰，是出身高貴的思科還是低調內涵的華三，本小姐統統不管，從今天起你們都叫做Openflow交換機，你們都直接聽我指揮，多餘的功能統統不要，本小姐說的都給我好好做到，聽懂沒？你，交換機一，你遇到MAC地址為A的，就轉發去2號埠，遇到MAC地址為B的轉發去3號，MAC地址為C的，加上這個VLAN tag然後送去10號，MAC地址為D的，那是隔壁伺服器大哥又抽風了，丟掉，其他MAC地址的，你處理不了，留著我來，交換機二，你上傳的這個包應該去5號埠，以後3分鐘內MAC地址跟它一樣的也統統去5號不要再來問本小姐，交換機三，你被下線了，之前處理的那些個MAC統統不用再處理了，去把埠關掉等我消息，交換機四，把你今天交換了的包的統計信息上傳給本小姐，本小姐要過目，都聽明白了沒？開工！」

我們的軟體不再是那個身居深閨，偶爾有配置需要的時候活動一下的大小姐，而是親自上陣和交換機們配合起來，深入到轉發控制當中去，按照需要不斷調整轉發策略。參與轉發的交換機都使用相同的Openflow協議，因此不再需要區分廠家，每個廠家的功能都基本一樣，而且內部機制對外暴露、可以通過Openflow協議控制，這就叫做白盒交換機。大小姐給交換機下的指令，比如目的MAC地址為A則轉發去2號埠，就叫做流表，它是Openflow交換機轉發控制的基本單位。我們的大小姐就叫做控制器。

由於要跟交換機協同工作，對軟體的要求自然比以前要高得多了，雖然比起真正交換大量網路報文的交換機來說，控制器的壓力要小得多，大部分報文都通過流表規則直接進行了轉發，只有很少量的報文會上傳到控制器由控制器處理，但控制器仍然要保持非常高的控制效率。在以前的方案中，整個數據中心都由一個集群的控制器來完全進行控制，控制器的壓力非常大，一旦出現控制器癱瘓很可能出現整個數據中心的故障；現在的一些新方案中，控制器被劃小部署到小的單元，甚至每台宿主機都有獨立的控制器，這樣控制器壓力大大減輕，故障範圍也受到了控制，比起以前的方案來說要更成熟。

SDN是一種面向未來的網路方案。難以更新和升級的交換機被設計成功能結構簡單、轉發效率高的通用模型，而多種複雜的策略被轉移到控制器中，通過外部軟體實現，這使得功能升級、bug修復都變得更加簡單，與外部系統的對接也可以使用大量的成熟技術，比如說MQ、資料庫、WebService等等，軟體工程師可以在自己最拿手的領域大顯身手。有了SDN技術，我們離一個即插即用的數據中心網路又近了一步。

這個專欄主要的內容就是介紹和探討一些SDN相關的問題，希望感興趣的觀眾能夠多多進行互動，可以在評論區提出一些感興趣的問題和話題，為以後的寫作提供方向。從前面也可以看出，其實SDN並不是那麼複雜、那麼困難的事情，不用覺得它需要多麼高深的網路知識才能夠開始入手，也不要一提起SDN就覺得軟體肯定不如硬體靠譜、不如硬體效率高，實踐才是檢驗真理的唯一標準，SDN也需要更多的實踐。

順便也推廣自己的SDN控制器項目VLCP，在github上開源（Apache許可），地址為https://github.com/hubo1016/vlcp。開源的控制器很多，但說實話質量參差不齊，能很方便自己動手擴展的很有限，而VLCP有完全開放的架構、完全開放的數據模型和堅實可靠的底層基礎，我相信即使是和出色的親兒子OVN（這是OpenvSwitch新版本附帶的控制器，而OpenvSwitch是運用最廣泛的軟體Openflow交換機）相比也不遜色。即便是Python和網路方面的新手，也是可以嘗試一下的。

（題圖來源於網路）