在網(wǎng)絡與IT領(lǐng)域，采用一種聚合方法創(chuàng)建基礎(chǔ)架構(gòu)，實現(xiàn)最大的靈活性和規(guī)模經(jīng)濟性，這已經(jīng)不是新聞。IP聚合將網(wǎng)絡設備和實踐方法結(jié)合在一起，而平臺架構(gòu)聚合(如Linux和商業(yè)化產(chǎn)品)則對計算資源做相同的事情。但是，將云作為廣泛統(tǒng)一平臺，前面提到的只是一些必要步驟，而不是最終解決方案。簡言之，我們還有工作沒做。

網(wǎng)絡是將云資源池的元素與用戶連接在一起的媒介。

在實現(xiàn)全面聚合基礎(chǔ)架構(gòu)解決方案中，云計算提供了3個重要的經(jīng)驗教訓：

• 首先，聚合源于虛擬化的概念，它創(chuàng)建一個抽象資源視圖，然后再輕松地映射到各種“真實”資源上。

• 其次，聚合要同時整合所有IT資源——而不僅僅單獨使用網(wǎng)絡、存儲或計算。

• 第三，聚合的實際實現(xiàn)依賴于網(wǎng)絡。雖然網(wǎng)絡也是聚合的其中一個目標，但是還需要用一些中間元素將物理資源綁定到虛擬化所依賴的重要中央抽象資源。

從大范圍看，云提出了虛擬化抽象層的需求，其中包括下面這些組件：運行應用程序和支持用戶的虛擬化服務器，附加存儲系統(tǒng)和用戶網(wǎng)絡連接。在最廣泛意義上，虛擬化使用戶能夠?qū)贸绦虿渴鸬教摂M化服務器上，然后它能夠管理底層服務器和存儲資源，滿足應用程序所需要的“資源虛擬化”任務。

云用戶完全不需要擔心服務器由什么組件構(gòu)成、它們在什么地方、存儲功能如何實現(xiàn)以及使用什么網(wǎng)絡設備。相反，用戶只需要管理虛擬化抽象資源。OpenStack的應用編程接口(API)讓用戶能夠訪問虛擬計算服務、虛擬網(wǎng)絡服務和虛擬存儲服務。這些API能夠?qū)①Y源池的分布式資源分配給應用程序，而網(wǎng)絡則是將云資源池中元素連接到用戶的媒介。所以，網(wǎng)絡發(fā)揮著雙重作用，它既是虛擬資源，也是云的實際連接工具。

為了高效使用虛擬資源，基于虛擬化的聚合需要網(wǎng)絡做更多的事情。當需要從由各種供應商硬件產(chǎn)品構(gòu)成的資源池中分配資源時，云的抽象層必須將所有資源變成同一類東西，讓應用程序能夠以相同的方式使用這些資源。

無論在什么主機上，存儲都必須通過同一種方式訪問。云中間件負責執(zhí)行這個工作，但是云中間件并不能克服資源的可用性或性能的差異，因為這是由資源與應用之間的網(wǎng)絡連接性能差異所決定的。來自全局資源池的存儲或計算元素必須有相同的工作方式，無論它是否位于資源池中，無論它離應用程序有多遠。

如果網(wǎng)絡失效，那么云也不復存在

云驅(qū)動的虛擬化聚合任務使網(wǎng)絡迫切需要改變。傳統(tǒng)的最佳IP連接并不能在云資源池所覆蓋的廣闊地理位置上實現(xiàn)統(tǒng)一的通信性能。隨著距離的增加，延遲和丟包也在加劇，以致有時候這兩個問題一起影響云資源的網(wǎng)絡訪問。如果云資源池的資源在性能上達不到要求，那么應用程序就無法從資源池獲得所需要的資源。相反，它們只能獲得鄰近的資源，也就是那些有穩(wěn)定性能的資源。這樣會大大降低資源池的效率，從而降低云的經(jīng)濟性。有時候，缺少穩(wěn)定的網(wǎng)絡性能會嚴重破壞云的規(guī)模經(jīng)濟，進而使它成為云技術(shù)應用的障礙。

抽象聚合所帶來的另一個挑戰(zhàn)是，使用計算或存儲資源的應用程序無法管理通信性能。當大多數(shù)計算機都無法連接“網(wǎng)絡”時，您又怎么向計算用戶解釋說遇到了網(wǎng)絡故障?在云環(huán)境中，連接真實資源與虛擬資源用戶的所有網(wǎng)絡活動都必須由云自己管理。流程越復雜，云的建設成本就越高。同樣，如果網(wǎng)絡無法正常工作，那么云的經(jīng)濟基礎(chǔ)就會受到威脅。網(wǎng)絡性能與穩(wěn)定的改進，都會降低資源成本和運營成本，也能夠改進云的應用。

底線是云正在驅(qū)動網(wǎng)絡的未來，特別是軟件定義網(wǎng)絡的發(fā)展。因為網(wǎng)絡即是“資源即服務”的云，也是將資源綁定到服務的橋梁，所以網(wǎng)絡任務的變化將重塑網(wǎng)絡技術(shù)。