以「服務(wù)」的角度驅(qū)動網(wǎng)絡(luò)建構(gòu)所需要的環(huán)境，并且根據(jù)實際網(wǎng)絡(luò)需要的狀態(tài)，提供程序化的服務(wù)策略及規(guī)模的需求，才是我們對于SDN的需要。

 

　　這也是當前硬梆梆的網(wǎng)絡(luò)概念所無法支持的「以服務(wù)驅(qū)動的網(wǎng)絡(luò)基礎(chǔ)架構(gòu)」(Service Drives Network Infrastructure)觀念。

 

　　目前維運的網(wǎng)絡(luò)是否真的需要這種投資。什么樣的環(huán)境才會需要這種高靈活及彈性的網(wǎng)絡(luò)?一定不是靜態(tài)的服務(wù)器或是大型主機，因為這些設(shè)備就像大樹一樣屹立不搖，或許多年也不會有變動網(wǎng)絡(luò)的需求。

 

　　但是被高度虛擬化的服務(wù)器(Server Virtualization)可就完全不一樣了，Hypervisor根據(jù)用戶或是服務(wù)運行的狀態(tài)被動地產(chǎn)生、刪除、變更、搬移，越來越多應(yīng)用的環(huán)境已經(jīng)完全架構(gòu)在服務(wù)器虛擬化之上，這對網(wǎng)絡(luò)營運來說就是很大的負擔，因為我們使用的網(wǎng)絡(luò)概念就像工作了超過30年的老先生，已經(jīng)跟不上這個跑在云端上的年輕小伙子所需要的彈性和速度。

 

　　多租戶云非SDN不可

 

　　若問哪種網(wǎng)絡(luò)環(huán)境一旦沒有SDN就幾乎無法順利營運，目前看來，多租戶的云端(Multi-Tenancy Cloud)環(huán)境會是首當其衝的痛苦者(Sufferer)。以下舉幾個例子，希望能幫助讀者了解這個網(wǎng)絡(luò)層面上的苦難。

 

　　VLAN數(shù)量不足

 

　　一個L2 Domain可用的VLAN數(shù)量至多支援4094個。如果用戶使用4個VLAN，整個網(wǎng)絡(luò)只可規(guī)劃(provision)1000左右的用戶，并需要建構(gòu)新的L2 Domain繼續(xù)提供服務(wù)，但是新舊的L2 Domain卻無法合併運用，而且平均網(wǎng)絡(luò)背板(Fabric)的運轉(zhuǎn)效率可能達不到規(guī)模的30%。

 

　　TCAM記憶體不足(Memory Overflow)

 

　　一般機架交換機(ToR)僅需要服務(wù)20臺左右規(guī)模的靜態(tài)服務(wù)器，但在服務(wù)器虛擬化之后，即使保守以1:10的比例來看，服務(wù)器規(guī)模也會立刻成長10倍。

 

　　加上以VLAN Trunk為基礎(chǔ)的便利連結(jié)方式，每一個ToR因為VLAN Trunk所帶來的ARP訊息更會呈等比級數(shù)增加，較終導(dǎo)致TCAM Overflow成為單點故障?？膳碌氖牵@個問題在許多的除錯過程(Troubleshooting)中不易察覺。

 

　　服務(wù)可控度低

 

　　前面提到以服務(wù)驅(qū)動基礎(chǔ)架構(gòu)的議題，在這裡更可以看出更明顯的差異。以多租戶的云端環(huán)境來看，每一個租戶的服務(wù)需求各有不同，所以網(wǎng)絡(luò)管理員幾乎不可能以人力一一應(yīng)對，用戶更不可能為此等待數(shù)個小時。與時間賽跑的商業(yè)服務(wù)，需要以SDN這樣的技術(shù)，建構(gòu)具有高度彈性的基礎(chǔ)建設(shè)，才能符合云端服務(wù)市場需求。

 

　　本末倒置的迷思

 

　　觀察SDN議題在市場上被廣泛討論，其主軸往往圍繞著OpenFlow這個協(xié)定，但OpenFlow真的是救世主方案嗎?筆者很幸運在前幾年加入Nicira公司(現(xiàn)為VMware網(wǎng)絡(luò)及安全事業(yè)群)，它是全世界第一個對OpenFlow進行產(chǎn)品化的商業(yè)公司，主要成員也是OpenFlow發(fā)源地史丹佛大學的早期開發(fā)團隊。

 

　　某次與發(fā)明OpenFlow概念的Nicira技術(shù)長Martin Casado對談時，他說，OpenFlow只是一個協(xié)定，就像USB Disk所使用的USB協(xié)定一樣，真正有價值的是USB Disk裡的資料，而非這個協(xié)定。

 

　　其實如果讀者理解前面所提到的「以服務(wù)驅(qū)動的架構(gòu)」，到此應(yīng)該可以理解，有價值的不是OpenFlow這個協(xié)定，而是透過它所建構(gòu)的服務(wù)。所以SDN是不是民生必需品?未來不敢說，但至少今天可能是只有特定的服務(wù)型態(tài)，才需要它的支持。

 

　　OpenFlow兩大模式

 

　　在現(xiàn)今OpenFlow發(fā)展中，存在著兩個不同類型，一種是Hop by Hop模式，另外一種則是Overlay模式。

 

　　Hop by Hop模式

 

　　這是OpenFlow較早期的發(fā)展模式，Edge Device(OpenFlow交換器)將未知數(shù)據(jù)流的第一個數(shù)據(jù)封包發(fā)送給OpenFlow Controller作為路徑演算的條件，如果一條路徑需要經(jīng)過5個Hop Count，這樣的行為至少重復(fù)5次才能畫出一條 Slice Topology，而OpenFlow Controller也就是坐落在Data Panel之上。

 

　　在公開網(wǎng)絡(luò)中，如果透過這種模式進行Topology的學習，OpenFlow Controller將承受極大的流量壓力，成為較主要的瓶頸點。如果要預(yù)先載入Flow Table以解決學習的問題，先需要知道完整網(wǎng)絡(luò)訊息以建立Slice Topology Flow，操作比傳統(tǒng)網(wǎng)絡(luò)更為復(fù)雜。

 

　　Overlay模式

 

　　這是OpenFlow逐漸發(fā)展之后所開發(fā)出來的新型運作模式，透過API直接對OpenFlow Controller定義需求網(wǎng)絡(luò)Topology的型態(tài)，并且發(fā)送Flow更新至Edge(OpenFlow交換器)，Edge便可以根據(jù)Flow定義結(jié)果，在本地建立IP Tunnel作為數(shù)據(jù)轉(zhuǎn)發(fā)的橋樑。

 

 

　　▲Overlay模式透過API直接對OpenFlow Controller定義需求網(wǎng)絡(luò)拓撲型態(tài)，并發(fā)送Flow更新至Edge (OpenFlow交換器)，在本地建立IP Tunnel作為數(shù)據(jù)轉(zhuǎn)發(fā)的橋梁。

 

　　這個模式，因為OpenFlow Controller不坐落在Data Panel上，所以不會成為瓶頸點，并且透過IP Tunnel的模式，同時間也抽象化了物理網(wǎng)絡(luò)，讓由Overlay模式所建立的邏輯網(wǎng)絡(luò)，不受限于傳統(tǒng)L2網(wǎng)絡(luò)邊界或設(shè)備可達範圍，只要是IP連線能到的地方，SDN Overlay Network就能存在。

 

　　目前在市場上，硬體架構(gòu)的OpenFlow交換器的廠商還是以Hop by Hop模式為主。如果是以O(shè)verlay的模式運作，Open vSwitch是廣泛被應(yīng)用的開放式交換器軟體，多半是安裝在服務(wù)虛擬化平臺(Hypervisor)。 此運作模式是直接在內(nèi)部連接虛擬服務(wù)器及網(wǎng)絡(luò)，無須基于OpenFlow的硬體交換器就可達成SDN的需求，尤其對于多租戶的云端環(huán)境來說，節(jié)省了特殊硬體成本的開銷，也達成了服務(wù)驅(qū)動網(wǎng)絡(luò)架構(gòu)的目的。

 

　　為何使用Tunnel協(xié)定

 

　　近來市場上也有許多關(guān)于Tunnel協(xié)定的討論，如VxLAN、NVGRE、GRE或是STT，主要的課題鎖定在如何跨叁層網(wǎng)絡(luò)延伸二層網(wǎng)絡(luò)，且應(yīng)用場景幾乎都在高度虛擬化的資訊中心服務(wù)內(nèi)，鎖定的痛點也都說明現(xiàn)今網(wǎng)絡(luò)的規(guī)模不足及簡化網(wǎng)絡(luò)的架構(gòu)。這其實唿應(yīng)了前文所提及規(guī)模化服務(wù)網(wǎng)絡(luò)的需求，及根據(jù)服務(wù)驅(qū)動網(wǎng)絡(luò)的概念。

 

　　Tunnel技術(shù)解決了L2網(wǎng)絡(luò)規(guī)模化的問題，但并沒有完全命中簡化復(fù)雜網(wǎng)絡(luò)的需求。因為這個概念只涉及L2網(wǎng)絡(luò)連線的建立，而沒有滿足更細節(jié)的網(wǎng)絡(luò)服務(wù)需求，如QoS、MAC Spoofing、ACL或是Layer 3及更高層服務(wù)網(wǎng)絡(luò)的建立。

 

　　至于如何利用Tunnel傳遞更多的網(wǎng)絡(luò)應(yīng)用需求，便是OpenFlow Overlay架構(gòu)的目標，而非建立規(guī)模很大但功能單純的網(wǎng)絡(luò)來面對用戶復(fù)雜的需求。

 

　　往往有人質(zhì)疑Tunnel的封裝會大量消耗操作系統(tǒng)CPU資源，但很幸運的是，今日許多晶片廠商已開發(fā)出x86系統(tǒng)上的卸載(Offload)機制，Tunnel協(xié)定本身更可以直接結(jié)合于核心(Kernel)之中，事實上在x86系統(tǒng)上，網(wǎng)絡(luò)傳輸及同時降低CPU耗損的目標已經(jīng)實現(xiàn)。

 

　　SDN方案誰提供

 

　　硬體網(wǎng)絡(luò)技術(shù)已經(jīng)非常成熟，產(chǎn)品差異變得越來越小，但服務(wù)需求的差異卻越來越大。如前面所說，網(wǎng)絡(luò)必須有能力去面對各種不同的動態(tài)需求的挑戰(zhàn)，目前大致有幾種類型的廠商能夠提供相關(guān)服務(wù)：

 

　　1.成熟的網(wǎng)絡(luò)設(shè)備商

 

　　這一類型的廠商是生產(chǎn)網(wǎng)絡(luò)硬體設(shè)備為主，著重在效能及連接密度，為網(wǎng)絡(luò)提供非常良好的傳輸媒介。這也是我們天天都在使用的網(wǎng)絡(luò)設(shè)備。

 

　　2.SDN元件商

 

　　較重要的就是SDN Controller，畢竟Controller這個控制元件是SDN核心技術(shù)之所在。至于OpenFlow交換器，因為在功能上為接受者，所以雖然跟SDN的議題有相關(guān)，但畢竟不是主導(dǎo)元件，所以地位相對沒有Controller的廠商來得重要，但也還是必要元件之一。

 

　　3.網(wǎng)絡(luò)抽象化(Abstraction)廠商

 

　　幾乎都是軟體和晶片廠商的天下，重點在于把現(xiàn)有的IP網(wǎng)絡(luò)建立成一個背板資源池(Network Fabric Pool)，讓用戶的網(wǎng)絡(luò)可以被任意部署，不需要再為L2網(wǎng)絡(luò)的邊界而傷腦筋，這也是讓服務(wù)網(wǎng)絡(luò)規(guī)模化的新選擇，代表技術(shù)就是VxLAN、STT、GRE或NVGRE等等。

 

　　4.網(wǎng)絡(luò)虛擬化(Virtualization)解決方案商

 

　　此類型廠商并非提供單一技術(shù)產(chǎn)品，而是全面性可以部署于生產(chǎn)環(huán)境的解決方案，包括了Controller、Edge Switch、Tunnel在同一方案之內(nèi)，提供高度的網(wǎng)絡(luò)效能、擴展性及靈活性。對于真正需要SDN網(wǎng)絡(luò)的用戶來說，這才是所需要的統(tǒng)合式網(wǎng)絡(luò)能力，而不再是元件堆疊后的一座危樓網(wǎng)絡(luò)基礎(chǔ)建設(shè)。

 

　　一個都不能少

 

　　雖然受到業(yè)界的高度重視，但畢竟SDN自身無法變成一個獨立有價值的東西，真正有價值的是服務(wù)。網(wǎng)絡(luò)、服務(wù)器、儲存的關(guān)係是密不可分的，但是誰來協(xié)調(diào)這些元件?在云端資訊中心裡，是由CMS(Cloud Management System)來扮演指揮者的角色，沒有了它，大家只不過是一群「烏合之眾」。

 

　　因為服務(wù)不可能單獨由網(wǎng)絡(luò)所提供，服務(wù)器沒有網(wǎng)絡(luò)也無法傳遞服務(wù)，沒有儲存，重要的數(shù)據(jù)該何去何從?對云端資訊中心的運轉(zhuǎn)而言，CMS是非常關(guān)鍵的工具，千萬不要忘記這個指揮官。

 

　　近期廣受關(guān)注的OpenStack就是一個代表性的CMS平臺，透過協(xié)同運作的力量，擁有包含了8000名以上的個人會員、82個國家的社群、150家以上硅谷及其他地區(qū)的IT商業(yè)公司共同參與，全球超過600名的共同開發(fā)者。當然此外VMware vCloud、CloudStack等平臺，也都是這方面出色的CMS平臺。