剛性需求一：省錢！省錢！省錢！

 

    傳統(tǒng)網(wǎng)絡(luò)的開銷大概分為兩部分：購買成本和運(yùn)營成本。購買成本 = 設(shè)備本身 + 售后服務(wù)。那些知名大廠的網(wǎng)絡(luò)設(shè)備和售后服務(wù)都是明碼標(biāo)價的。問題是，我們買了設(shè)備，為啥還要售后服務(wù)呢？原因就在于傳統(tǒng)的網(wǎng)絡(luò)設(shè)備比較復(fù)雜，特別是它上面的軟件協(xié)議棧。遇到問題怎么辦？售后服務(wù)來解決。比較具有諷刺意味的是：售后服務(wù)的價格竟往往比設(shè)備本身昂貴很多，這讓博主頗為不解。如果不購買售后服務(wù)，那設(shè)備本身的價格又如何呢？單純的硬件已經(jīng)是白菜價了，值錢的是硬件上面的軟件協(xié)議棧。分解到這里，我們已經(jīng)看出了問題：因?yàn)檫@個龐雜的軟件協(xié)議棧，我們花了更多的錢買硬件設(shè)備，也因?yàn)檫@個龐雜的協(xié)議棧，我們甚至需要花更多的錢買所謂的售后服務(wù)。對于運(yùn)營商，這個軟件協(xié)議棧也許還有存在的意義，拓?fù)涠嘧儯従雨P(guān)系復(fù)雜，需要一些復(fù)雜的分布式協(xié)議撐撐門面。但對于數(shù)據(jù)中心，這個協(xié)議棧則變得非常雞肋。最簡單的，規(guī)劃一下vlan，跑二層。稍微復(fù)雜一些的，在leaf和spine之間跑路由協(xié)議+ECMP。配置都有模版，變變參數(shù)就好了。如此簡單的要求，根本不需要那個龐雜的協(xié)議棧，我們?yōu)槭裁催€花那份冤枉錢呢？

 

    再來說說運(yùn)營傳統(tǒng)網(wǎng)絡(luò)的成本。最大的開銷莫過于雇傭運(yùn)維團(tuán)隊了。在大企業(yè)的IT部門中，曾經(jīng)有一項(xiàng)很重要的衡量企業(yè)基礎(chǔ)設(shè)施自動化程度的參數(shù)叫做“管理員/每千臺服務(wù)器”。博主相信只要在傳統(tǒng)交換機(jī)上做過運(yùn)維的朋友都會承認(rèn)，管理一張傳統(tǒng)網(wǎng)絡(luò)是件非常麻煩的事情：任何來自上層應(yīng)用的需求都需要曠日持久的重新配置vlan，IP地址，路由協(xié)議和ACL，任何網(wǎng)絡(luò)故障都需要管理員登錄每一臺交換機(jī)檢查配置和各種show，還得每天盯著各種監(jiān)控系統(tǒng)查帶寬，看延時。這是一個技術(shù)活，不然CCIE們的身價也不會那么高。于是，網(wǎng)絡(luò)的運(yùn)營成本因?yàn)樗膹?fù)雜而變得昂貴。

 

    另外還有一些SDN和傳統(tǒng)網(wǎng)絡(luò)都無法繞開的成本，比如電費(fèi)之類的，博主就在此略過了。拆分完了傳統(tǒng)網(wǎng)絡(luò)的開銷，我們看看在理想情況下，SDN是如何幫助客戶省錢的：交換機(jī)仍然需要，但是交換機(jī)上面的協(xié)議棧不需要了。從前是n臺交換機(jī)n個協(xié)議棧，而現(xiàn)在是n臺交換機(jī)1個控制器。售后服務(wù)，仍然需要。新技術(shù)嘛，總得有人教一教。運(yùn)帷團(tuán)隊在SDN的世界里可能會大幅縮水，因?yàn)橹挥幸粋€控制器，不需要太多的管理員。看來在理論上，SDN確實(shí)能省錢，而且省的都是協(xié)議棧和運(yùn)維這樣的大頭。

 

    博主目前還沒有看到那些聲稱已經(jīng)部署SDN的企業(yè)公開他們具體省了多少錢。我猜有些企業(yè)可能會叫苦：部署SDN之后，我們花了更多的錢！博主把可能的原因歸結(jié)為1）不純粹的SDN方案以及2）新增的研發(fā)成本，在以后的文章中會詳細(xì)分析。

 

    剛性需求二：多租戶和彈性計算（multi-tenancy & elastic computing）

 

    自從多租戶與彈性計算的概念被Amazon EC2實(shí)現(xiàn)之后，不管是公有云還是私有云都紛紛希望效仿，使之成為了一個剛性需求。不過，這個需求可難為了傳統(tǒng)網(wǎng)絡(luò)。難點(diǎn)有二，首先是如何實(shí)現(xiàn)多租戶之間的隔離。在傳統(tǒng)的網(wǎng)絡(luò)中，二層的vlan以及三層的子網(wǎng)是最常見的租戶隔離方式。每加入一個新的租戶，網(wǎng)絡(luò)管理員都要手動為其分配vlan，分配IP地址。在傳統(tǒng)的網(wǎng)絡(luò)中，這個過程往往以天為單位。EC2出現(xiàn)之后，人們已經(jīng)習(xí)慣了分分鐘之內(nèi)搞定機(jī)器，搞定網(wǎng)絡(luò)。無奈不是家家都是Amazon，這種平臺可不是隨隨便便就能夠搭建起來的。

 

    第二個難點(diǎn)來自于彈性計算，也就是每個租戶可以根據(jù)負(fù)載的情況隨時申請，注銷和移動虛擬機(jī)。這一剛性需求成就了VMWare的一系列產(chǎn)品，以及以O(shè)penStack和CloudStack為代表的orchestration系統(tǒng)。但是這些系統(tǒng)都僅僅在管理服務(wù)器，物理網(wǎng)絡(luò)與它們無關(guān)。當(dāng)一臺虛擬機(jī)從一臺主機(jī)遷移到另外一臺主機(jī)的時候，物理網(wǎng)絡(luò)有時候必須做出相應(yīng)得調(diào)整（比如重新配置vlan）才能實(shí)現(xiàn)虛擬機(jī)的無縫遷移。

 

    沒有任何人會選擇以手動登錄每一臺交換機(jī)的方式來完成以上的配置修改。集中控制網(wǎng)絡(luò)設(shè)備成為了唯一的選擇。SDN也正是在這個剛性需求的推動之下，開始全速進(jìn)入人們的視野的。

 

    剛性需求三：應(yīng)用的多級部署和網(wǎng)絡(luò)服務(wù)鏈 （multi-tier application & service chaining）

 

    我把這個剛需稱作壓死傳統(tǒng)網(wǎng)絡(luò)這只駱駝的最后一根稻草。如今的在線服務(wù)已經(jīng)變得非常復(fù)雜了，那種一臺web服務(wù)器加一個數(shù)據(jù)庫服務(wù)器的架構(gòu)也許只能在demo階段見到了。一個更現(xiàn)實(shí)一些的架構(gòu)也許是這個樣子：最前端是防火墻，之后負(fù)載均衡把流量分派到多個web服務(wù)器，多個application服務(wù)器處理復(fù)雜的業(yè)務(wù)邏輯，多臺數(shù)據(jù)庫服務(wù)器負(fù)責(zé)查詢和插入記錄并且彼此備份，在web服務(wù)器和數(shù)據(jù)庫之間又有ACL拒絕二者直接通信。這僅僅是整個業(yè)務(wù)鏈條的一半，返回的網(wǎng)絡(luò)流量可能會經(jīng)歷另外一個完全不同的業(yè)務(wù)鏈條。用傳統(tǒng)網(wǎng)絡(luò)來實(shí)現(xiàn)以上這個業(yè)務(wù)鏈條簡直是一場災(zāi)難。業(yè)務(wù)鏈條每增加一環(huán)，服務(wù)器每增加一臺或者訪問控制每增加一項(xiàng)，就意味著網(wǎng)絡(luò)管理員要非常非常小心的根據(jù)各個服務(wù)器所處的網(wǎng)絡(luò)位置來配置相應(yīng)的網(wǎng)絡(luò)設(shè)備。業(yè)務(wù)邏輯復(fù)雜到這個程度，傳統(tǒng)網(wǎng)絡(luò)的管理方式已經(jīng)完全不能適應(yīng)了。而SDN與NFV（網(wǎng)絡(luò)功能虛擬化）對于解決這樣的問題具有很多先天的優(yōu)勢，博主會在以后的文章中詳細(xì)討論。

 

    到此，三個加速傳統(tǒng)網(wǎng)絡(luò)顛覆的剛性需求總結(jié)完了。值得注意的是，這三個剛需直到移動互聯(lián)網(wǎng)和大數(shù)據(jù)如火如荼的今天才開始顯得那么迫切。博主還是想強(qiáng)調(diào)：SDN的出現(xiàn)完完全全是因?yàn)樯蠈討?yīng)用的需求，是一個自頂向下的過程。這篇文章略去了不少其他的剛性需求，比如安全，快速路由恢復(fù)，實(shí)時網(wǎng)絡(luò)監(jiān)控等等。不是因?yàn)樗鼈儾恢匾且驗(yàn)樗鼈儾⒉皇谴偈筍DN發(fā)展的直接原因。