精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

虛擬化時代的交換網絡

責任編輯:sjia

2011-11-30 14:02:43

摘自:51CTO

在云計算漫漫之旅上,虛擬化將是我們建設架構即服務云不得不跨越的一道坎,而大規模部署虛擬化更是給傳統數據中心管理模式、服務器、存儲和網絡架構規劃管理帶來巨大的挑戰。

在云計算漫漫之旅上,虛擬化將是我們建設架構即服務云不得不跨越的一道坎,而大規模部署虛擬化更是給傳統數據中心管理模式、服務器、存儲和網絡架構規劃管理帶來巨大的挑戰。為培養提高IT團隊服務水平和總結有關這些方面的IT管理方法,筆者結合實際工作經驗,與大量用戶交流與反饋,閱讀了國內外一些書籍、互聯網資料,在本文就云計算虛擬化交換網絡原理、邊緣網絡、核心網絡和產品與發展趨勢等方面給出了業務挑戰、技術、經濟分析和解決方案,希望對讀者有所啟發。

第一節 云計算虛擬化交換網絡——原理篇

架構即服務云計算

云計算是實現方便、快速、簡單、按需訪問可配置計算資源的管理模型 (部分定義來自nist),云計算是企業IT資源管理的高級階段,隨業務變化而變化,而不僅僅是IT技術簡單合并與應用。云計算所包含內容非常廣泛,如圖1所示,分成不同層次,從最接近用戶的上層到最下面的物理層,包含有業務接口層、應用平臺層、分布式操作系統層、虛擬化層、硬件架構層和數據中心設施層,同時有支撐不同層次之間管理和平臺,技術之外就作為商業模式出現的云服務交付體系和互聯互通標準等。而架構即服務云計算是什么呢,很簡單,就是根據用戶需求,在虛擬化層、硬件層和數據中心設施基礎等實現動態資源管理與調配的云計算服務,具備了這些特征計算模式就可以稱之為架構即服務云。

云計算架構模型
圖1 云計算架構模型

在實現架構即服務云計算過程中,虛擬化部署與實施是邁向成功的最關鍵一步。這里的虛擬化概念是更大范圍的架構虛擬化,與我們平時所認為的狹義服務器虛擬化不同,架構即服務云的虛擬化應該是端對端的虛擬化,包括數據中心虛擬化和桌面用戶虛擬化,而數據中心虛擬化(英文稱為Virtual Data Center或更細分為vPoD,Virtual Point of Delivery)又包含了服務器虛擬化、存儲虛擬化和網絡虛擬化。在所有虛擬化實現方式之中,以網絡虛擬化實現、設計和部署難度最大,因為大多數網絡還是基于傳統硬件芯片轉發機制,無法實現靈活升級,所以只有實現了網絡虛擬化,我們才能真正最終實現基礎架構端對端的虛擬化,才能實現架構資源動態調度。

云計算數據中心資源融合演變

談到云計算數據中心架構,我們知道,如圖2所示,數據中心最基本的三種基礎資源組成信息基礎架構,即服務器、存儲和網絡。當前融合趨勢之一是服務器與存儲相互融合,服務器增加內置硬盤容量替代大量直聯和近線存儲,以分布式文件系統方式管理,存儲設備則利用標準服務器實現更大規模橫向、豎向擴展和更高性能架構,將原本在服務器上的文件系統內置于存儲架構,通過存儲內的元數據信息做到了應用智能感知和處理;融合趨勢之一是服務器計算節點虛擬化需要更高比如萬兆、更強、更靈活網絡設備支持,而傳統網絡設備功能也從游離在服務器之外進入到內部物理,即虛擬化軟件交換機,不但如此還在服務器內部實現了虛擬防火墻或虛擬負載均衡,CPU作為服務器內部計算核心在內部網絡實現將發揮更大作用;融合趨勢之三是基于IP扁平化存儲與網絡結合更加緊密,需要優化以IP網絡為基礎支撐的云存儲,作為存儲服務被異構服務器或客戶端調用。在服務器、存儲和網絡硬件三種基礎資源平臺上,虛擬化和管理平臺建立統一架構資源池,通過標準如RESTful接口進行即時調度管理。

實際上,我們仔細分析一下,從云計算數據中心存在的三個基礎網絡就不難理解前面所述架構融合趨勢。如圖3,第一個網絡是服務器與前端客戶之間通信網,特點是高接入、協議兼容,目前常用以太網絡,用戶對網絡價格彈性和敏感性較高;第二個網絡是服務器與服務器之間進程通信網,特點是高可靠、低延遲,進程消息微秒級實時同步,目前常用InfinitBand網絡,大規模部署時對網絡價格敏感性高;第三個網絡是服務器與存儲陣列之間通信網,特點是滿足SCSI的Initiator和Target之間高帶寬、高IOPS和可靠性傳輸,目前通常維持獨立IP SAN或FC SAN,對網絡價格敏感性一般,因為網絡在總存儲成本只是少部分,來自數據保護和關鍵業務的需要也降低了價格彈性。這些兩兩對象之間的需求就是云計算數據中心架構資源包括網絡需求在內的最基本需求。要分析業務IT架構需求、了解用戶痛點,規劃、設計和實現數據中心架構,根據圖2和圖3確定的基本原則,就可以做到有的放矢,迎刃而解。 

架構云計算數據中心基礎架構
圖2 架構云計算數據中心基礎架構

數據中心基本網絡I/O需求
圖3 數據中心基本網絡I/O需求

進一步分析,在我們建立虛擬化環境后,服務器與服務器之間通信網被融合到單臺物理機內部的不同虛擬機之間,從而服務器與存儲通信網、服務器與前端客戶網絡也被拉到單臺物理機內部,導致南北流量從90%減少25%,東西流量成為主流占據75%,如圖4所示,這樣趨勢下,傳統系統架構和網絡設計勢必相應改變才能適應設計要求。這就是我們今天要談的云計算虛擬交換網絡。 

云計算虛擬化數據中心I/O演變
圖4 云計算虛擬化數據中心I/O演變

從歷史來看,云計算虛擬交換網絡由服務器內部基于軟件虛擬交換發展而來,進化發展到基于硬件的數據中心邊緣網絡,再升級到到數據中心核心層演變,層次疊進,由用戶需求推動到不同層面技術革新,從技術創新新反哺到用戶需求業務發展,又有新需求促進反復作用,不斷提高和前進的過程。

云計算計算資源虛擬交換網絡——計算資源內部虛擬交換網絡

計算資源內部虛擬交換網絡原理

簡單來講,計算資源虛擬交換網絡就是在物理主機內部,虛擬機管理平臺為了實現同一物理機或不同物理之間虛擬機通信而實現的軟件交換機。為了便于大家理解虛擬交換網絡原理,下面以VMware虛擬交換網絡概念為例介紹:

虛擬化交換網絡示意圖(VMware軟件交換)
虛擬化交換網絡示意圖(VMware軟件交換)
圖5 虛擬化交換網絡示意圖(VMware軟件交換)

虛擬化交換網絡接口分兩大類,一類是位于虛擬化支撐操作系統內部,另一類是位于虛擬客戶機操作系統內部。虛擬化支撐操作系統內部網絡接口有IP存儲網絡接口(NFS或iSCSI,需要約2G帶寬,存取虛擬機映像或用戶數據),資源調度和虛擬機飄移網絡接口(如vMotion,一般最大消耗是3.6Gbps帶寬,傳遞飄移信息),保證虛擬機高可用網絡接口和容錯日志接口(Fault Tolerant Logging,消耗約4Gbps帶寬,同步高可用信息)。虛擬化客戶機操作系統需求則比較簡單,只要客戶操作系統內部虛擬接口。從圖5,我們看到,每個虛擬化支撐平臺內核本身就需要5個通信接口,而每個虛擬化客戶機至少配置一個虛擬化接口,每個接口都需要獨立IP和MAC地址。為了簡化虛擬化軟件交換機復雜性、構建更加開放的IT虛擬化生態環境,VMware提供了VNetwork控制平面接口,第三方軟件廠家可以自己開發獨立虛擬化控制平面交換機,或網絡硬件廠家開發出虛擬化管理平臺插件,與VMware虛擬化管理平臺整合集成,自動化調度網絡設備硬件配置隨虛擬機飄移而變化。比如Cisco公司Nexus 1000V就是第三方軟件交換機解決方案,Force10等還提供了基于VMware虛擬化交換機符合VNetware規范的控制平臺插件,與VMware飄移策略集成,虛擬化計算節點智能感知,實現虛擬機調度是網絡自動化調度,這里就不費篇幅贅述了,有興趣讀者可以在網上查找資料。

計算資源內部虛擬交換網絡挑戰

隨著虛擬化和云計算的深入發展,人們發現藏在虛擬操作系統內的虛擬化交換機越來越成為頭痛的問題。根據IDC統計(圖6),到2013年底虛擬機部署數量將是物理機的2.5倍,達到8千2百萬臺,虛擬機節省了大量的物理購買成本,但在管理復雜度上面造成運營成本增加也非常顯著。虛擬交換機既要與現有虛擬管理平臺兼容,又要應對高度動態變化端設備,維護虛擬邏輯抽象鏈接,集成與交換硬件設備功能,從移動性、機動性、維護性和集成性分類如下:

• 跟蹤設備移動狀態。網絡端節點實體(比如虛擬機)的網絡狀態需要簡單確定,不同主機之間可相互遷移節點狀體。這些狀態包括傳統“軟狀態”,比如數據鏈路層學習表、三層路由轉發狀態、路由策略狀態、訪問控制列表、服務質量策略、配置監控及結構化自動化系統等。簡單來講,就是每個虛擬機移動時,其所帶虛擬接口策略如何主動隨之漂移。

• 響應網絡動態變化。虛擬化環境最大特點是網絡高度狀態變化。跟蹤虛擬機加入和離開,虛擬機往前或往后即時移動,邏輯網絡環境快速變化,開放式控制平面控制流量和全局網絡自動發現管理。而且由于虛擬機動態變化,防火墻和入侵檢測系統無法有效隨之變化而保護它們,無法做到及時被動有效反應。更極端情況是,虛擬機機動性變化常常跨越了不同的組織邊界,尤其在公共云環境。

• 維護虛擬化邏輯標記。分布式虛擬交換機通常通過增加或管理虛擬機網絡數據,來維護虛擬網絡或邏輯區域上下文,這是容易理解的簡單方式,問題是正確和高效管理這些虛擬化標記非常困難。增加網絡標記,就增加新一層網絡信息,從另一方面間又增加了網絡復雜度。為簡化管理和提高效率,常常需要優化虛擬機標記存儲方式,包括保存虛擬化地址或重新映射、配置、修改和遷移標志。

• 集成操作系統和硬件。把虛擬數據轉發路徑設計成“卸載”模式,數據包處理由硬件芯片完成,以獨立軟件或硬件芯片方式實現靈活控制,增加虛擬化網絡性能。獨立軟件開發商還可以使用接口增強虛擬邊界網絡功能,減少硬件交付到應用交付的負面影響,從而簡化、加速和減輕可擴展云的網絡管理。 

邏輯主機與物理主機增長趨勢圖
圖6 邏輯主機與物理主機增長趨勢圖

開放虛擬化軟件交換機(Open vSwitch)體系架構簡介

隨著虛擬化應用普及,需要部署更多虛擬化軟交換交換機,而費用昂貴的閉源虛擬交換機讓用戶不堪重負,于是一群開源社區奉獻者開發出了多層虛擬化軟件交換機Open vSwitch,它遵循Apache 2.0開源代碼版權協議,可用于生產環境,支持跨物理服務器分布式管理、擴展編程、大規模網絡自動化和標準化接口,實現了和大多數商業閉源交換機功能類似的軟件交換機。

Open vSwitch內部通信圖
圖7 Open vSwitch內部通信圖

Open vSwitch功能結構圖
圖8 Open vSwitch功能結構圖

Open vSwitch基本部件分為三個部分,其一是ovs-vswtichd守護進程,慢速轉發平面,位于用戶空間,完成基本轉發邏輯包括地址學習、鏡像配置、802.1Q VLAN、LACP協議、外部物理端口綁定基于源MAC和TCP負載均衡或主備方式,可以通過OpenFlow遠程配置和管理,sFlow、NetFlow或SPAN端口鏡像方式保證網絡可視性,配置后數據交由ovsdb-server進程存儲和管理;其二是核心數據轉發平面openvswitch_mod.ko模塊,它位于內核空間,完成數據包查詢、修改、轉發,隧道封裝,維護底層轉發表,是快速數據轉發平面;其三是控制平面OpenFlow,不同物理機的軟件交換機通過OpenFlow控制集群組成分布式虛擬化交換機,還實現不同租戶虛擬機隔離實現。每個數據轉發保持一個OpenFlow鏈接,沒有在轉發平面出現的數據流在第一次通過軟件交換機時,都被轉發到OpenFlow控制平臺處理,OpenFlow根據2-4層信息特征匹配,定義轉發、丟棄、修改或排隊策略,然后第二次數據轉發時就直接由核心轉發模塊處理,加快了后續數據處理過程。根據有關測試報告,Open vSwtich與Linux Bridge表現性能相差無幾。

Open vSwitch不但可以獨立軟件方式在虛擬機管理器內部運行,比如Xen、 XenServer、KVM、Proxmox VE和VirtualBox等虛擬機支撐平臺,還可以可部署在硬件上,作為交換芯片控制堆棧。Citrix公司已把Open vSwitch作為XEN Cloud Platform平臺缺省內置交換機,Open vSwitch版本1.1.0pre2支持如下功能:

• 支持NetFlow、sFlow(R)、SPAN和RSPAN,監視虛擬機之間通信

• 支持標準802.1Q VLAN Trunk

• 保證最大、最小細分服務質量保證QoS

• 可按虛擬機接口分配流量,定制策略

• 支持綁定網卡、基于源MAC地址負載均衡

• 支持OpenFlow控制平面協議

• 支持本地Python綁定的遠程配置協議

• 支持以太網GRE隧道連接

• 兼容Linux橋接代碼

• 支持可選內核或用戶空間轉發引擎

• 流緩沖引擎實現多表轉發管道

增強虛擬化軟件交換機性能

因為虛擬化軟件交換機基于服務器內部處理,消耗大量CPU資源和IO資源,為了提高轉發性能,各個組織如CPU廠家Intel、AMD和PCI工業協會一直積極推進提高虛擬化性能。第一種性能提高方式是虛擬主機IO頁面地址直接訪問功能,Intel VT-x功能是允許虛擬機直接訪問由VMM(Virtual Machine Monitor)配置的物理內存空間,直接路徑I/O存取,加速DMA數據存取。Intel VT-d與VT-d功能類似,使用DMA描述符號標識虛擬機I/O地址空間,它們共同點是都需要做虛擬機I/O地址轉換到物理I/O地址工作,與物理I/O資源需要一一對應關系,無法做到一對多,只能實現虛擬化對應物理資源性能提高,無法I/O資源共享;第二種性能提高方式是卸載軟件網絡功能到物理網卡,VMDq (Virtual Machine Direct Queue) 就是基于網卡硬件加速的技術,提高虛擬化環境下網絡I/O性能。VMDq網卡實現了二層交換機部分功能,分揀和分類數據包,輪詢傳輸,傳統模式下由軟件交換機實現,據說可以提高2倍性能,但是還需要VMM復制網絡數據包;第三種性能提高方式是SR-IOV實現IO設備資源共享,SR-IOV網卡內嵌具有完整功能、支持廣播的二層交換機,是基本網絡轉發平面,由CPU的VMM管理,可實現更加數據分揀、分類與安全等控制平面,還有一些簡單QoS控制平面功能。資源共享方式是PCI Mgr (SR PCIM)給每個虛擬機分配一個單獨虛擬功能號VF(Virtual Function),最大支持256個子設備號256個虛擬機。性能提高方式是虛擬化軟件交換機完成初始資源(CPU、內存和IO虛擬)分配管理,保留基本網絡控制平面。建立數據轉發連接后,虛擬機虛擬網卡之間通過VF直接轉發數據,無需經過主機虛擬化軟件交換機,從而加速了虛擬化交換性能。其他性能提高方式還有Intel VT-c/VMDc功能(Virtual Machine Direct Connectivity)實現同一物理口不同虛擬機和虛擬功能之間直接通信模式,可以動態指定不同虛擬機虛擬網卡專用帶寬,限于篇幅,這里就不多述了。

SR-IOV系統結構圖
圖9 SR-IOV系統結構圖

第二節 云計算虛擬化交換網絡——邊緣篇

虛擬化交換網絡層邊緣層挑戰

熟悉IT發展歷史的人都知道,IT技術發展趨勢總是這樣,進入者在軟件上突破和實現,不斷應用于客戶和取得市場反饋,然后隨著性能提升要求和硬件技術發展,移植到高速、簡潔的ASIC上,虛擬化交換網絡領域也不外乎遵循這樣變化軌跡。

前面所講,計算資源內部虛擬交換網絡實際上是通過數據中心邊緣計算節點內部的虛擬交換機軟件實現。虛擬交換機放在數據中心網絡計算節點內部時就被稱為虛擬邊緣橋接VEB(Virtual Edge Bridge)。這種稱謂是非常合適的,因為此時虛擬交換機完成的功能和二十多年前我們使用的物理橋接設備(Bridge)類似,只完成不同網絡節點之間的數據轉發,沒有更細分的交換控制和管理比如網絡監視、更多標準協議支持等等。虛擬邊緣橋接優點是基于物理主機內部交換,基于計算節點內部資源,不會增加更多外部網絡流量,實現物理計算節點內部更快交換速度,不需要額外硬件支持,只需在虛擬機支撐管理平臺編寫告訴數據轉發引擎和開發控制平面,服務器管理人員更容易理解和實施,但是主機軟件交換機缺點是一方面是性能提高受制于CPU和網卡IO架構,另一方面是它通常只能由服務器團隊通過虛擬機支撐平臺配置和管理,傳統網絡團隊難以理解、學習和操作,缺乏鏈路底層的監控和安全控制,因此IT安全管理策略還需要在虛擬機和物理機不同層面分別實現。為了進一步提高性能和簡化管理,把卸載到網卡功能再卸載到強大的物理交換機。

虛擬化交換網絡邊緣層層技術發展

針對以上數據中心邊緣網絡技術和管理挑戰,目前業界發展“Edge Virtual Bridging”(EVB)邊緣虛擬橋接,形成了兩種的技術標準:

虛擬以太端口匯聚器(Virtual Ethernet Port Aggregator,簡稱VEPA)

VEPA技術標準是由HP、IBM、Dell、Juniper和Brocade等公司發起的,統一管理和監控各種虛擬機的橋接標準,目前已被采納為IEEE標準802.1Qbg,其主要功能由數據中心邊緣虛擬交換機硬件實現。VEPA有兩種實現模式,一種是標準模式,需要虛擬交換機和上聯交換機做少量代碼升級;另外一種是多通道模式,需要上聯交換機更多智能處理功能。

標準模式VEPA技術特點是實現簡單。傳統虛擬環境下,同一物理節點的不同虛擬機之間流量發送由虛擬交換機直接處理了,并不會發出網口。在VEPA下,情況發生了一點點改變,虛擬機內部之間流量不再由本地虛擬交換機處理,而是被強制發往物理網卡外部,由網卡上聯的VEPA交換機接收處理后才發送回來,這種技術叫Hairpin(發夾)。因為大家知道,傳統交換機固件不允許從一個物理接口接收數據幀,又同時從同一口發送同樣目的MAC地址的數據幀,所以需要我們需要對傳統交換機固件做一些簡單修改,允許其繞回。這種方式下,很簡單,所有虛擬機流量被重新導向了上聯物理交換機,用戶可以輕松地以傳統管理方式,在修改后的物理交換機上實現流量統計、安全控制管理,減少物理節點寶貴CPU資源,不必浪費在簡單的網絡I/O層面。不過VEPA實現方式也有明顯缺點,所有虛擬機之間流量在物理節點和交換機來回了兩次,浪費了網絡帶寬和增加數據延遲,但是與安全管理簡單控制收益相比,這些代價是值得的。另外一方面,專用網絡設備芯片對網絡流量轉發和控制效率通常比我們標準服務器來得更加經濟有效,我們還可以結合第一節中提到的單根IO虛擬化(Single Root I/O Virtualization)或VMDq直接路徑I/O減少虛擬機之間來回轉發數據包負面影響。

標準VEPA EVB操作模式
圖10 標準VEPA EVB操作模式

VEPA多通道運行模式
圖11 VEPA多通道運行模式

多通道模式VEPA(Mutli-Channel VEPA)則增強了標準模式功能,同時兼容傳統虛擬交換機和標準模式VEPA,實現方式是將物理鏈路分成多個服務通道Channel,網絡交換機和網卡獨立識別每個通道,這些通道可以分配給傳統直聯虛擬機、傳統VEB模式虛擬化交換機或VEPA虛擬以太端口聚合交換機。每個通道物理標識采用802.1ad(Q-in-Q)技術,簡單來講,就是在802.1Q VLAN標記基礎上增加了“S-Tag”服務字段標記每個通道,很顯然,服務器網卡和交換機都需要支持Q in Q特性,才能區分不同源虛擬機或橋接流量。

虛擬網絡標識(VN-Tag)

VN-Tag標準由Cisco為主發起的虛擬化網絡控制協議,實現了虛擬網絡智能識別和控制,在不擴大生成樹域和管理界面的前提下擴展了接入層,目前已被IEEE接納成802.1Qbh“Bridge Port Extension”橋接口擴展標準,實現方式主要是在傳統以太網幀基礎上增加VN-Tag幀頭以標識每個虛擬機所綁定的虛擬接口(Virtual Interface, 簡稱VIF)。VN-Tag幀頭其中最重要兩個字段分別是目的虛擬接口標識DVIF_ID和源虛擬接口標識SVIF_ID,它們清楚地區分了來自同一個物理網口上的每個虛擬機虛擬網絡接口。每個接口功能實現機理有兩種,物理網卡芯片固件或虛擬機平臺軟件交換。VN-Tag缺點是需要網卡和交換機硬件升級,但是與傳統交換機兼容,因為虛擬接口VIF只是本地查找有效,VN-Tag在VN-Tag交換機入口處寫入,在出口處去除VN-Tag,中間交換機只是需要根據傳統以太網幀模式傳輸,VIF作用有點類似我們以前常用幀中繼的本地邏輯鏈路接口DLCI。 

VN_Tag幀格式
圖12 VN_Tag幀格式

VN_Tag幀轉發模式
圖13 VN_Tag幀轉發模式

總的來說,目前兩大標準802.1Qbg和802.1Qbh都在不斷完善過程中。可以看出,VEPA主要改進在于減少軟件交換機在數據轉發層面性能影響,虛擬流量以802.1q和服務通道表示,整個控制平面交由VEPA物理交換機實現。而VN-Tag主要改進在于虛擬化得數據轉發層面和控制平面端對端實現了革命性變化,虛擬流量以源和目的VIF虛擬端口表示,既可以通過軟件交換機內核實現也可以物理交換機實現。實際上,兩者具有互補作用,VEPA設備自動發現方式就可以用于VN-Tag,未來不排除出現融合兩者技術的新標準,做為IT管理者,對當前采購的設備需要充分考慮與原有設備和協議的兼容性,運行效率提高,同時不會由于哪一個技術發展障礙而受到影響。

第三節 云計算虛擬化交換網絡——核心篇

虛擬化交換網絡核心層挑戰

同一物理節點部署了多臺虛擬節點,虛擬機可用性就會受制于物理節點可用性,為了減少來自物理節點可用性影響,就必須讓虛擬機在不同物理機之間保持高可用性。不但如此,資源調度以虛擬機飄移方式實現。虛擬化主機高可用、動態調度和容錯等,其支撐平臺需要同步大量所有關鍵信息,包括微妙級別變化更新的大規模內存影像和存儲數據,同步進程之間消息傳遞必須保證低延遲,因此我們在擴展核心和邊緣網絡時必須實現傳輸性能最大化,延遲最小化,所以保持基本網絡多路徑、快速收斂、橫向擴展的二層環境就是我們選擇和發展方向。但是傳統網絡為實現物理網絡高可用性而用得生成樹協議,就成為了我們不得不面對最大挑戰。一方面,在網絡控制平面,STP浪費了50%鏈路帶寬,秒級收斂時間無法滿足低延遲要求,另一方面,由于虛擬化接口二層MAC地址大量增加,如何在轉發平面保持二層高效尋址和高速數據轉發就是另外的困難點。舉個例子,MAC地址表轉發需求,原來每臺物理節點只有兩個網卡,兩個MAC地址,安裝十個虛擬機后MAC地址數目變成2x10(冗余設計)+2等于22個,安裝五十個虛擬機后MAC地址數量變成102個,增加了50倍MAC表轉發要求,激活MAC的數目是物理機數和虛擬機數線性函數,虛擬化環境下,這個函數值被放大了成十上百倍,單個物理端口MAC密度同比放大,并且我們知道網絡信息處理要求與網絡節點數目平方成正比,所以網絡性能要求也就增加了成百上萬倍。

當前不少數據中心網絡雖然也實現了二層網絡,但是由于交換機功能比較簡單,它只是根據入端口學習網絡節點物理地址,根據目的節點物理地址,給定出端口轉發路徑,我們可以稱之為純二層轉發,同時生成樹距離向量算法也比較簡單,沒有與轉發平面集成,更無法實現基于二層網絡層次模型智能地轉發,或者說沒有二層半的數據轉發,所以實際上傳統數據中心網絡只有基本數據轉發平面,沒有豐富的控制和管理平面。另外,傳統網絡下,網絡節點數目比較少,而且節點網絡位置變化頻率非常低,通常幾天或幾月不等,流量模式主要是客戶機與服務主機之間的南北流量。虛擬化交換架構里,網絡節點數目成百增加,節點位置遷移和變化頻率要求去到妙級,流量模型變成以虛擬主機之間的東西流量為主,這種頻繁變化需求,使得生成樹STP在高度重建虛擬化節點路徑時應接不暇,可能最終變成一個近似無限的循環。

為了隔離網絡風暴,簡化管理和增加安全,傳統大型數據中心通過VLAN方式隔離不同用戶區域。整體網絡分成接入層、匯聚層和核心層,不同區域用戶通信時,接入層和匯聚層把數據導向核心,核心層基于三層轉發。云計算虛擬化環境下,“不同區域”概念被高度模糊,區域內部、區域之間通信無法有效靜態區分,二層和三層極度混合,通信模式從數據中心服務主機群與外部客戶交互的垂直交換模式(占總體流量95%以上)演變變成數據中心內部大量虛擬機之間交互的水平交換模式(占總體流量75%以上,原因是垂直流量不變,水平流量大量增加),傳統模式的核心三層路由轉發便成為瓶頸。那么如何消除瓶頸呢?用戶需求永遠是產業導向之根本,顯然根本途徑是消除或減少網絡層次,云計算虛擬化交換網絡趨勢便是從三層簡化為核心層和邊緣層二層,而且二層網絡則需要消除生成樹,更加簡單,支持多路徑以應對虛擬資源快速變化要求。

虛擬化交換網絡核心層技術發展

每一次新IT技術出現,我們在應用新IT技術都會有新的挑戰。從最終用戶需求觀點看,第一,新技術應用從保護資產投資、員工學習曲線上講,其應用過程應該是漸進性的,而不是革命性,不能影響現有應用環境,與現有環境局部兼容共存,是求同存異過程,一個環境兩種或以上技術,可在適當時間段將當前應用環境平滑到新技術環境;第二,從技術需求上講,新技術應該能夠提供更高性能、更好擴展性、更易管理、更加開放和兼容標準價值等,保持總擁有成本更小優勢;第三,新技術在不同應用、不同行業廣泛應用程度和技術成熟程度也會用戶重要考量指標。具體到虛擬化交換網絡核心層發展,我們可以看到來自三個方面需求:

第一,數據轉發平面發展。關鍵要保證數據轉發平面可擴展性,核心豎向擴展有限設備轉發智能轉向基于邊緣設備快速轉發智能,中心設備只是完成無CPU介入的全網狀通路。簡單來說,需要把傳統交換機端口接口板和交換背板快速轉發機理延展到了數據中心網絡邊緣,每個靈活的接口板變成每個獨立智能、靈活接口設備部件,交換機交換背板變成可橫向擴展的中心交換部件。來自任意端口節點的流量都可以盡可能少的跳數到達任意其它節點端口,以使延遲達到最小。其實現本質上就是解決一對多問題,原來由一臺大型網絡部件實現的功能,為了橫向擴展只能以更多中小型節點替代一個大型部件,減少大型部件向上擴展的物理限制,從而減少了所需核心節點總經濟成本。

第二,控制平面發展。人類每一次把老問題以新方式解決后,又會有新問題出現,如此反復。當我們把中心智能推向邊緣智能后,產生了新的挑戰,傳統模式交換機中心控制不復存在,沒有統一轉發表,沒有集中控制,而集中控制和端對端感知需求依然存在,九九歸一,控制平面集中化就是多對一,這個需求本身沒有消失,消失的是老需求方式。要保證原來的需求,新網絡邊緣設備必須有全網拓撲、路由和控制能力,這樣才可以全網智能,本地轉發,這樣控制方式有點像我們人類社會的聯邦制國家管理,大家都在統一憲法下管理,每個聯邦郡能充分自主的能力管理政府和社會。當業務需要擴展時,只要接入邊緣智能節點,邊緣節點自動感知現有網絡,當中心節點失效時,多接口接入邊緣節點即時、自動無縫轉移到另外轉發平面節點繼續工作。每個邊緣設備都需要智能,需要更高性能CPU、內存和相應芯片組,新型邊緣設備成本通常比傳統接入設備要高得多,因此控制平面要求導致單個邊緣節點成本增加。

第三,管理平面發展。實際上,管理平面和控制平面是相輔相成的。只要控制平面集中實現,整個數據中心交換架構就可以做到多對一,當作虛擬統一交換機管理,管理平面簡單實現也就自然而然了。單個核心節點由于橫向擴展和功能簡單減少經濟成本,單個邊緣節點由于需要智能感知和靈活接入導致研發和硬件成本增加,這一增一減總體就需要IT管理者的平衡藝術了。

總而言之,針對虛擬化交換網絡核心層挑戰,二層多路徑是應對挑戰的必由之路,目前致力于實現二層多路徑標準化組織主要有IETF和IEEE。IETF標準為為TRILL(RFC5556,命名為Transparent Interconnection of Lots of Links)和IEEE標準是802.1aq(SPB,Shortest Path Bridge,最短路徑橋接),他們都采用IS-IS作為基本路由協議確定將數據包傳輸到它的目的地的最短路徑,實現方式大同小異。SPB被IEEE提議為802.1aq,它與TRILL很類似,但是它是使用現有生成樹協議來保持向后兼容的。與TRILL不同的是,SPB可以建立在現有的Ethernet芯片上。目前,TRILL和SPB都已接近完成,預計2011年底就能夠正式標準化。有些供應商在他們的數據中心結構中通過第三種方法多機架鏈路聚集 (M-LAG or MC-LAG)實現了多路徑。

未來網絡技術發展

軟件定義網絡發展原因是轉發平面與控制平面都需要橫向擴展,平行分離,而控制平面的控制信息本身流量有限并可預計,所以人們就不需要昂貴的專門高性能轉發芯片處理控制信息,那么經濟性解決方案就是控制平面由獨立可擴展軟件實現,這就是軟件定義網絡,它的發展是對傳統網絡廠家封閉專有控制平面技術產生了的破壞性創新,將對網絡廠家變革導致巨大推力和影響。OpenFlow開源控制平面協議便是其中一個著名代表。OpenFlow增加了網絡靈活控制能力,分布式節點智能通過OpenFlow指令得以實現,外部OpenFlow控制管理節點的實時控制,集中統一中央智能。OpenFlow根據運行實況實時控制分布式節點,分布式節點生成快速轉發表,無須進行復雜智能分析計算,只要執行網絡轉發平面功能。當新轉發節點加入到OpenFlow網絡時,自動從中央控制節點得的最新網絡配置信息,完成網絡自動化感知。而中央控制節點基于x86標準服務器架構,強大計算能力和橫向擴展特性保證了控制平面擴展性和經濟性。

第四節 云計算虛擬化交換網絡——產品篇

云計算銷售市場爆發增長,聰明的網絡廠家自然不會坐等商業機會來臨,而是主動給力出擊,撲捉市場市場機會,這里就以Cisco、Juniper、Brocade和Force10為例,介紹他們適應云計算虛擬化系統架構。

Cisco FabricPath云網絡基礎架構

FabricPath是思科NX-OS軟件交換機上的創新功能, 可以幫助客戶虛擬化數據中心網絡實現平滑擴展,據稱可實現穩定和可擴展的二層環境路由功能,能夠并行多路徑數據轉發,思科之前又稱之為L2MP(L2 Mutlipath)。FabricPath是TRILL基本功能加上“多重拓撲樹轉發”、“MAC地址學習基于會話層”、“VPC+”、“FHRP”等許多高級功能,可以簡單看作一個“增強版的TRILL”。

FabricPach不再需要運行生成樹協議(STP)來防止環路,所有鏈路基于IS-IS協議建立并同時激活,沒有鏈路被阻斷,使用ECMP(等價多路徑,目前最多16條),顯然降低網絡延遲、大大增加了網絡傳輸帶寬,很好地支持了服務器之間由于虛擬機資源調度而迅速增加的東西流量。如圖14,由于FabricPath網絡引入新的二層數據轉發平面,網絡幀頭包括可路由的源和目的地址,中間幀以源交換機地址作為幀源地址,以目的交換機地址作為幀目的地址,正常以太網幀在進入FabricPath邊緣交換機時被加入FabricPath幀頭,在退出FabricPath邊緣交換機被去除FabricPath幀頭。簡單來說,FabricPath就是Mac in Mac方式,轉發平面是在普通以太網幀疊加上交換機地址,做到交換路由轉發(當然需要加上TTL,因為Time To Live可以防止無限循環)。對于不支持FabricPath的網絡設備, FabricPath網絡對已部署的接入設備來說是一個透明連接。在支持FabricPath的設備上將端口配置為FabricPath模式,系統會自動完成地址分配、路由建立等行為,無需手動干預。2010年Cisco在Nexus 7000交換機上發布了一塊支持FabricPath的32口萬兆光纖板卡,以及相應的軟件。

思科FabricPath轉發機理圖
圖14 思科FabricPath轉發機理圖

Dell Force10 開放云網絡體系架構Open Cloud Networking (OCN)

戴爾公司于2011年8月收購Force10 Networks, 從此這個以高性能數據中心網絡名聞天下的網絡公司成為戴爾開放企業級解決方案的重要一員。Dell Force10新一代數據中心架構產品完全基于TRILL,目前用戶可選擇核心方案是Z9000機架交換機(如圖16),多臺Z9000全網狀互聯一起來實現分布式核心網絡解決方案,每臺Z9000具備32個40 GbE固定端口高性能核心節點交換機。邊緣節點是S4810,可配置64個萬兆或48個萬兆加4個40G,支持DCB、TRILL、EVB和VLT(跨交換機多鏈路),可以智能感知虛擬化網絡,具備豐富虛擬化交換網絡功能。

為了將10 GbE服務器連接到Z9000上,我們需要使用一條4端口多芯軟光纜將一個QSFP+端口拆分成4個10 GbE端口。這使Z9000擴展到2 RU成128個服務器端口。對于尋求更高豎向性能的企業而言,Force10未來還準備交付Z9512高性能模塊交換機,它可以配備4個端口100 GbE接口卡,提供了8個端口40 GbE,40個端口10 GbE兩種選擇,然用戶可以容易在豎向擴展和橫向擴展之間找到平衡點,同時提高了數據中心結構市場的帶寬水平。除了未來預計交付核心節點Z9512解決方案外,Dell Force10還準備推出S7000三合一邊緣節點,可同時支持12個光纖通道接口、同萬兆或FCoE萬兆,從而核心節點和邊緣節點都升級到超低延遲和新的擴展層次。

Dell Force10下一代數據中心分布式網絡拓撲圖(40G互聯)
圖15 Dell Force10下一代數據中心分布式網絡拓撲圖(40G互聯)

第五節 云計算虛擬交換網絡市場——總結篇

根據IDC統計,到2014年底,公共云市場容量發展到2015年729億美金,云網絡廠家在這股商業大潮,各顯英雄本色,努力展現自己獨特價值。下面就讓我們總結分析一下商業趨勢和技術趨勢。

商業趨勢

當新產品或解決方案出現時,網絡廠家為了保留老客戶和更好服務,通常會選擇邊緣層或核心層方面讓新產品保持與現有產品部分兼容,以混合方式組網部署,或者在核心層升級到新架構,或直接替換邊緣層設備,不同層次的新舊產品之間兼容程度對客戶選擇決策影響非常大,因為網絡架構與服務器或存儲架構不一樣(它們常常通過平臺或應用方式平滑升級,降低了架構變化對上層影響),新舊網絡架構之間通常必須互聯互操作。隨著數據中心爆炸規模發展,作為高新科技行業,每個廠家核心優勢體現不是成本領先,而是顯著差異化價值,其往往一方面體現在包括每U高度端口密度、端口帶寬、每端口耗電、設備轉發延遲時間、包轉發速度與系統擴充能力等,另一方面是因機架空間節省、線纜節省、耗電節省、管理人員節省而帶來的總擁有成本節省。實際上,每個廠家由于進入市場時間點不同,客戶定位不同,解決方案也很大不同,結果是架構整體表現在不同客戶、不同應用和不同場合也都非常不同,通常都會把他們表現最好的一面展現到用戶和媒體前面。除了客戶產品定位外,網絡廠家市場覆蓋方式也各不相同,有直接模式、全渠道模式或混合模式,每種模式對產品到市場、客戶接受速度和盈利都非常不一樣,由于篇幅所述,這里就不多講了。

仔細思考一下,網絡廠家產品的客戶價值其實存在于控制平面和轉發平面兩個方向。我們知道,網絡轉發平面都采用硬件實現,一般會建立在高效芯片架構基礎之上,而在摩爾定律下,芯片性能每十八個月就會提升一倍,所以一般來說網絡新進入者后來者或小廠家會利用最新科技成果,研發設計基于最新架構的全新轉發平面,體現比如延遲、帶寬、密度和能耗等差異化價值,與競爭對手拉開差距。但是控制平面所體現價值過程與轉發平面完全不同,控制平面需求與客戶應用耦合度很高,甚至不同客戶群有完全不同控制和管理要求(比如電信網絡和普通企業需求差別就非常大),領先市場廠家往往由于先前系統架構限制,在經濟學“路徑依賴”原理下,無法放棄原有架構,只能基于原有架構的局部升級,好在領先廠家往往有大量和長時間的客戶安裝基礎,所以領先者會不斷積累客戶前端反饋,改善提高產品控制平面,另一方面因為控制平面往往以軟件實現,易于升級,不但如此,領先者里會積極建立圍繞在控制平面周圍的生態伙伴,開放應用接口、培育忠實技術粉絲,發展更多更好的服務伙伴,形成龐大的利益共同體,交付給客戶包括控制、管理平面和服務在內一站式方案。所以我們在網絡解決方案選擇決策時需要根據業務要求,不同業務工作負載類型不一樣,對IT資源消耗也就不一樣,需要平衡轉發平面和控制平面帶來的不同經濟性影響,對它們做具體經濟分析。

技術趨勢

云計算虛擬化到來,核心擴展是彈性計算實現最有效方式之一,因此幾乎所有網絡廠家極力開發提供按需橫向擴展的核心層解決方案,核心層設備以100G或40G互聯,不過由于橫向擴展節點之間也需要超低延遲同步,所以核心機箱橫向最大數目有限制,比如4到8臺。核心層節點之間無協議轉換發生,利用高速轉發平面芯片充分利用最大包轉發率和帶寬極限,達到極速轉發。因為核心節點芯片性能高,成本也高,為了降低客戶使用成本和利用最大容量,消除生成樹協議,提供跨機箱Trunk技術,以并行無生成樹協議下聯就是來自用戶的技術訴求。由于核心節點橫向擴展數目有限,為了更高性能或擴展性,廠家同時堅持核心層豎向擴展,提供高密度、高容量和高帶寬接入,比如一些廠家單機箱可支持300個萬兆、數十個40G。所以橫向擴展架構和豎向擴展架構是相互作用過程,不同產品定位就需要不同擴展架構技術。

核心層橫向擴展,邊緣層更是如此。網絡廠家不遺余力支持邊緣層按需橫向擴展,包括使用虛擬機箱技術或堆疊技術、多鏈路綁定上聯、消除生成樹等技術以10G或40G上聯到核心。邊緣節點接口方面提供高密度、混合多端口一體機頂交換機,混合接口一般支持千兆、萬兆、FCoE、FC和iSCSI,并支持TRILL或SPB協議,支持二層路由多路徑,接入到二層核心層。邊緣節點與計算節點或存儲節點相連,通過支持EVB、VEPA等虛擬主機協議智能感知虛擬計算節點,完成虛擬移動性策略漂移。可是邊緣層發展情況比較復雜,目前業界還沒有邊緣層統一標準,各個網絡廠家八仙過海,各顯神通。除了虛擬計算智能外,邊緣層還常常擔負網絡增強服務角色,比如負載均衡、防火墻、入侵檢測和日志記錄等,這也是業界發展的重要方向。

鏈接已復制,快去分享吧

企業網版權所有?2010-2024 京ICP備09108050號-6京公網安備 11010502049343號

  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 绥宁县| 临高县| 建始县| 罗平县| 台南县| 云安县| 云林县| 莫力| 屏东县| 论坛| 若羌县| 邛崃市| 句容市| 长海县| 白水县| 蒙自县| 德化县| 邮箱| 麻江县| 珲春市| 昌江| 左权县| 莱芜市| 土默特左旗| 承德县| 湖南省| 封丘县| 枝江市| 枣庄市| 阿城市| 潞城市| 乃东县| 象州县| 安达市| 吴旗县| 三门县| 翁源县| 拉孜县| 城固县| 花莲县| 迁西县|