SDN本身就是一個局部的網(wǎng)絡技術革命,，放大到全網(wǎng)的演進就得面臨經(jīng)濟、技術上的雙重挑戰(zhàn),，個人理解對于一個分散控制的互聯(lián)網(wǎng),，引入SDN不過是將分布式系統(tǒng)的節(jié)點規(guī)模做得更大,，如果你想擴大它的內涵，引入更廣泛的SDN控制,，那么你要想想為什么互聯(lián)網(wǎng)要分自治域,，為什么是IGP+BGP,BGP還要分iBGP、eBGP,，還要引入路由反射器,，為什么不是一個OSPF的單一區(qū)域。也許SDN+BGP,，替代IGP是有技術可行性的,，但是全網(wǎng)的演進總是比預期的更為緩慢。

 

回到SDN擅長的領域：數(shù)據(jù)中心,。數(shù)據(jù)中心由來已久,，Internet商用化后就存在，只不過在計算模式經(jīng)由MainFrame,、C/S架構,、P2P再回到中心化的云計算時代，數(shù)據(jù)中心規(guī)模呈爆炸式增長,，在虛擬化,、分布式計算技術解決了計算本身的部署、規(guī)模問題后,，網(wǎng)絡問題變得特別突出,。前幾年的數(shù)據(jù)中心網(wǎng)絡問題研究很多人拿虛擬機遷移說事，但是虛擬機遷移實際上是個小眾應用,，畢竟虛擬機遷移需要大量的狀態(tài)復制，跨存儲集群遷移時還要進行持久存儲的復制,，這是個投入產(chǎn)出比較低的活兒,，尤其是跨WAN進行遷移，簡直拿資本家的錢不當錢,。

 

我個人認為數(shù)據(jù)中心SDN帶來的價值主要有3點：

 

1,、網(wǎng)絡的自動化部署和運維、故障診斷,。依賴于SDN的集中控制,、集中拓撲探測，網(wǎng)絡設備完全可以做到即插即用,，除了部署之外,，網(wǎng)絡故障設備的更換變?yōu)楹唵蔚挠布鼡Q。對于故障診斷,，則依賴于控制器具有完全的轉發(fā)表項,，應用可以根據(jù)故障申告的業(yè)務報文做端到端的報文路徑靜態(tài)檢查,，也可以通過工具生成自動化的測試用例，在控制面進行灌包測試(與專門的測試儀表相比,，不受位置限制),，并且可以評估測試的覆蓋率，就如同軟件的代碼,、分支覆蓋率一樣;最后可以在控制面應用上生成故障申告業(yè)務相同的報文頭部通過SDN控制器的報文上送,、下發(fā)機制進行單步的檢測，檢測到軟故障具體的流水線節(jié)拍,。

 

2,、虛擬機的按需部署，這在公有云,、混合云的環(huán)境下尤其有用,。今天大家已經(jīng)比較習慣于在電信運營商營業(yè)窗口、自服務頁面上辦理業(yè)務后,，立刻收到短信通知業(yè)務已經(jīng)開通,，但是在早年，這些業(yè)務開通涉及到營業(yè),、計費,、后臺、網(wǎng)管中心,、LMT等系統(tǒng),，需要工單的流轉才能開通，是以天計的,。那么在今天絕大多數(shù)的數(shù)據(jù)中心中只要涉及到IP地址的分配問題,，仍然需要工單的流轉，這對于以虛擬機作為單位的主機托管數(shù)據(jù)中心,，顯然是低效的,，尤其是虛擬私有云、混合云,，從業(yè)需求來看需要允許客戶自己規(guī)劃,、配置子網(wǎng)和虛機的IP地址，并支持按需啟動/停用虛擬機和按使用計費,，從數(shù)據(jù)中心運營效率來看,，需要能夠自動發(fā)現(xiàn)負載更輕的物理機器加載虛機，這就要求網(wǎng)絡的地址是可以浮動的,，并且可以根據(jù)客戶的指令實時生效,。前幾年大家推大二層的解決方案，大二層需要輔以802.1Qbg才是一個完整的解決方案,，而Overlay+IP組網(wǎng)無需升級硬件,，無疑性價比更高,。如果要升級，則不如升級到SDN更為徹底,，你可以得到第1條所述的所有好處,，另外你也不知道明天還會有哪些需求，SDN提供了未來不升級硬件的承諾(當然這些承諾也是靠不住的,，你不因為功能升級,，但更可能要因為性能而升級)。保底地,，可以實現(xiàn)基于SDN的Overlay,。

 

3、動態(tài)業(yè)務插入,，比如虛擬防火墻,、虛擬VPN網(wǎng)關等設備以VM形式動態(tài)插入到轉發(fā)路徑上，并且可以根據(jù)業(yè)務流量的變化動態(tài)增加/停用Virtual Appliance.這其實是在第二點的基礎上實現(xiàn)的,，只不過增加了應用去感知,、控制業(yè)務邏輯實體。

 

vSwitch的性能很多人懷疑,，但是自從Intel推出DPDK后,，這個問題質疑的聲音要少一些了，但是報文經(jīng)過vSwitch到VM引起的上下文切換開銷還是比較難以解決,，尤其是小報文為主的業(yè)務,，將來應該以智能網(wǎng)卡+SR-IOV為解決思路，vSwitch退化為本地控制面,。

 

至于流量可視化,，沒有SDN你能夠做到，有了SDN也不見得會實現(xiàn)更加容易,。租戶數(shù)量問題,，和SDN也沒有太大關系，關鍵是轉發(fā)面封裝格式中表達租戶數(shù)量的標簽是多少位以及轉發(fā)設備據(jù)此生成的轉發(fā)規(guī)則,。

 

需要謹慎考慮、評估的好處包括：

 

1,、虛擬機遷移,，除了前面講的虛機遷移本身的成本外，虛擬機遷移本身的SDN實現(xiàn)也是一個比較困難的問題,。當集群規(guī)模較小,，VM通信對端較少的時候，一切都不是問題;當虛機集群規(guī)模較大,，比如Hadoop集群節(jié)點,，one hop DHT節(jié)點,、分布式文件系統(tǒng)節(jié)點，數(shù)據(jù)庫節(jié)點等(當然不一定建議這些節(jié)點用虛擬機,，性能也是問題),，遷移時需要遷移VM所在節(jié)點的轉發(fā)表，還需要更新與之有通信關系的虛擬機所在邊緣交換機的轉發(fā)表,，這個問題的痛苦之處在于需要更新轉發(fā)表的節(jié)點數(shù)量是不可預知的,。我們在移動網(wǎng)絡網(wǎng)絡中往往不去更新對端的轉發(fā)表，而是在遷移終端所在的遷出網(wǎng)絡設備和遷入網(wǎng)絡設備之間建立一條中轉隧道用于流量的轉發(fā),，但問題是移動網(wǎng)絡中的每一個會話周期都是短暫的,，因此這種中轉通道的生命周期是短暫的，不會給設備帶來太大的負擔;而服務器集群中的通信會話周期是不可預知的,，并且中轉帶來的迂回流量開銷可能也是驚人的,。因此這是一個很難控制的過程，尤其是在集群規(guī)模較大,、業(yè)務繁忙的時刻,。

 

2、細顆粒度的流量控制,。理論上我們可以做到,，并且OpenFlow一開始就被誤解為基于流的轉發(fā)控制。顆粒度越細,，需要消耗更多的轉發(fā)面和控制面資源,，更為糟糕的是在轉發(fā)面和控制面之間需要同步的信息就越多。在移動核心網(wǎng)的PCC架構下,，理論上是按照業(yè)務流進行QoS的控制的,，需要和轉發(fā)面能力相匹配的本地控制面能力，需要海量的TCAM來存儲通配流表,，付出的代價就是高1-2個數(shù)量級的成本,，所幸的是移動網(wǎng)絡的無線接入是瓶頸，流量有限,，如果在數(shù)據(jù)中心中應用,，最好還是進行粗顆粒度的流統(tǒng)計或者只對少數(shù)已經(jīng)預先識別的流進行控制。

 

從遠期來看,，DataCenter本身的效率和管理復雜度問題可能逐步成為解決方案的重點,，可能由松散的系統(tǒng)逐步走向計算、存儲,、網(wǎng)絡統(tǒng)一控制的緊耦合體,，更加注重對不同計算實體調度的優(yōu)化處理，這是所謂的DataCenter As A Computer理念，這其中,，裸CPU+Main Memory,、存儲都可以通過融合網(wǎng)絡直接連接起來，構成一臺類NUMA(此處是針對外存而言)的超級計算機,，而SDN控制下的網(wǎng)絡充當其CPU和外設的交換矩陣,。出于成本的考慮，這一交換矩陣可能很難做到完全無阻塞的,，因此它需要一定的實時監(jiān)測和路徑重指派能力,。這時候，SDN已經(jīng)完全融入到DataCenter的管理控制系統(tǒng)之中,，和計算,、存儲的調度完全融為一體。