半年前的博文《Open vSwitch帶來的鉅變》中提到了SDN（軟件定義網絡），很開心看到目前國內關於SDN的討論越來越火，關注SDN的雲計算同仁們越來越多。國外基於SDN的產品化已經做的很不錯了，我們國內有沒有一些具體的項目，能讓人切實感受到SDN的靈活性、敏捷性給雲計算帶來的好處呢？如果只給你一天時間，用SDN能做出些什麼呢？這個Demo也許能帶來一點啓示：《一天時間，用SDN能做些什麼》。(清晰版下載，只有4M多。 Demo下載地址)
在介紹Demo之前，我們先接着聊聊SDN。
雖然近來才爲人熟知，但SDN並不是一個很新的概念。網絡牛人們在很久以前就提出了這個概念。遠的不說，最近VMware斥資12億美金收購的網絡虛擬化公司Nicira，早在五年前就成立了，專注於網絡虛擬化解決方案。至於學術研究、概念討論，則開始的更早。
那爲什麼SDN在近兩年才逐漸熱門起來呢？這應該是雲計算發展到一定階段的一個必然。計算虛擬化、存儲虛擬化是雲計算首先要解決的問題，在這些方面成熟之後，網絡虛擬化滯後的問題對雲計算靈活性的制約越來越明顯，爲解決這些問題，SDN越來越受重視。
網絡虛擬化滯後給雲計算帶來了什麼問題？各家公司在推廣自己的SDN方案時，通常會提到這樣的現狀：部署簡單、快捷是雲計算的一大優勢，而目前阻礙部署效率的往往都是網絡配置。例如，部署一批VM只需數十分鐘到幾小時，但在交付這些VM給公司內不同部門使用前，網絡管理員還需要花費數天，甚至更長時間，配置接入、安全等策略。聽起來有些駭人聽聞，但各大公司反覆在宣傳材料裏使用這一案例，應該是較爲可靠的現實狀況。傳統網絡的弊端在於，每當網絡拓撲、安全策略改變時，都要手動逐個配置衆多的網絡設備。問題根源在於計算虛擬化已經使計算資源和底層硬件服務器解耦了，但VM所使用的網絡資源和底層網絡硬件還緊緊耦合在一起。
SDN想要達到的理想狀態是，將VM所使用的網絡資源和底層網絡硬件解耦，並能通過軟件方式靈活、快捷地進行管理配置。這樣，就像給VM分配計算資源時不需要操作底層物理服務器一樣，管理VM的網絡配置時，也不再需要（至少不必頻繁地）操作衆多的物理網絡設備。進一步還能把計算、存儲上流行的Profile，Policy-Based Management等管理方式引入網絡領域。這些改變能極大提高雲計算數據中心的部署和管理效率。VMware最近在推SDD的概念（Software-defined Datacenter）， 切入點就是上述思路。
SDN的瞬間火爆，離不開業界一系列引人關注的事件，讓人們看到了一個技術概念能夠產品化並規模化應用的可能：
1.當人們還在懷疑Openflow，說“Openflow標準對大型產品化應用來說還很不夠”的時候，Google宣佈他們使用古老的Openflow 1.0標準，將自己遍佈全球的WAN主幹網SDN化了。太強大了！
2.VMware從5.1版本起，全面推廣VXLAN + Edge的網絡虛擬化架構；並高調收購Nicira，將NVP網絡虛擬化方案收入自己旗下；
3.Openstack宣佈在下一個發佈版中，Quantum項目將被囊括進來。
下面兩張圖解釋了openstack要做quantum項目的原因：
瞭解Quantum項目的人，可能覺得它還太簡單以至於不能稱作SDN，嫌棄它只做了網絡隔離。但這只是它要解決的第一個問題，Quantum本身的架構，爲以後支持firewall、load balance等更復雜的功能做了充分考慮。現在已經有公司在做供quantum使用的load balance。而且從下圖可以看出，quantum的引入，也是爲了解耦，使得網絡接入成爲一種服務（Quantum口號：connectivity as a service），能夠以軟件化的方式，直接供Nova調用。
回到SDN本身，就像雲計算剛開始時，各家對雲的理解都不一樣。目前大家對SDN的理解也多種多樣，採用的技術並不唯一，各家的實現方案也不盡相同。SDN最終會發展成什麼樣？目前沒人能說清楚。
總的來說，目前做SDN的大致分爲兩個門派：
其中一派主推“二次封裝”。代表方案有：Nicira的NVP（採用STT封裝），VMware的VXLAN + Edge，微軟的NvGre，這些都是Mac In IP的方案，還有Amazon的Mac In Mac私有方案 …
另一派主推Openflow。Google的方案是對Openflow enabled SDN強有力的背書。業界甚至有“SDN被Openflow綁架”的說法。
扯的有點多，回到Demo。Demo主題的選擇，沒有重複業界已有的SDN產品，因爲上面介紹的各種方案，都能搜到詳細文檔。而且上述multi-tenant隔離、軟路由等方案也不是“一天”就能做出來的。主要想分享一下SDN能帶來的靈活性、敏捷性，所以另闢蹊徑，選擇了半年前做的一個“基於SDN的Web訪問控制”的原型系統，拋磚引玉，希望能帶來一點啓發。
在傳統方案中，Web訪問控制通常工作在網絡邊界處，例如proxy、firewall等，對http數據包進行分析、丟棄或者重定向。例如zscaler的一款Web訪問控制產品，就是工作在proxy上。
該方案中，所有http數據包都是在到了網絡邊界的時候，才被甄別。非法數據包在內網飛來飛去。另外proxy、firewall本身還有其他工作要做，web訪問控制增加了它們的負載。
有沒有可能做些改變呢？例如，把proxy、firewall從這項工作中解放出來，讓它們專注於其它工作。同時，縮短非法數據包在內網的生存期，在離VM最近的地方，對數據包進行分析、丟棄或重定向。通過引入SDN，可以實現上述構想。
在對雲裏的VM進行web訪問控制時，該系統如何與雲計算中心控制節點交互？是否提供命令行配置？是否支持運行時實時配置？
該系統提供三種實時配置方式：
1. 提供了python控制檯，用戶可通過命令行進行配置；
2. 接觸到的公有云公司，有用python做總控節點的。該系統提供的第二種配置方式，支持雲計算中心控制節點通過傳參調用python腳本的方式進行實時配置；
3. 暴露REST API，雲計算中心控制節點可以通過遠程REST調用進行實時配置。
該系統實現了四種基本的Web訪問控制：
Pass_all : 允許所有網頁訪問
Deny_all : 屏蔽所有網頁訪問
White_list : 允許白名單上的網頁，屏蔽其它
White_list + Redirection : 允許白名單上的網頁，其它網頁自動重定向到指定網頁
做這個原型的過程中，SDN的靈活性、敏捷性給我留下了深刻的印象。半年前的某個週末，着手做這個事情，該原型系統主體部分，一天左右就完成了。
好了，不多囉嗦了，上視頻！
這次做Demo，還順道給各家視頻網站做了一把測試，優酷、新浪、騰訊試了個遍，發現視頻網站們二次轉碼壓縮的太狠了，明明上傳的是divx的高清視頻，轉碼之後卻超級模糊。相比之下，騰訊的效果稍好一些。如果還是覺得看不清，請移步微盤下載清晰版，只有4M多。 Demo下載地址
純屬拋磚引玉，希望能看到大牛們關於SDN更多的分享。歡迎拍磚！
微博 http://weibo.com/bengocloud Email: cloudbengo at gmail dot com