云計算的各方面定義很多，基于用戶的視角來看，目的就是讓使用者在不需了解資源的具體情況下做到按需分配，將計算資源虛擬化為一片云。站在高處看，當前的主流云計算更貼切于云服務(wù)，個人認為可理解為早先運營商提供數(shù)據(jù)中心服務(wù)器租用服務(wù)的延伸。以前用戶租用的是一臺臺物理服務(wù)器，現(xiàn)在租用的是虛擬機，是軟件平臺甚至是應(yīng)用程序。公認的三個云計算服務(wù)層次是IaaS（Infrastructure as a Service）、PaaS（Platform as a Service）和SaaS（Software as a Service），分別對應(yīng)硬件資源、平臺資源和應(yīng)用資源。對于用戶來說：

1、當提供商給你的是一套a 個核CPU、b G大小內(nèi)存的主機、c M帶寬網(wǎng)絡(luò)以及d G大小存儲空間，需要你自己去裝系統(tǒng)和搞定應(yīng)用程序，那么這就是IaaS，舉例如Amazon EC2；

2、當提供的是包含基本數(shù)據(jù)庫和中間件程序的一套完整系統(tǒng)，但你還需要根據(jù)接口編寫自己的應(yīng)用程序時，那么就是PaaS，舉例如Google AppEngine、Microsoft Azure和Amazon SimpleDB, SQS；

3、最傻瓜的方式自然是連應(yīng)用程序都寫好了，例如你只需要告訴服務(wù)提供商想要的是個500人的薪酬管理系統(tǒng)，返回的服務(wù)就是個HTTPS的地址，設(shè)定好帳號密碼就可以訪問過去直接使用，這就是SaaS了，如SalesForce、Yahoo Hadoop和Cisco Webex: Collaboration SaaS等。

為啥舉例都是國外的呢，因為國內(nèi)目前的云服務(wù)狀況是，能提供的都處于IaaS階段，有喊著要做PaaS的，但還沒聽說有SaaS的。

說完公共的，該講些私貨了。

個人理解云計算的核心首先是計算，什么網(wǎng)絡(luò)、存儲、安全等等都是外延，從技術(shù)上講云計算就是計算虛擬化。最早的云計算來自于網(wǎng)格計算，通過一堆性能較差的服務(wù)器完成一臺超級計算機才能完成的計算任務(wù)，簡單的說就是計算多虛一。但是現(xiàn)如今一虛多（VM/XEN等）也被一些廠商扯著大旗給忽悠進來，并且成為主流。但是單從技術(shù)角度來看，這兩者是南轅北轍的。因此云計算技術(shù)在下面被作者主觀的分為集中云與分散云兩個概念來闡述。

2.1 集中云

首先是集中云，根正苗紅的多虛一，最早期的也是目前最大的一個典型實際用戶就是Google了 (注意這里說的不是現(xiàn)在Google云服務(wù))。搜索引擎是超級消耗資源的典型應(yīng)用，從你在網(wǎng)頁上一個關(guān)鍵詞的搜索點擊，到搜索結(jié)果的產(chǎn)生，后臺是經(jīng)過了幾百上千臺服務(wù)器的統(tǒng)一計算。至于搜索引擎的工作模型本文就不多說了，網(wǎng)上很多資料的。隨著互聯(lián)網(wǎng)的發(fā)展，現(xiàn)在的開心、淘寶、新浪微博等等（好孩子不翻墻），雖然使用者看到的只是在簡單的頁面進行點擊輸入，但是后臺的工作量已經(jīng)遠遠不是少量幾臺大型服務(wù)器能夠勝任的了，即使天河一號也不見得能搞定。集中云的應(yīng)用主力就是這些大型的互聯(lián)網(wǎng)內(nèi)容提供商們，當然還有一些傳統(tǒng)應(yīng)用如地震、氣象和科研項目的計算也會存在此類需求。

了解了需求，下面簡單談下技術(shù)，上圖是Cluster集群多虛一技術(shù)的簡單分布，除了按照承載網(wǎng)絡(luò)類型可分成Infiniband和Ethernet外，根據(jù)技術(shù)分，還可分為Active-Standby主備與LoadBalance負載均衡兩類。

主備模式好理解，所有的Server里面只有一臺干活，其他都是候著的，只有偵聽到干活的歇菜了，才開始接管處理任務(wù)。主備模式大部分就二虛一提供服務(wù)，多了如三虛一什么的其實意義都不太大，無非是為了再多增加些可靠性。主備模式以各類HA集群技術(shù)為代表。

而負載均衡模式復雜一些，在所有的LB技術(shù)中都存在兩個角色，協(xié)調(diào)者與執(zhí)行者，協(xié)調(diào)者一般是一個或多個（需要主備冗余時），主要工作就是接活兒和分活兒（有點兒像包工頭）；而執(zhí)行者就只處理計算了，分到啥就完成啥，典型的苦力。從流量模型上來說，LB集群技術(shù)有來回路徑一致和三角傳輸兩種，來回路徑一致指流量都是客戶發(fā)起連接，請求協(xié)調(diào)者進行處理，協(xié)調(diào)者分配任務(wù)給執(zhí)行者進行計算，計算完成后結(jié)果會都返回到協(xié)調(diào)者，再由協(xié)調(diào)者應(yīng)答客戶。

這種結(jié)構(gòu)簡單，計算者不需要了解外界情況，由協(xié)調(diào)者統(tǒng)一作為內(nèi)外接口，安全性最高。此模型主要應(yīng)用于搜索和地震氣象科研計算等業(yè)務(wù)處理中。三角傳輸模型指計算者完成計算后直接將結(jié)果反饋給客戶，此時由于計算者會和客戶直接通信，造成安全性降低，但返回流量減少了協(xié)調(diào)者這個處理節(jié)點，性能得到很大提升。此模型主要應(yīng)用于騰訊新浪的新聞頁面和阿里淘寶的電子商務(wù)等WEB訪問業(yè)務(wù)。

集中云在云服務(wù)中屬于富人俱樂部的范圍，不是給中小企業(yè)和個人玩的，實際上都是各大互聯(lián)網(wǎng)服務(wù)提供商自行搭建集中云以提供自己的業(yè)務(wù)給用戶，不會說哪天雅虎去租用個Google的云來向用戶提供自己的新聞頁面訪問。集中云服務(wù)可能的租用對象是那些高度科研項目，因而也導致當前集中云建設(shè)上升到國家宏觀戰(zhàn)略層面的地位。你能想象哪天百度的云服務(wù)提供給總裝研究院去計算個導彈軌跡，核裂變什么嘛，完全不可能的事。

最后是多虛一對網(wǎng)絡(luò)的需求。在集中云計算中，服務(wù)器之間的交互流量多了，而外部訪問的流量相對減少，數(shù)據(jù)中心網(wǎng)絡(luò)內(nèi)部通信的壓力增大，對帶寬和延遲有了更高的要求，自然而然就催生出后面會講到的一些新技術(shù)（L2MP/TRILL/SPB等）。

題外話，當前的多虛一技術(shù)個人認為不夠給力，現(xiàn)在把10臺4核CPU的服務(wù)器虛擬合一后，虛擬的服務(wù)器遠遠達不到一個40核CPU的計算能力。準確的說現(xiàn)在的多虛一只能基于物理服務(wù)器的粒度進行合并，理想的情況應(yīng)該是能夠精細到CPU核以及每臺設(shè)備的內(nèi)存緩存等等物理構(gòu)件虛擬合一。這塊應(yīng)該就涉及到超算了，不熟不深談?？偟膩碚f認為技術(shù)進步空間巨大，有些搞頭。

2.2?分散云

再講分散云，這塊是目前的主流，也是前面提到的云服務(wù)的關(guān)鍵底層技術(shù)。由于有VMware和Citrix等廠家在大力推廣，而且應(yīng)用內(nèi)容較集中云更加平民化，隨便找臺PC或服務(wù)器，裝幾個虛擬機大家都能玩一玩，想干點兒啥都成，也就使其的認知度更加廣泛。

一虛多的最主要目的是為了提高效率，力爭讓所有的CPU都跑到100%，力爭讓所有的內(nèi)存和帶寬都占滿。以前10臺Server干的事，我整兩臺Server每臺跑5個虛擬機VM（Virtual Machine）就搞定了，省電省空間省制冷省網(wǎng)線，總之省錢是第一位的（用高級詞兒就是綠色環(huán)保）。技術(shù)方面從實現(xiàn)方案來看，目前大致可分為三類：

操作系統(tǒng)虛擬化OS-Level

在操作系統(tǒng)中模擬出一個個跑應(yīng)用程序的容器，所有虛擬機共享內(nèi)核空間，性能最好，耗費資源最少，一個CPU號稱可最多模擬500個VPS(Virtual Private Server)或VE(Virtual Environment)。缺點是操作系統(tǒng)唯一，如底層操作系統(tǒng)跑的Windows，VPS/VE就都得跑Windows。代表是Parallels公司（以前叫SWsoft）的Virtuozzo（商用產(chǎn)品）和OpenVZ（開源項目）。Cisco的Nexus 7000猜測也是采用這種方案運行的VDC技術(shù)，但不太清楚為什么會有最多4個VDC的數(shù)量限制，也許是基于當前應(yīng)用場景進行規(guī)格控制的一種商業(yè)手段。

主機虛擬化Hosted

先說下Hypervisor或叫做Virtual Machine Monitor（VMM），它是管理虛擬機VM的軟件平臺。在主機虛擬化中，Hypervisor就是跑在基礎(chǔ)操作系統(tǒng)上的應(yīng)用軟件，與OS-Level中VE的主要區(qū)別在于：

Hypervisor構(gòu)建出一整套虛擬硬件平臺（CPU/Memory/Storage/Adapter），上面需要你再去安裝新的操作系統(tǒng)和需要的應(yīng)用軟件，這樣底層和上層的OS就可以完全無關(guān)化，諸如Windows上跑Linux一點兒問題沒有；

VE則可以理解為盜用了底層基礎(chǔ)操作系統(tǒng)的資源去欺騙裝在VE上的應(yīng)用程序，每新創(chuàng)建出一個VE，其操作系統(tǒng)都是已經(jīng)安裝好了的，和底層操作系統(tǒng)完全一樣，所以VE比較VM（包括主機虛擬化和后面的裸金屬虛擬化）運行在更高的層次上，相對消耗資源也少很多。

主機虛擬化中VM的應(yīng)用程序調(diào)用硬件資源時需要經(jīng)過:VM內(nèi)核->Hypervisor->主機內(nèi)核，導致性能是三種虛擬化技術(shù)中最差的。主機虛擬化技術(shù)代表是VMware Server（GSX）、Workstation和Microsoft Virtual PC、Virtual Server等。

裸金屬虛擬化Bare-metal

裸金屬虛擬化中Hypervisor直接管理調(diào)用硬件資源，不需要底層操作系統(tǒng)，也可以理解為Hypervisor被做成了一個很薄的操作系統(tǒng)。這種方案的性能處于主機虛擬化與操作系統(tǒng)虛擬化之間。代表是VMware ESX Server、Citrix XenServer和Microsoft Hyper-V。

上圖描述了三種虛擬化方案的形態(tài)區(qū)別。當前分散云數(shù)據(jù)中心服務(wù)器虛擬化使用的主要是Bare-Metal方案。分散云給數(shù)據(jù)中心網(wǎng)絡(luò)帶來了新的挑戰(zhàn)，虛擬機之間的數(shù)據(jù)通信管理需求促使了一系列網(wǎng)絡(luò)新技術(shù)的發(fā)展。在OS-Level與Hosted方案中，虛擬機都是架設(shè)于操作系統(tǒng)之上的，因此VM/VE之間的通信主要由同樣運行于基礎(chǔ)操作系統(tǒng)之上的網(wǎng)絡(luò)交換應(yīng)用程序來完成。而在最主流的Bare-Metal結(jié)構(gòu)中，由于Hypervisor薄操作系統(tǒng)的引入，性能、管理、安全和可靠性等多維度的考慮，造成VM間網(wǎng)絡(luò)通信管理發(fā)展出不同的技術(shù)道路（EVB與BPE），后文會對這些技術(shù)方向加以詳述。

VMware ESX與Xen/Hyper-V的Bare-Metal方案實現(xiàn)結(jié)構(gòu)有所不同，簡單如下圖所示。

分散云除了給網(wǎng)絡(luò)帶來上述的VM通信問題，同樣由于其對服務(wù)器硬件能力的極端榨取，造成網(wǎng)絡(luò)中的流量壓力增大，與集中云一樣存在著帶寬擴展的需求。原本一臺服務(wù)器一個操作系統(tǒng)跑一個應(yīng)用只需要10M流量帶寬就夠了，現(xiàn)在裝了10個VM跑10個應(yīng)用，帶寬可能就需要100M了。

大型機與小型機的一虛多技術(shù)早在30年前IBM就做出來了，現(xiàn)在RISC平臺上已經(jīng)相當完善了，相比較而言X86架構(gòu)的虛擬化才處于起步階段，但X86架構(gòu)由于性價比更高成為了分散云計算的首選。

X86架構(gòu)最早期是純軟件層面的Hypervisor提供虛擬化服務(wù)，缺陷很多，性能也不夠，直到2006年Intel推出了實現(xiàn)硬件輔助虛擬化的VT技術(shù)CPU產(chǎn)品后才開始迅猛發(fā)展（AMD也跟著出了VM技術(shù)）。硬件輔助虛擬化技術(shù)主要包括CPU/Chipset/Network Adapter等幾個方面，和網(wǎng)絡(luò)技術(shù)緊密相關(guān)的就是網(wǎng)卡虛擬化了，后文會對如SR-IOV等網(wǎng)卡虛擬化技術(shù)應(yīng)用進行更具體分析。隨著2007年Intel VT FlexMigration技術(shù)的推出，虛擬機遷移成為可能，2009年Intel支持異構(gòu)CPU間動態(tài)遷移再次向前邁進。

vMotion

這里再多嘮叨幾句vMotion技術(shù)。vMotion是VMware公司提出的虛擬機動態(tài)遷移技術(shù)名稱（XEN也有相應(yīng)的XENMotion技術(shù)），由于此名稱被喊得最早，范圍最廣，認知度最高，因此下文提到虛擬機遷移技術(shù)時大都會使用vMotion來代稱。

先要明確vMotion是一項資源管理技術(shù)，不是高可靠性技術(shù)，如果你的某臺服務(wù)器或VM突然宕機了，vMotion是無助于應(yīng)用訪問進行故障切換和快速恢復的。vMotion是將一個正常的處于服務(wù)提供中的VM從一臺物理服務(wù)器搬家到另一臺物理服務(wù)器的技術(shù)，vMotion的目的是盡可能方便的為服務(wù)管理人員提供資源調(diào)度轉(zhuǎn)移手段，當物理服務(wù)器需要更換配件關(guān)機重啟啦，當數(shù)據(jù)中心需要擴容重新安排資源啦，這種時候vMotion就會有用武之地了。

設(shè)想一下沒有vMotion上述遷移工作是怎么完成的，首先需要將原始物理服務(wù)器上的VM關(guān)機，再將VM文件拷貝到新的物理服務(wù)器上，最后將VM啟動，整個過程VM對外提供的服務(wù)中斷會達到幾分鐘甚至幾小時的級別。而且需要來回操作兩臺物理服務(wù)器上的VM，對管理人員來說也很忙叨。

使用vMotion后，兩臺物理服務(wù)器使用共享存儲來保存VM文件，這樣就節(jié)省了上述步驟2中的時間， vMotion只需在兩臺物理服務(wù)器間傳遞當前的服務(wù)狀態(tài)信息，包括內(nèi)存和TCP等上層連接表項，狀態(tài)同步的拷貝時間相對較短，而且同步時原始VM還可以提供服務(wù)使其不會中斷。同步時間跟VM當前負載情況及遷移網(wǎng)絡(luò)帶寬有關(guān)，負載大了或帶寬較低使同步時間較長時，有可能會導致vMotion出現(xiàn)概率性失敗。當狀態(tài)同步完成后，原始物理服務(wù)器上的VM會關(guān)閉，而新服務(wù)器上的VM激活（系統(tǒng)已經(jīng)在狀態(tài)同步前啟動完畢，始終處于等待狀態(tài)），此時會有個較短的業(yè)務(wù)中斷時間，可以達到秒級。再者vMotion是通過VMware的vCenter管理平臺一鍵化完成的，管理人員處理起來輕松了許多。

這里要注意vMotion也一定會出現(xiàn)業(yè)務(wù)中斷，只是時間長短區(qū)別，不要輕易被一些宣傳所忽悠。想想原理，不論怎么同步狀態(tài)，只要始終有新建發(fā)生，在同步過程中原始服務(wù)器上新建立的客戶連接，新服務(wù)器上都是沒有的，切換后這部分連接勢必被斷開重建，零丟包只能是理想值。VMware也同樣建議將vMotion動作安排在業(yè)務(wù)量最少的時候進行。

vMotion什么場景適用呢？首先肯定得是一虛多的VM應(yīng)用場景，然后是對外業(yè)務(wù)中斷恢復的可靠性要求極高，一般都是7*24小時不間斷應(yīng)用服務(wù)才用得上，最后是計算節(jié)點規(guī)模始終在不斷增長，資源調(diào)度頻繁，管理維護工作量大的數(shù)據(jù)中心。

另外共享存儲這個強制要求會給數(shù)據(jù)中心帶來了整體部署上的限制，尤其是下面提到的跨數(shù)據(jù)中心站點vMotion時，跨站點共享存儲的問題解決起來是很麻煩的，由于這部分內(nèi)容和網(wǎng)絡(luò)關(guān)系不大，屬于存儲廠商的地盤，對跨站點共享存儲技術(shù)有興趣的讀者可以參考EMC/IBM等廠商的資料看看，本文就不過多介紹了。

vMotion的出現(xiàn)推動了數(shù)據(jù)中心站點間大二層互聯(lián)和多站點動態(tài)選路的網(wǎng)絡(luò)需求，從而導致OTV和LISP等一系列新網(wǎng)絡(luò)技術(shù)的出現(xiàn)。

2.3?云計算小結(jié)

通過前面的描述，希望大家能對云計算有個較為清晰的概念。云計算還有一大塊內(nèi)容是平臺管理資源調(diào)度方面（目前很多廠家吆喝的云計算都是云平臺）。這部分主要針對客戶如何更便捷的創(chuàng)建與獲取虛擬化服務(wù)資源，實際過程就是用戶向平臺管理軟件提出服務(wù)請求，管理平臺通過應(yīng)用程序接口API（Application Program Interface）將請求轉(zhuǎn)化為指令配置下發(fā)給服務(wù)器、網(wǎng)絡(luò)、存儲和操作系統(tǒng)、數(shù)據(jù)庫等，自動生成服務(wù)資源。需要網(wǎng)絡(luò)做的就是設(shè)備能夠識別管理平臺下發(fā)的配置，從技術(shù)創(chuàng)新的角度講，沒有啥新鮮東西，就不多說了。當前的云平臺多以IaaS/PaaS為主，能做到提供SaaS的極少。但在今后看來，SaaS將會成為云服務(wù)租用主流，中小企業(yè)和個人可以節(jié)省出來IT建設(shè)和維護的費用，更專注于自身的業(yè)務(wù)發(fā)展。

總結(jié)一下云計算給數(shù)據(jù)中心網(wǎng)絡(luò)帶來的主要變化：

1、?更高的帶寬和更低的延遲

2、?服務(wù)器節(jié)點（VM）規(guī)模的增加

3、?VM間通信管理

4、?跨數(shù)據(jù)中心站點間的二層互聯(lián)以承載vMotion

題外再多說兩句，計算虛擬化中一虛多與多虛一結(jié)合使用才是王道。但目前云計算服務(wù)提供商能夠提供的只是先將物理服務(wù)器一虛多成多臺VM，再通過LB/集群計算等技術(shù)將這些VM對外多虛一成一個可用的資源提供服務(wù)。個人感覺，如果能做到先將一堆物理服務(wù)器虛擬成一臺幾萬個核Super Computer，用戶再根據(jù)自己的需要幾個幾十個核的自取資源，這樣才更有云計算的樣子， Super Computer就是那朵云。當然計算虛擬化的時候不光是核的調(diào)配，還要包括IO/Memory等一起進行調(diào)度，這里只是簡單舉例。

3?、數(shù)據(jù)中心

數(shù)據(jù)中心的產(chǎn)生有多早？從人類開始將信息記錄到介質(zhì)上傳遞開始就有了數(shù)據(jù)中心，那個記載信息的介質(zhì)（石頭或樹皮）就是數(shù)據(jù)中心，不過那時的網(wǎng)絡(luò)是靠手手相傳而已。如果更甚一些，可以理解人類產(chǎn)生語言開始，知識最多的人（酋長/祭祀）就是數(shù)據(jù)中心，口口相傳就相當于現(xiàn)如今的網(wǎng)絡(luò)傳輸。有人該說，夸張了哈，寫作手法而已，只是想突出一下數(shù)據(jù)中心的重要性。

當計算機網(wǎng)絡(luò)連接到Server的那一刻起，整個世界的網(wǎng)絡(luò)就從網(wǎng)狀變成了樹狀，一個個數(shù)據(jù)中心就是網(wǎng)絡(luò)世界的根。

3.1?Client與Server

在所有的數(shù)據(jù)通信會話中，只有兩個永恒的角色，Client與Server。為了下文敘述簡便，作者把數(shù)據(jù)中心內(nèi)部的終端統(tǒng)一稱之為Server，數(shù)據(jù)中心外部的為Client。這樣網(wǎng)絡(luò)間的流量通信就只剩下Client-Server（CS）與Server-Server（SS）兩種了。其實更準確說還是只有CS一種，SS通信也是有個發(fā)起方和響應(yīng)方的。QQ/MSN等即時通信軟件的流量模型實際可理解為CSC；唯有P2P對CS結(jié)構(gòu)有所顛覆，但不管怎么處理也必定會存在Server角色進行最初的調(diào)度。

所有數(shù)據(jù)中心需要處理的業(yè)務(wù)就是CS和SS兩種，CS肯定是基于IP進行L3轉(zhuǎn)發(fā)的了，SS則分為基于IP的L3和基于MAC的L2兩種轉(zhuǎn)發(fā)方式?；贗P的SS通信主要是不同業(yè)務(wù)間的數(shù)據(jù)調(diào)用，如WEB/APP服務(wù)器去調(diào)用DB服務(wù)器上的數(shù)據(jù)，再如有個員工離職，職工管理系統(tǒng)會同步通知薪酬管理、考勤管理、績效管理等一系列系統(tǒng)進行刪除信息的相關(guān)操作。基于MAC的SS通信則是同一類服務(wù)器間的數(shù)據(jù)同步計算，比如使用WEB集群分流用戶訪問時，需要對修改或增刪的數(shù)據(jù)進行集群同步；再比如多虛一中集群一起計算任務(wù)時協(xié)調(diào)者和執(zhí)行者之間的大量通信進行任務(wù)調(diào)度。

可以看出云計算數(shù)據(jù)中心給網(wǎng)絡(luò)帶來的挑戰(zhàn)主要是基于MAC的二層（OSI模型）SS通信。在一虛多技術(shù)影響下，Server的概念已經(jīng)擴展到以單臺VM為基礎(chǔ)單元，因此可以引出下面這個圖，看看新網(wǎng)絡(luò)技術(shù)是如何劃分的。

Network1：VM到VM之間的SS二層互聯(lián)網(wǎng)絡(luò)

Network2：DC站點內(nèi)部SS二層互聯(lián)網(wǎng)絡(luò)

Network3：跨DC站點間的SS二層互聯(lián)網(wǎng)絡(luò)

Network4：DC到Client之間的CS三層互聯(lián)網(wǎng)絡(luò)

后文的技術(shù)章節(jié)就會針對這些部分進行展開，詳細說下都有哪些技術(shù)分別對應(yīng)在這四段網(wǎng)絡(luò)中，這些技術(shù)的特點是什么。

3.2?層次化與扁平化

數(shù)據(jù)中心的網(wǎng)絡(luò)結(jié)構(gòu)取決于應(yīng)用計算模型，計算模型主要分為層次化與扁平化兩種結(jié)構(gòu)。層次化結(jié)構(gòu)如下圖所示，典型的應(yīng)用如WEB-APP-DB、搜索引擎或高性能計算（地震、科研）等。特點是客戶請求計算結(jié)果必須逐層訪問，返回數(shù)據(jù)也要逐層原路返回。

計算模型扁平化結(jié)構(gòu)如下圖所示，特點是數(shù)據(jù)層服務(wù)器會將結(jié)果直接返回給客戶，不需要再由接口層服務(wù)器進行處理，也有管這種模型叫做三角傳輸?shù)?。典型的?yīng)用如一些Internet網(wǎng)站服務(wù)采用的LB結(jié)構(gòu)，LB服務(wù)器就是只做調(diào)度，WEB服務(wù)器會直接將請求結(jié)果返回給用戶。

注意，上面說的是計算模型，和網(wǎng)絡(luò)模型并不是一一對應(yīng)，采用層次化結(jié)構(gòu)計算模型一樣可以進行扁平化組網(wǎng)，如下圖所示。

從網(wǎng)絡(luò)角度講，扁平化相比較層次化結(jié)構(gòu)最大的好處是可以減少服務(wù)器的網(wǎng)卡接口數(shù)量（省錢），然而缺點是沒有清晰的層次，部署維護的復雜度就會相應(yīng)提升?？傮w來說，當前數(shù)據(jù)中心實際組網(wǎng)建設(shè)中，這兩種方式誰都沒占據(jù)到絕對優(yōu)勢，上哪種結(jié)構(gòu)完全看規(guī)劃者的考量重點是在哪個方面。

前面說過，云計算主要分為多虛一與一虛多兩種虛擬化結(jié)構(gòu)。一虛多對傳統(tǒng)計算模型沒有太大影響，只是將其服務(wù)器從物理機到虛擬機數(shù)量規(guī)模擴大了N倍，網(wǎng)絡(luò)規(guī)模也隨之進行擴大。而多虛一中，協(xié)調(diào)者角色對應(yīng)了接口層服務(wù)器，執(zhí)行者角色則對應(yīng)數(shù)據(jù)層服務(wù)器，由于此時大量的通信交互是在不同執(zhí)行者之間或執(zhí)行者與協(xié)調(diào)者之間，需要重點關(guān)注的大規(guī)模網(wǎng)絡(luò)就由原來的接口層服務(wù)器之前，轉(zhuǎn)移到了接口層服務(wù)器與數(shù)據(jù)層服務(wù)器之間。

3.3?三層結(jié)構(gòu)與兩層結(jié)構(gòu)

在以往的數(shù)據(jù)中心網(wǎng)絡(luò)建設(shè)時，關(guān)注的重點都是指接口層服務(wù)器前的網(wǎng)絡(luò)，傳統(tǒng)的三層網(wǎng)絡(luò)結(jié)構(gòu)如下圖所示。其中的匯聚層作為服務(wù)器網(wǎng)關(guān)，可以增加防火墻、負載均衡和應(yīng)用加速等應(yīng)用優(yōu)化設(shè)備。

但在云計算數(shù)據(jù)中心里面Ethernet網(wǎng)絡(luò)規(guī)模擴大，流量帶寬需求增加，因此不會在網(wǎng)絡(luò)中間位置再插入安全和優(yōu)化設(shè)備了，轉(zhuǎn)發(fā)性能太低，上去就是瓶頸，匯聚層的位置也就可有可無了。再加上帶寬收斂比的問題，短期內(nèi)大型云計算數(shù)據(jù)中心網(wǎng)絡(luò)里面不會出現(xiàn)匯聚層的概念。以前是百兆接入、千兆匯聚、萬兆核心，現(xiàn)在服務(wù)器接入已經(jīng)普及千兆向著萬兆邁進了，除非在框式交換機上40G/100G接口真的開始大規(guī)模部署，還有可能在云計算數(shù)據(jù)中心里面再見到超過兩層的級聯(lián)結(jié)構(gòu)網(wǎng)絡(luò)?，F(xiàn)如今的云計算數(shù)據(jù)中心流行的都是如下圖所示的千兆接入，萬兆核心的兩層網(wǎng)絡(luò)結(jié)構(gòu)。

此兩層網(wǎng)絡(luò)結(jié)構(gòu)部署在接口層服務(wù)器之前，則一般會將服務(wù)器網(wǎng)關(guān)部署在Core Switch上，但前提是網(wǎng)絡(luò)規(guī)模不會太大，Core不會太多（2個就差不多了），否則VRRP/HSRP等多網(wǎng)關(guān)冗余協(xié)議只能走到一個活動網(wǎng)關(guān)，會導致網(wǎng)絡(luò)效率很低。還有一種方式是將服務(wù)器網(wǎng)關(guān)部署在Access Switch上，Access SW與Core SW之間通過OSPF等動態(tài)路由協(xié)議達到全互聯(lián)，使用等價路由達到多Core SW的負載均擔。但此方式的缺點是L3路由交互轉(zhuǎn)發(fā)效率較低，部署復雜且占用大量IP地址。在未來的TRILL/SPB等二層Ethernet技術(shù)結(jié)構(gòu)中，可能會出現(xiàn)專門作為網(wǎng)關(guān)與外部進行IP層面通信用的邊緣交換機（由于出口規(guī)模有限，2-4臺足夠處理），內(nèi)部的Core SW只做二層轉(zhuǎn)發(fā)，可以大規(guī)模部署以滿足內(nèi)部服務(wù)器交互的需求，如下圖所示。

當遇到多虛一高性能計算的模型，則二層網(wǎng)絡(luò)結(jié)構(gòu)會被部署在接口服務(wù)器與數(shù)據(jù)服務(wù)器之間，為二者構(gòu)建純二層的大規(guī)模交互網(wǎng)絡(luò)，結(jié)構(gòu)如下圖所示。

3.4?Server與Storage

前面說的CS/SS網(wǎng)絡(luò)可以統(tǒng)稱為數(shù)據(jù)中心前端網(wǎng)絡(luò)，目前和以后基本上都是IP+Ethernet一統(tǒng)天下（IB Infiniband只能吃到高性能計算的一小口）。有前端當然就有后端，在數(shù)據(jù)中心里面，服務(wù)器與存儲設(shè)備連接的網(wǎng)絡(luò)部分統(tǒng)稱為數(shù)據(jù)中心后端網(wǎng)絡(luò)。就目前和短期的未來來看，這塊兒都是FC的天下。

簡單說兩句存儲，DAS（Direct Attached Storage）直連存儲就是服務(wù)器里面直接掛磁盤，NAS（Network Attached Storage）則是網(wǎng)絡(luò)中的共享文件服務(wù)器，此二者大多與數(shù)據(jù)中心級別存儲沒什么關(guān)系。只有SAN（Storage Area Network）才是數(shù)據(jù)中心存儲領(lǐng)域的霸主，磁盤陣列會通過FC或TCP/IP網(wǎng)絡(luò)注冊到服務(wù)器上模擬成直連的磁盤空間。而目前FC SAN是主流中的主流，基于TCP/IP的IP SAN等都是配太子讀書的角色。

在服務(wù)器到存儲的后端網(wǎng)絡(luò)中，涉及到IO同步問題，高速、低延遲與無丟包是對網(wǎng)絡(luò)的基本需求，而Ethernet技術(shù)擁有沖突丟包的天然缺陷，F(xiàn)C的無丟包設(shè)計使其領(lǐng)先一步，加上早期Ethernet還掙扎在100M帶寬時，F(xiàn)C已經(jīng)可以輕松達到2G，所以在后端網(wǎng)絡(luò)中從開始到現(xiàn)在都是FC獨占鰲頭。但是從發(fā)展的眼光看，Ethernet目前已經(jīng)向著40G/100G邁進，而FC的演進并不理想，無論是BASE10的10/20/40G路線（主要用在FC交換機之間，目前基本已經(jīng)被淘汰）還是BASE2的2/4/8/16/32G路線（當前主流FC應(yīng)用）都已經(jīng)落后，加上各種以太網(wǎng)零丟包技術(shù)（CEE/DCE/DCB）的出現(xiàn)，以后鹿死誰手還真不好說。

在目前階段，為了兼容數(shù)據(jù)中心已有的主流FC網(wǎng)絡(luò)和存儲設(shè)備，在基于iSCSI技術(shù)的IP SAN技術(shù)沒能開花結(jié)果的情況下，眾多Ethernet網(wǎng)絡(luò)廠商又推出了FCoE來蠶食服務(wù)器到存儲這塊蛋糕。下文技術(shù)章節(jié)會專門介紹FCoE的內(nèi)容。

先簡單說下，F(xiàn)CoE沒有惦著像IP SAN那樣一下子完全取代FC去承載后端網(wǎng)絡(luò)，而是走前后端網(wǎng)絡(luò)融合，逐步蠶食的路線，是網(wǎng)絡(luò)廠商們將數(shù)據(jù)中心的核心由服務(wù)器向網(wǎng)絡(luò)設(shè)備轉(zhuǎn)移的重要武器。如下圖，就是看誰做太陽，誰做星星。相比較IP SAN的壯烈犧牲，F(xiàn)CoE采用了一條更為迂回的兼容道路，目前已經(jīng)出現(xiàn)了支持FCoE的存儲設(shè)備，也許Ethernet完全替代FC的時代真的能夠到來。

如果FCoE能成功，雖然短期內(nèi)交換機、服務(wù)器和存儲的價格對比不會有太大的變化，但是占據(jù)了核心位置，對未來的技術(shù)發(fā)展就有了更大的話語權(quán)，附加值會很高。又如當前的EVB（Edge Virtual Bridging）和BPE（Bridging Port Extend）技術(shù)結(jié)構(gòu)之爭也同樣是話語權(quán)之爭。

順便一提，當一項完全不能向前兼容的全新技術(shù)出現(xiàn)時，除非是有相當于一個國家的力量去推動普及，而且原理簡單到8-80歲都一聽就明白，否則注定會夭折，與技術(shù)本身優(yōu)劣無太大關(guān)系。老話說得好，一口吃不成胖子。

?

3.5?數(shù)據(jù)中心多站點

這是個有錢人的話題，且符合2-8原則，能夠建得起多個數(shù)據(jù)中心站點的在所有數(shù)據(jù)中心項目中數(shù)量也許只能占到20%，但他們占的市場份額肯定能達到80%。

建多個數(shù)據(jù)中心站點主要有兩個目的，一是擴容，二是災備。

擴容

首先說擴容，一個數(shù)據(jù)中心的服務(wù)器容量不是無限的，建設(shè)數(shù)據(jù)中心時需要考慮的主要因素是空間、電力、制冷和互聯(lián)。數(shù)據(jù)中心購買設(shè)備場地建設(shè)只是占總體耗費的一部分，使用過程中的耗能維護開銷同樣巨大，以前就鬧過建得起用不起的笑話。當然現(xiàn)在建設(shè)時要規(guī)范得多，考慮也會更多，往往做預算時都要考慮到10年甚至以上的應(yīng)用損耗。

再講個故事，以前曾有某大型ISP打算找個雪山峽谷啥的建數(shù)據(jù)中心，荒郊野外空間本來就大，融雪制冷，水力發(fā)電，聽上去一切都很美，但是就忘了一件事，互聯(lián)。光纖從哪里拉過去，那么遠的距離中間怎么維護，至少從目前階段來說這個問題無解。也許等到高速通信發(fā)展到可以使用類似銥星的無線技術(shù)搞定時，數(shù)據(jù)中心就真的都會建到渺無人煙的地方吧，現(xiàn)在還只能在城市周邊徘徊。貌似聽說過國外有建得比較偏遠的大型數(shù)據(jù)中心，但個人覺得應(yīng)該還是人家通信行業(yè)發(fā)達，光纖資源豐富，四處都能接入。但至少目前國內(nèi)的運營商們不見得會支持，大城市周邊搞搞就算了，遠了沒人會陪你玩。

有些扯遠，回到正題。現(xiàn)在國內(nèi)已經(jīng)有超過10k臺物理服務(wù)器在一個數(shù)據(jù)中心站點的項目了，再多我還沒有聽說過。只有幾百上千的物理服務(wù)器就敢喊搞云計算是需要一定勇氣的，既然是云，規(guī)模就應(yīng)永無止境。所以建多個數(shù)據(jù)中心站點來擴容就成了必然之舉。這時就可能遇到Cluster集群計算任務(wù)被分配在多個站點的物理服務(wù)器或虛擬機來完成的情況，從而提出了跨多個數(shù)據(jù)中心站點的Ethernet大二層互聯(lián)需求。

在擴容時，就可以充分利用vMotion等虛擬機遷移技術(shù)來進行新數(shù)據(jù)中心站點的建設(shè)部署，同樣需要站點間的大二層互通。支持IP層的vMotion目前雖然已經(jīng)出現(xiàn)，但由于技術(shù)不夠成熟，限制很多，實用性不強，還是以Ethernet二層遷移技術(shù)為主。

災備

再說說災備，最近幾年天災人禍著實不少，數(shù)據(jù)中心容災就越來越受到重視。擴容和災備的主要區(qū)別就是：擴容的多個站點針對同一應(yīng)用都要提供服務(wù)；而災備則只有主站點提供服務(wù)，備份站點當主站點掛掉的時候才對外服務(wù)，平時都處于不運行或者空運行的狀態(tài)。

參考國標《信息系統(tǒng)災難恢復規(guī)范》GB/T 20988－2007，災備級別大致可劃分為數(shù)據(jù)級別（存儲備份），應(yīng)用級別（服務(wù)器備份），網(wǎng)絡(luò)級別（網(wǎng)絡(luò)備份），和最高的業(yè)務(wù)級別（包括電話、人員等所有與業(yè)務(wù)相關(guān)資源）。

國內(nèi)外統(tǒng)一的容災衡量標準是RPO（Recovery Point Objective）、RTO（Recovery Time Objective）和RAO（Recovery Access Objective）了，通過下圖形象一些來體現(xiàn)他們的關(guān)系。

簡單來說RPO衡量存儲數(shù)據(jù)恢復，RTO衡量服務(wù)器應(yīng)用恢復，RAO衡量網(wǎng)絡(luò)訪問恢復。一般來說RPO設(shè)計都應(yīng)小于RTO。國外按照RTO/RPO的時間長短對災難恢復分級參考由高到低為：

Class 1/A???? RTO=0-4 hrs; RPO=0-4 hrs

Class 2/B???? RTO=8-24 hrs; RPO=4 hrs

Class 3/C???? RTO=3 day; RPO=1 day

Class 4/D???? RTO=5+ days; RPO=1 day

標準歸標準，真正建設(shè)時候最重要的參考條件還是應(yīng)用的需求，像銀行可以直接去調(diào)研儲戶能容忍多長時間取不出來錢，騰訊去問問QQ用戶能容忍多長時間上不了線，就都知道該怎么設(shè)計容災恢復時間了。

真正在玩多中心災備的行業(yè)，國內(nèi)集中在金融系統(tǒng)（尤其是銀行），政府和能源電力等公字頭產(chǎn)業(yè)，國外的不太清楚，但我想以盈利為主要目的企業(yè)不會有太強烈意愿去建設(shè)這種純備份的低效益站點，更多的是在不同站點內(nèi)建設(shè)一些應(yīng)用服務(wù)級別的備份，所有站點都會對外提供服務(wù)。

小結(jié)

在云計算規(guī)模的數(shù)據(jù)中心中，對于LB類型的多虛一集群技術(shù)，執(zhí)行者（概念參見文檔前面集中云部分）少上幾個不會影響全局任務(wù)處理的，只要在擴容時做到數(shù)據(jù)中心間大二層互通，所有站點內(nèi)都有計算任務(wù)的執(zhí)行者，并且配合HA技術(shù)將協(xié)調(diào)者在不同站點做幾個備份，就已經(jīng)達到了應(yīng)用容災的效果。針對一虛多的VM備份，VMware/XEN等都提出了虛擬機集群HA技術(shù)，此時同樣需要在主中心站點與備份中心站點的服務(wù)器間提供二層通道以完成HA監(jiān)控管理流量互通，可以達到基于應(yīng)用層面的備份。

云計算數(shù)據(jù)中心多站點主要涉及的還是擴容，會部署部分針對VM做HA的后備服務(wù)器，但是不會搞純?yōu)膫湔军c。針對多站點間網(wǎng)絡(luò)互聯(lián)的主要需求就是能夠做而二層互聯(lián)，當站點數(shù)量超過兩個時所有站點需要二層可達，并部署相關(guān)技術(shù)提供冗余避免環(huán)路。

3.6?多站點選擇

數(shù)據(jù)中心建設(shè)多站點后，由于同一應(yīng)用服務(wù)可以跑在多個站點內(nèi)部，對Client來說就面臨著選擇的問題。

首先要記住的是一個Client去往一個應(yīng)用服務(wù)的流量必須被指向一臺物理或虛擬的 Server。你可以想象一個TCP請求的SYN到ServerA，而ACK到了ServerB時，ServerA和B為了同步會話信息都會瘋掉。想辦法維持一對Client-Server通信時的持續(xù)專一是必須的。

Client到Server的訪問過程一般分為如下兩步：

1、?Client訪問域名服務(wù)器得到Server IP地址（很少人會去背IP地址，都是靠域名查找）

2、?Client訪問Server IP，建立會話，傳遞數(shù)據(jù)。

當前的站點選擇技術(shù)也可以對應(yīng)上面兩個步驟分為兩大類。

第一類是在域名解析時做文章，原理簡單來說就是域名服務(wù)器去探測多個站點內(nèi)IP地址不同的服務(wù)器狀態(tài)，再根據(jù)探測結(jié)果將同一域名對應(yīng)不同IP返回給不同的Client。這樣一是可以在多個Client訪問同一應(yīng)用時，對不同站點的服務(wù)器進行負載均擔，二是可以當域名服務(wù)器探測到主站點服務(wù)器故障時，解析其他站點的服務(wù)器IP地址給Client達到故障冗余目的。這時要求不同站點的服務(wù)地址必須在不同的三層網(wǎng)段，否則核心網(wǎng)沒法提供路由。缺點很明顯，對域名解析服務(wù)器的計算壓力太大，需要經(jīng)常去跟蹤所有服務(wù)器狀態(tài)并Hash分配Client請求的地址。此類解決方案的代表是F5/Radware/Cisco等廠商的3DNS/GSLB/GSS等技術(shù)。

第二類就是把多個站點的服務(wù)IP地址配置成一樣，而各個站點向外發(fā)布路由時聚合成不同位數(shù)的掩碼（如主中心發(fā)布/25位路由，備中心發(fā)布/24位路由），或通過相同路由部署不同路由協(xié)議Cost值以達到主備路由目的。使用掩碼的問題是太細則核心網(wǎng)轉(zhuǎn)發(fā)設(shè)備上的路由數(shù)量壓力大，太粗則地址使用不好規(guī)劃很浪費。使用Cost則需要全網(wǎng)IP路由協(xié)議統(tǒng)一，節(jié)點規(guī)模受到很大限制。另外這種方式只能將所有Client訪問同一服務(wù)IP的流量指向同一個站點，負載分擔只能針對不同的服務(wù)。好處則是這種站點選擇技術(shù)誰都能用，不需要專門設(shè)備支持，部署成本低成為其存活的根據(jù)。

在云計算大二層數(shù)據(jù)中心部署下，各個站點提供同一服務(wù)的Server都處于一個二層網(wǎng)絡(luò)內(nèi)，且不能地址沖突，與前面描述的兩種站點選擇技術(shù)對服務(wù)器IP設(shè)置要求都不匹配，因此需要配合SLB設(shè)備一起使用?？梢岳斫馄錇橐环N基于IP粒度的多虛一技術(shù)，使用專門LB硬件設(shè)備作為協(xié)調(diào)者，基于IP地址來分配任務(wù)給服務(wù)組中不同的Server執(zhí)行成員。LB設(shè)備通常將多個Server對應(yīng)到一個NAT組中，外部訪問到一個NAT Server虛擬IP地址，由LB設(shè)備按照一定算法分擔給各個成員。LB設(shè)備同時會探測維護所有Server成員狀態(tài)。當各個站點內(nèi)LB設(shè)備將同一服務(wù)對外映射為不同的虛擬IP地址時，可以配合域名解析方式提供Client選路；而配置為相同時則可以配合路由發(fā)布方式使用。

現(xiàn)有的站點選擇技術(shù)都不盡如人意，即使是下文介紹的Cisco新技術(shù)LISP也只是部分的解決了路由發(fā)布技術(shù)中，發(fā)布服務(wù)器地址掩碼粒度過細時，給核心網(wǎng)帶來較大壓力的問題，目前還不算是一套完整的站點選擇解決方案。個人感覺，最好的路還是得想法改造DNS的處理流程，目前的DNS機制并不完備，在攻擊面前脆弱不堪，后面的安全附加章節(jié)中會對此再深入討論。

3.7?數(shù)據(jù)中心小結(jié)

又到了小結(jié)部分，云計算數(shù)據(jù)中心相比較傳統(tǒng)數(shù)據(jù)中心對網(wǎng)絡(luò)的要求有以下變化：

1、?Server-Server流量成為主流，而且要求二層流量為主。

2、?站點內(nèi)部物理服務(wù)器和虛擬機數(shù)量增大，導致二層拓撲變大。

3、?擴容、災備和VM遷移要求數(shù)據(jù)中心多站點間大二層互通。

4、?數(shù)據(jù)中心多站點的選路問題受大二層互通影響更加復雜。

題內(nèi)話，F(xiàn)CoE并不是云計算的需求，而是數(shù)據(jù)中心以網(wǎng)絡(luò)為核心演進的需求，至于云計算里面是不是一定要實現(xiàn)以網(wǎng)絡(luò)為核心，就看你是站在哪個設(shè)備商的角度來看了。

4?、網(wǎng)絡(luò)

說到網(wǎng)絡(luò)，這里關(guān)注的重點是前文提到的數(shù)據(jù)中心內(nèi)部服務(wù)器前后端網(wǎng)絡(luò)，對于廣泛意義上的數(shù)據(jù)中心，如園區(qū)網(wǎng)、廣域網(wǎng)和接入網(wǎng)等內(nèi)容，不做過多擴散。

4.1?路由與交換

網(wǎng)絡(luò)世界永遠的主題，至少目前看來還沒有出現(xiàn)能取代這二者技術(shù)的影子，擴展開足夠?qū)懞脦妆緯牧恕?

數(shù)據(jù)中心的網(wǎng)絡(luò)以交換以太網(wǎng)為主，只有傳統(tǒng)意義的匯聚層往上才是IP的天下。參考前文的需求可以看出，數(shù)據(jù)中心的以太網(wǎng)絡(luò)會逐步擴大，IP轉(zhuǎn)發(fā)的層次也會被越推越高。

數(shù)據(jù)中心網(wǎng)絡(luò)從設(shè)計伊始，主要著眼點就是轉(zhuǎn)發(fā)性能，因此基于CPU/NP轉(zhuǎn)發(fā)的路由器自然會被基于ASIC轉(zhuǎn)發(fā)的三層交換機所淘汰。傳統(tǒng)的Ethernet交換技術(shù)中，只有MAC一張表要維護，地址學習靠廣播，沒有什么太復雜的網(wǎng)絡(luò)變化需要關(guān)注，所以速率可以很快。而在IP路由轉(zhuǎn)發(fā)時，路由表、FIB表、ARP表一個都不能少，效率自然也低了很多。

云計算數(shù)據(jù)中心對轉(zhuǎn)發(fā)帶寬的需求更是永無止境，因此會以部署核心-接入二層網(wǎng)絡(luò)結(jié)構(gòu)為主。層次越多，故障點越多、延遲越高、轉(zhuǎn)發(fā)瓶頸也會越多。目前在一些ISP（Internet Service Provider）的二層結(jié)構(gòu)大型數(shù)據(jù)中心里，由于傳統(tǒng)的STP需要阻塞鏈路浪費帶寬，而新的二層多路徑L2MP技術(shù)還不夠成熟，因此會采用全三層IP轉(zhuǎn)發(fā)來暫時作為過渡技術(shù)，如前面提到過的接入層與核心層之間跑OSPF動態(tài)路由協(xié)議的方式。這樣做的缺點顯而易見，組網(wǎng)復雜，路由計算繁多，以后勢必會被Ethernet L2MP技術(shù)所取代。

新的二層多路徑技術(shù)會在下文做更詳細的介紹，不管是TRILL還是SPB都引入了二層ISIS控制平面協(xié)議來作為轉(zhuǎn)發(fā)路徑計算依據(jù)，這樣雖然可以避免當前以太網(wǎng)單路徑轉(zhuǎn)發(fā)和廣播環(huán)路的問題，但畢竟是增加了控制平面拓撲選路計算的工作，能否使其依然如以往Ethernet般高效還有待觀察。MPLS就是一個尷尬的前車之鑒，本想著幫IP提高轉(zhuǎn)發(fā)效率而生根發(fā)芽，沒想到卻在VPN路由隔離方面開花結(jié)果了，世事難料啊。

4.2?EOR與TOR

前面說了，數(shù)據(jù)中心網(wǎng)絡(luò)設(shè)備就是交換機，而交換機就分為框式與盒式兩種。當前云計算以大量X86架構(gòu)服務(wù)器替代小型機和大型機，導致單獨機架Rack上的服務(wù)器數(shù)量增多。受工程布線的困擾，在大型數(shù)據(jù)中心內(nèi)EOR（End Of Row）結(jié)構(gòu)已經(jīng)逐步被TOR（Top Of Rack）結(jié)構(gòu)所取代。盒式交換機作為數(shù)據(jù)中心服務(wù)器第一接入設(shè)備的地位變得愈發(fā)不可動搖。而為了確保大量盒式設(shè)備的接入，匯聚和核心層次的設(shè)備首要解決的問題就是高密度接口數(shù)量，由此框式交換機也就占據(jù)了數(shù)據(jù)中心轉(zhuǎn)發(fā)核心的位置。

4.3?控制平面與轉(zhuǎn)發(fā)平面

對交換機來說，數(shù)據(jù)報文轉(zhuǎn)發(fā)都是通過ASIC（Application Specific Integrated Circuit）芯片完成，而協(xié)議報文會上送到CPU處理，因此可以將其分為控制平面與轉(zhuǎn)發(fā)平面兩大部分。

控制平面主體是CPU，處理目的MAC/IP為設(shè)備自身地址和設(shè)備自身發(fā)給其他節(jié)點的報文，同時下發(fā)表項給轉(zhuǎn)發(fā)ASIC芯片，安排數(shù)據(jù)報文的轉(zhuǎn)發(fā)路徑?？刂破矫嬖谌龑咏粨Q機中尤為重要，需要依靠其學習路由轉(zhuǎn)發(fā)表項并下發(fā)到ASIC芯片進行基于IP的轉(zhuǎn)發(fā)處理。而二層交換機中數(shù)據(jù)報文的轉(zhuǎn)發(fā)路徑都是靠MAC地址廣播來直接學習，和控制平面CPU關(guān)系不大。

轉(zhuǎn)發(fā)平面則是以ASIC芯片為核心，對過路報文進行查表轉(zhuǎn)發(fā)處理，對交換機來說， ASIC轉(zhuǎn)發(fā)芯片是其核心，一款交換機的能力多少和性能大小完全視其轉(zhuǎn)發(fā)芯片而定。而控制平面CPU雖然也是不可或缺的部分，但不是本文介紹的重點，下文將以分析各類型交換機的轉(zhuǎn)發(fā)處理為主。

4.4?Box與集中式轉(zhuǎn)發(fā)

經(jīng)?？吹皆O(shè)備商們今天推出個“高性能”，明天推出個“無阻塞”，后天又搞“新一代”的網(wǎng)絡(luò)交換產(chǎn)品，各種概念層出不窮，你方唱罷我登臺，搞得大家跟著學都學不過來，總有一種是不是被忽悠了的感覺。其實很多時候真的是在被忽悠。

先說說Box盒式設(shè)備。盒式交換機從產(chǎn)生到現(xiàn)在，以轉(zhuǎn)發(fā)芯片為核心的集中式轉(zhuǎn)發(fā)結(jié)構(gòu)就沒有過大的變化。集中式轉(zhuǎn)發(fā)盒子的所有接口間流量都是走轉(zhuǎn)發(fā)芯片來傳輸，轉(zhuǎn)發(fā)芯片就是盒子的心臟。

而這個心臟的叫法多種多樣，神馬Port ASIC、Switch Chip、Fabric ASIC、Unified Port Controller等等都是各個廠家自行其說罷了，關(guān)鍵就看各個物理接口的PHY（將0/1信號與數(shù)據(jù)互相轉(zhuǎn)換用的器件）連接到哪里，哪里就是核心轉(zhuǎn)發(fā)芯片。一般的中小型交換機設(shè)備廠商（H3C/中興/銳捷/ Foundry/Force10等，Juniper目前的數(shù)據(jù)中心Switch不提也罷，下文會簡單說說未來的QFabric）都會直接采購Broadcom和Marvell等芯片生產(chǎn)廠商的產(chǎn)品，只有Cisco和Alcatel等寥寥幾家大廠商有能力自己生產(chǎn)轉(zhuǎn)發(fā)芯片。但說實話，從轉(zhuǎn)發(fā)能力來看這些自產(chǎn)的還真不見得能趕上公用的，人家專業(yè)啊。自產(chǎn)的最大好處其實在于方便搞些私有協(xié)議封包解包啥的，我的芯片我做主。

下面來說說集中式轉(zhuǎn)發(fā)能力的計算，假設(shè)一個盒子喊自己的轉(zhuǎn)發(fā)能力是x Gbps/y Mpps，x是依靠所有外部接口帶寬總和算出來的，如48GE+2*10GE的盒子，轉(zhuǎn)發(fā)能力就是單向68GE，雙向136GE，一般x都會取雙向的值；而y則是整機的包轉(zhuǎn)發(fā)能力，y=x*1000/2/8/(64+20)，1000是G到M的轉(zhuǎn)換，2是雙向，8是每字節(jié)8比特，64是報文最小載荷，20是IP頭長。要注意下面的機框式轉(zhuǎn)發(fā)就不是這么算的了。大部分盒子的包轉(zhuǎn)發(fā)能力還是能夠很接近這個理論值的，畢竟能選的轉(zhuǎn)發(fā)芯片就那么多，設(shè)備廠商在這里自己搞不出太多貓膩來。唯一有可能用來混淆客戶的就是用芯片轉(zhuǎn)發(fā)能力替代設(shè)備接口轉(zhuǎn)發(fā)能力作為x值來宣傳，絕大部分交換機使用的芯片轉(zhuǎn)發(fā)能力是大于所有接口帶寬總和的。這時x與y都會比實際的要大一些，但是很明顯，芯片再強，沒有接口引出來也沒用的。所以這里的防忽悠技巧就是數(shù)接口數(shù)自己加一下。

再說結(jié)構(gòu)，決定一款盒式交換機的接口轉(zhuǎn)發(fā)容量的是轉(zhuǎn)發(fā)芯片，反之你看一款盒子的接口排布情況大概能反推出其使用的芯片能力。轉(zhuǎn)發(fā)芯片的接口多種多樣（如SGMII、XAUI、HIG、Senders等），但通常每個芯片只連接24個GE接口（8個口一個PHY，3個PHY為一組），因此遇到24GE口交換機，通常都是單芯片的，而48GE或更多就肯定是多芯片的了。而10GE接口的多少要看芯片的能力，個人了解Broadcom有支持24個10GE的轉(zhuǎn)發(fā)新片，應(yīng)該還有能力更強的?，F(xiàn)在作者知道的10GE接口密度最高的盒子是Arista的7148SX和Juniper的QFX3500，都支持48個10GE接口，具體布局有待拆機檢查。

多芯片交換機還是很考驗設(shè)備廠商架構(gòu)設(shè)計人員的，既要保證芯片間足夠帶寬互聯(lián)無阻塞，又要考慮出接口不能浪費，需拿捏好平衡。所以現(xiàn)在的多芯片盒式交換機設(shè)備大多是2-3個轉(zhuǎn)發(fā)芯片的，再多的就極少了，芯片間互聯(lián)設(shè)計起來太麻煩了。舉兩個例子，大家可以看看下面這兩種結(jié)構(gòu)有沒有問題。

首先是我們能不能用兩塊6個HIG接口級別轉(zhuǎn)發(fā)能力的ASIC（HIG接口帶寬12.5GE），設(shè)計一款48GE+4*10GE的交換機呢？答案是可以做，但存在結(jié)構(gòu)性擁塞，芯片間至少需要4條HIG才能滿足完全無阻塞。

再來看一個，能不能用3塊4個HIG接口級別轉(zhuǎn)發(fā)能力的ASIC搭建出一款48GE+2*10GE的交換機呢？沒有問題，如下圖所示內(nèi)部結(jié)構(gòu)是完全無阻塞的，缺點是部分流量會多繞經(jīng)1個ASIC轉(zhuǎn)發(fā)。

看完了前面這部分，相信大家對盒式交換機都能有個大致了解了，這里只講講結(jié)構(gòu)，更詳細的轉(zhuǎn)發(fā)功能流程就需要有興趣的童鞋自行去查看下各種芯片手冊。另外上述兩個例子只為講解，請勿將當前市場產(chǎn)品對號入座。

剛剛說了，當盒子里面芯片較多的時候連接起來很麻煩，于是出現(xiàn)了新的轉(zhuǎn)發(fā)單元Switch Fabric（Cisco N5000上新的名詞叫做Unified Crossbar Fabric）。其實這個東東在框式交換機里面很常見，下面會有更詳細的介紹。而在盒式交換機里面，目前看到的發(fā)布資料使用此種架構(gòu)的就是Cisco的3750X和N5000了，連接方式如下圖所示，這已經(jīng)接近分布式轉(zhuǎn)發(fā)的范圍了。

作者將這個Fabric單元叫做交換芯片，便于和前面的ASIC轉(zhuǎn)發(fā)芯片區(qū)分，二者的主要區(qū)別是，交換芯片只處理報文在設(shè)備內(nèi)部的轉(zhuǎn)發(fā)，類似Cut-Through，為不同轉(zhuǎn)發(fā)芯片間搭建路徑，不做過濾和修改。而轉(zhuǎn)發(fā)芯片要對報文進行各種查表、過濾和修改等動作，包括緩存都在其中調(diào)用，大多是基于Store-Forward方式進行報文處理，是交換機處理數(shù)據(jù)報文的核心部件。

3750X目前還沒有看到進一步的發(fā)展需要，而N5000其實是為了Cisco的網(wǎng)絡(luò)虛擬化架構(gòu)而服務(wù)，不再單單屬于傳統(tǒng)意義上的Ethernet交換機了。Juniper為QFabric設(shè)計的QFX3500接入盒子（48*10GE+4*40GE）估計也是類似于N5000這種帶交換芯片的分布式架構(gòu)。另外懷疑Arista的7148SX也是分布式架構(gòu)的，應(yīng)該是6個8*10G的轉(zhuǎn)發(fā)芯片通過交換芯片連接，和它的機框式交換機中48*10G接口板布局相同。

總的來說盒子里面搞分布式的最主要原因就是希望提高接口密度，尤其是萬兆接口密度，后面相信還會有其他廠商陸續(xù)跟進，但是其接口數(shù)量需求是與部署位置息息相關(guān)的，盲目的擴充接口數(shù)并不一定符合數(shù)據(jù)中心的需要。

再嘮叨幾句數(shù)據(jù)中心Box交換機的選型，前面說了Top Of Rack是Box的主要歸宿，一個標準Rack目前最高的42U，考慮冗余怎么也得搞2臺Box，剩下最多裝40臺1U的Server，那么上48GE+4*10GE的Box就是最適合的。依此類推，接口數(shù)量多的box不見得真有太大作用，位置會很尷尬。考慮選擇Box的最大轉(zhuǎn)發(fā)容量時，直接根據(jù)服務(wù)器接口數(shù)來計算接口即可。目前隨著FCoE的推進，服務(wù)器提供10GE CNA接口上行到接入交換機越來越常見，那么對Box的要求也隨之提升到10GE接入40G/100G上行的趨勢，像Juniper的QFX3500（48*10GE+4*40GE）明顯就是上下行帶寬1：3收斂的交換機，估計下一代Top Of Rack的數(shù)據(jù)中心交換機怎么也得要40*10GE+4*100GE的接口才能徹底搞定42U機架，如果全部署2U的服務(wù)器，則最少也需要16*10GE+4*40GE接口的Box才靠譜一些。

4.5?Chassis與分布式轉(zhuǎn)發(fā)

本章節(jié)涉及轉(zhuǎn)發(fā)能力的舉例計算量較大，對數(shù)字不感興趣的同學可以直接略過相關(guān)內(nèi)容。

盒子說完了講講框，盒式設(shè)備發(fā)展到一定程度，接口密度就成了天花板，必須要搞成機框式才能繼續(xù)擴展了。可以把機框里面的板卡理解為一個個獨立的盒子，然后通過交換網(wǎng)絡(luò)將其連接起來形成整體。

羅馬不是一天建成的，機框式交換機最初也是按照集中式轉(zhuǎn)發(fā)架構(gòu)來進行設(shè)計。例如Cisco4500系列（又是Cisco，沒辦法，就他家產(chǎn)品最全，開放出來的資料最多，而且確實是數(shù)通領(lǐng)域的無冕之王，下文很多技術(shù)也都跟其相關(guān)），其接口板（LineCard）上面都沒有轉(zhuǎn)發(fā)芯片的（XGStub ASIC只做接口緩存和報文排隊的動作），所有的數(shù)據(jù)報文都需要通過背板通道（Fabric），上送到主控板（Supervisor）的轉(zhuǎn)發(fā)芯片（Forwarding Engine）上進行處理。結(jié)構(gòu)如下圖所示，其中PP（Packet Processor）是做封包解包的，F(xiàn)E（Forwarding Engine）是做查表處理的。

在早期Cisco6500系列交換機設(shè)備上同樣是基于總線（BUS）的集中式轉(zhuǎn)發(fā)結(jié)構(gòu)。如Classic類型接口板（Module）就只有Port ASIC做緩存和排隊，所有的報文同樣要走到主控板（Supervisor32或720）上的轉(zhuǎn)發(fā)芯片（PFC3）來處理。普通的CEF256和CEF720系列接口板雖然以Switch Fabric替代BUS總線通道來處理接口板到主控板的流量轉(zhuǎn)發(fā)，但仍然是靠主控板上的PFC3對流量進行集中處理，因此還是集中式轉(zhuǎn)發(fā)。直到CEF256和CEF720的DFC（Distributed Forwarding Card）扣板出來，才能在板卡上進行轉(zhuǎn)發(fā)，稱得上是真正的分布式架構(gòu)。而最新的第四代接口板dCEF720 Linecards已經(jīng)直接將DFC變成了一個非可選組件直接集成在接口板上。

分布式架構(gòu)指所有的接口板都有自己的轉(zhuǎn)發(fā)芯片，并能獨立完成查表轉(zhuǎn)發(fā)和對報文的L2/L3等處理動作，接口板間通過交換芯片進行報文傳遞，機框的主控板只通過CPU提供協(xié)議計算等整機控制平面功能。分布式架構(gòu)接口板上都會專門增加一個Fabric連接芯片（Fabric Interface或Fabric Adapter Process等），用以處理報文在框內(nèi)接口板間轉(zhuǎn)發(fā)時的內(nèi)部報頭封裝解封裝動作。當報文從入接口板向交換芯片轉(zhuǎn)發(fā)時，連接芯片為報文封裝一個內(nèi)部交換報頭，主要內(nèi)容字段就是目的出接口板的Slot ID和出接口Port ID，交換芯片收到報文后根據(jù)Slot ID查找接口轉(zhuǎn)發(fā)，出接口板的連接芯片收到后根據(jù)Slot ID確認，并將此內(nèi)部交換報頭去掉，根據(jù)Port ID將報文從對應(yīng)出接口轉(zhuǎn)出交換機。很顯然分布式對比集中式的區(qū)別主要是芯片更多，成本更高，轉(zhuǎn)發(fā)能力也更高。目前各廠商最新一代的主流數(shù)據(jù)中心交換機都已經(jīng)是完全的分布式轉(zhuǎn)發(fā)架構(gòu)（如Cisco的N7000，H3C的12500等）。

下面說下Chassis的轉(zhuǎn)發(fā)能力，這個可比盒子要復雜多了，各個廠家多如繁星的機框、主控和接口板種類足以使用戶眼花繚亂。還是以Cisco6500系列交換機舉例，一法通萬法通，搞明白這個其他的也不過爾爾了。選擇Cisco6500還有一個主要原因就是其結(jié)構(gòu)從集中式跨越到分布式，從BUS總線通道跨越到Crossbar轉(zhuǎn)發(fā)，堪稱傳統(tǒng)機框交換機百科全書。

FIRE（Fabric Interface & Replication Engine）為Cisco的接口板連接芯片，除了作為連接Switch Fabric的接口對報文進行內(nèi)部報頭的封包解包動作外，還能提供本地鏡像和組播復制功能。圖中舉例了報文在65機框式交換機中跨接口板轉(zhuǎn)發(fā)的主要節(jié)點。集中式轉(zhuǎn)發(fā)時板內(nèi)接口間流量轉(zhuǎn)發(fā)同樣適用此圖，而分布式轉(zhuǎn)發(fā)時板內(nèi)轉(zhuǎn)發(fā)流量不需要走到Switch Fabric。

另外報文走到出方向接口板時是否經(jīng)過轉(zhuǎn)發(fā)芯片處理各個廠家的設(shè)備實現(xiàn)并不一致，最簡單的一個方法就是看交換機接口板支持不支持出方向的報文ACL（Access Control List）過濾，就知道其有沒有上出口板轉(zhuǎn)發(fā)芯片處理了。

從上圖可以看出接口板的轉(zhuǎn)發(fā)能力都受限于板卡連接BUS或Switch Fabric的接口帶寬，而衡量整機轉(zhuǎn)發(fā)能力時，集中式轉(zhuǎn)發(fā)受限于轉(zhuǎn)發(fā)芯片F(xiàn)E的轉(zhuǎn)發(fā)能力，分布式轉(zhuǎn)發(fā)受限于交換芯片Switch Fabric的轉(zhuǎn)發(fā)能力。先說接口板轉(zhuǎn)發(fā)能力，大家以前可能經(jīng)常會聽到接口板存在非線速和收斂比的概念，看到這里就很好明白了，例如CEF256類型接口板的Switch Fabric接口帶寬是8G，那最多就支持8個GE口和其他接口板進行流量轉(zhuǎn)發(fā)，其WS-X6516-GBIC接口板的面板上有16個GE口，明顯就是一塊2：1的收斂比的非線速板。

再如CEF720類型接口板的Switch Fabric接口是2*20G（單板上有兩個FIRE），那48GE口的單板也明顯不可能是線速的了。即使是號稱第四代的dCEF720接口板，其Switch Fabric接口和CEF720一樣都是2*20G接口，那么X6708-10G接口板（提供8*10GE接口）和X6716-10G接口板（提供16*10GE接口）只能是2：1和4：1收斂的非線速板了。

背板通道預留不足，Switch Fabric交換能力不夠，6500系列的這些架構(gòu)缺陷促使Cisco狠下心來為數(shù)據(jù)中心重新搞出一套Nexus7000，而其他交換機廠商也都幾乎同時期推出了新架構(gòu)的機框式交換機，都是被逼的啊，誰讓1000M接入這么快就替代了100M接入呢，核心更得開始拼萬兆了。

再說說整機轉(zhuǎn)發(fā)能力。在集中式轉(zhuǎn)發(fā)時，Cisco6500不論使用Supervisor32還是Supervisor720主控，F(xiàn)E轉(zhuǎn)發(fā)芯片都是走BUS的，帶寬都是16G（雙向32G），因此只要用的接口板沒有DFC，整機最大也就雙向32G了。而其中Supervisor32不支持Switch Fabric，也就支持不了DFC的分布式轉(zhuǎn)發(fā)，名稱里的32就代表了其雙向32G的最大整機轉(zhuǎn)發(fā)能力。

Supervisor720主控支持18*20的Switch Fabric交換，名稱中的720是指整個Switch Fabric的雙向交換能力18*20*2=720G。但其中1個通道用于連接FE轉(zhuǎn)發(fā)芯片，1個通道暫留未用，只有16個通道留給了接口板，意味著整機實際最大能夠支持的雙向轉(zhuǎn)發(fā)能力是16*20*2=640G。Supervisor720-10GE支持20*20的Switch Fabric，多出來的2個10G通道給了Supervisor上的2個10GE接口，實際提供給接口板的交換通道仍然是16*20G。

剛剛說了，目前最新的CEF720系列接口板每塊有2*20G的出口，簡單做個除法，16/2=8，主控板的交換芯片最多能夠承載8塊CEF720接口板，熟悉Cisco6500產(chǎn)品的同學這時候就會想到6513機框怎么辦呢。6513除去7-8的主控槽位外，一共有11個接口板槽位，1-6槽位背板只提供1個Switch Fabric通道，9-13才能提供2個通道，正好是6+2*5=16個通道滿足主控板的Switch Fabric交換能力。而6513E雖在1-6槽位背板提供了2個通道，但實際上1-6槽位也同樣只能支持1個Switch Fabric通道，否則Supervisor720的Switch Fabric也搞不定的。如果想6513E的接口板通道全用起來，只能等Cisco6500出下一代引擎了，至少是Supervisor880才能搞定6513E的全線速轉(zhuǎn)發(fā)，不過從交換芯片的發(fā)展來看，Supervisor960的可能性更大一些，1280就有些拗口了。由上看出即使將CEF720接口板插到6513/6513E的1-6槽，也只能跑20G的流量，這下連24GE接口板都無法線速了。

前面算了好多數(shù)，好在都是加減乘除，只要搞明白了，完全可以避免選型時再被設(shè)備廠商忽悠。題外話，很多廠商的機框千兆接口板（24或48個光/電口）都可以在其同時代盒式交換機中找到相似的影子，假如看到支持相同接口數(shù)量類型的接口板和盒子，相信里面的轉(zhuǎn)發(fā)芯片十之八九也用的一樣。萬兆接口板不做成盒式是因為接口密度太低，價格上不去；而高密萬兆的盒子做不成接口板則是因為框式交換機交換芯片和背板通道結(jié)構(gòu)限制導致跨板轉(zhuǎn)發(fā)能力上不去。

?

框式交換機架構(gòu)從集中式發(fā)展到分布式后，整機的轉(zhuǎn)發(fā)能力迎來了一次跳躍性發(fā)展，從Cisco6500的Supervisor32到Supervisor720就可見一斑。那么下一步路在何方呢，各個廠家都有著不同的看法?？椿氐角懊娣植际睫D(zhuǎn)發(fā)的結(jié)構(gòu)圖，可以想到要繼續(xù)提升轉(zhuǎn)發(fā)能力有兩個主要方向，一個是將單芯片處理能力提升，交換芯片只處理一次查表轉(zhuǎn)發(fā)，工作簡單相對更容易提升，而轉(zhuǎn)發(fā)芯片要干的事情太多就不是那么好換代的了。

而另一條路就是增加芯片的數(shù)量，轉(zhuǎn)發(fā)芯片由于要排布在接口板上，畢竟地方就那么大，發(fā)展有限，現(xiàn)在的工藝來說，一塊單板放4個轉(zhuǎn)發(fā)芯片基本上已經(jīng)到極限了，6個的也只看到Arista的7548接口板上有，再多的還沒有見過，因此轉(zhuǎn)發(fā)芯片的發(fā)展還是要看芯片廠商的能力了。而像Cisco6500的Supervisor720一樣將交換芯片布在主控板上的話，同樣面臨空間的限制，上面還得放些CPU/TCAM什么的，最多每塊主控上面放2個交換芯片就頂天了，雙主控能支撐4個，但是全用做轉(zhuǎn)發(fā)的話就做不到冗余了。最新的思路是將交換芯片拿出來單獨成板，這樣只要新機框設(shè)計得足夠大，交換芯片的數(shù)量就不再是限制。例如Cisco的N7000可以插5塊交換網(wǎng)板，而H3C的12500能夠插9塊交換網(wǎng)板。當然轉(zhuǎn)發(fā)能力并不是交換芯片的數(shù)量越多就越好，還要看具體其單體轉(zhuǎn)發(fā)能力和整機背板通道布局。

以Cisco的N7000舉例分析，其交換網(wǎng)板Fabric Modules上的CFA（Crossbar Fabric ASICs）宣稱是支持每槽位（Slot）2*23G的通道交換，整機最大支持2*23*5=230G的每槽位單向轉(zhuǎn)發(fā)能力。這樣能看出來啥呢？

1、N7010上8個板卡槽位，2個主控槽位（主控槽位支持1條23G通路），一共是8*2+2=18條通道，可以看出7010的交換網(wǎng)板上就一塊Crossbar Fabric ASIC，這個交換芯片和以前Cisco6500 Supervisor720上的18*20交換芯片除了每通道帶寬從20G提升到了23G以外，通路數(shù)都是18條沒有變化，應(yīng)該屬于同一代交換芯片產(chǎn)品。7018可以算出是16*2+2=34條通道，那么其每塊交換網(wǎng)板上應(yīng)該是2個與7010相同的CFA交換芯片，而且還空了2條通道暫時沒用上。

2、其接口板上的數(shù)據(jù)通道同樣應(yīng)該與交換網(wǎng)板通道相匹配，升級到23G的容量?？聪?8GE接口板的圖，上面只有一塊2通道的轉(zhuǎn)發(fā)芯片F(xiàn)orwarding Engine，于是了解為啥其只能提供46G的全線速轉(zhuǎn)發(fā)，而且使用一塊交換網(wǎng)板就可以達到最大轉(zhuǎn)發(fā)能力了。

3、再看其10GE接口板，8口萬兆板上面有兩塊2通道的轉(zhuǎn)發(fā)芯片，這樣80G流量完全夠處理，那么算算需要2塊交換網(wǎng)板才能線速跨板轉(zhuǎn)發(fā)，1塊就只能轉(zhuǎn)40G了。而32口萬兆板上面就一塊4通道的轉(zhuǎn)發(fā)芯片，只能搞定80G流量轉(zhuǎn)發(fā)，是收斂比4:1的非線速板，同樣需要兩塊交換網(wǎng)板才能達到最大的跨板轉(zhuǎn)發(fā)能力。

4、由上面3點可以看出，只使用目前Cisco N7000的接口板的話，交換網(wǎng)板2+1冗余就完全足夠用的了。Cisco的下一步換代目標肯定是要想辦法提升接口板轉(zhuǎn)發(fā)芯片的能力了。首先應(yīng)該搞定兩塊4通道轉(zhuǎn)發(fā)芯片F(xiàn)E的工藝布局（VOQ和Replication Engine芯片的數(shù)量都要翻倍），這樣能把16口線速萬兆板先搞出來，然后是否研究20*10GE接口板就看其市場戰(zhàn)略了。再下一步由于目前交換網(wǎng)板支持每接口板230G的總帶寬限制，24/32口萬兆線速板肯定是搞不定的。只能先想法將交換網(wǎng)板升級一下，至少得讓交換能力再翻一翻才好拿出來搞定32/40口萬兆板的線速轉(zhuǎn)發(fā)，至于交換芯片是換代還是數(shù)量翻番就都有可能了。不過無論走哪條路都不是可以一蹴而就的事情，一兩年內(nèi)應(yīng)該沒戲。

再簡單說說H3C的12500，由于其公布資料太少，說多了會有問題。還是從網(wǎng)站公布的宣傳值來看。12508背板7.65T，交換容量3.06T/6.12T，包轉(zhuǎn)發(fā)率960Mpps/2400Mpps；12518背板16.65T，交換容量6.66T/13.32T，包轉(zhuǎn)發(fā)率2160Mpps/5400Mpps。12508與12518都是最大支持9塊交換網(wǎng)板，當前主要接口板與N7000相似，含48GE和4萬兆、8萬兆的線速接口板，32萬兆非線速接口板。

1、從背板算起，首先16.65-7.65=9T就是10個槽位的容量，考慮到廠商的宣傳值都是雙向，那么每接口板槽位應(yīng)該是預留了9000/2/10=450G的最大出口帶寬。根據(jù)12508推算，雙主控每主控板槽位應(yīng)該是預留(7650/2-450*8)/2=112.5G的最大出口帶寬。由此背板預留通道數(shù)接口板與主控板為450:112.5=4:1的關(guān)系。基于省錢原則，主控板上肯定只有一條通道，那么接口板都是4條通道，12508背板槽位一共給接口和主控板留了4*8+2=34條通道。

2、12508交換網(wǎng)板總的交換容量3.06T，則每條通道的帶寬應(yīng)該是3060/34=90G，由此可以推算出實際每塊接口板的出口帶寬為90*4=360G，同樣由于3.06T肯定是個雙向值，則每接口板最大交換即可偶帶寬理論值為180G（比較Cisco N7000的230G理論值要低一些）?！敖粨Q容量3.06T/6.12T”的寫法應(yīng)該指新一代的交換網(wǎng)板芯片能力翻倍或者是數(shù)量翻倍，那時其接口板理論帶寬就可以達到360G了，還是小于前面計算的背板預留450G的最大帶寬，說明背板設(shè)計還是考慮不錯的。

3、再來算算接口板，從8萬兆接口板支持線速轉(zhuǎn)發(fā)看來，首先4個通道應(yīng)該對應(yīng)到4塊轉(zhuǎn)發(fā)芯片，每轉(zhuǎn)發(fā)芯片對應(yīng)2個萬兆接口，處理20G的流量。而32*10G非線速板應(yīng)該是同樣使用4塊轉(zhuǎn)發(fā)芯片，所以也是4:1的收斂比。而其48GE和4*10GE的接口板應(yīng)該是只用了2塊同樣的轉(zhuǎn)發(fā)芯片，轉(zhuǎn)發(fā)芯片的接口應(yīng)該是使用類似于前面盒式交換機中的12.5G帶寬線路類型，每塊轉(zhuǎn)發(fā)芯片對應(yīng)2組12GE接口或2個10GE接口?？紤]其所有接口板采用完全相同轉(zhuǎn)發(fā)芯片是因為大量采購時存在價格優(yōu)勢，不像Cisco自己做芯片。

4、返回來再說下12518，總的通道數(shù)應(yīng)該是18*4+2=74，則總的交換容量應(yīng)該為90*74=6.66T與其宣傳值相同。有個小問題，這里的通道數(shù)計算是按照接口板與主控板來統(tǒng)計的，以交換板的角度來看時，12508每塊交換板一個交換芯片要連8塊接口板，每接口板最大4條通道，既需要8*4=32個出口（主控板通道不見得會連接到交換芯片上，也可能是連接到交換網(wǎng)板的CPU）；而12518每塊交換板肯定是兩個交換芯片，每芯片需要18*4/2=36個出口。這說明12500系列交換機網(wǎng)板上的交換芯片要不就都是32出口的，那么12518有2個槽位只有一半的轉(zhuǎn)發(fā)能力；要不就都是36+出口的，12508存在部分出口空余用不上。

5、最后說下包轉(zhuǎn)發(fā)率的計算，機框式交換機的包轉(zhuǎn)發(fā)率應(yīng)該是所有轉(zhuǎn)發(fā)芯片轉(zhuǎn)發(fā)能力的總和。如每個轉(zhuǎn)發(fā)芯片20G處理帶寬（單向），則轉(zhuǎn)發(fā)率應(yīng)該為20/8/(64+20) =29.76Mpps，取整為30Mpps。按每接口板最大4個轉(zhuǎn)發(fā)芯片計算，則12508整機為30*4*8=960M，12518為30*4*18=2160M，符合其宣傳值。至于其后面的2400M和5400M兩個值，反向推算，每接口板轉(zhuǎn)發(fā)能力為2400/8=5400/18=300Mpps，帶寬則為300*8*(64+20)=201600約200G，難道是預示著其下一代接口板能夠使用2個100G的轉(zhuǎn)發(fā)芯片支持2個100G接口，拭目以待。

前面算了這么多，希望不會導致頭暈吧。

4.6?Clos與VOQ

在Crossbar里面，任何兩個轉(zhuǎn)發(fā)芯片之間的只會經(jīng)過一塊交換芯片，路徑是根據(jù)背板固定死的。這就導致了兩個結(jié)構(gòu)性問題的產(chǎn)生：一是多交換芯片時同一對轉(zhuǎn)發(fā)芯片之間的流量不能被負載分擔，如Cisco N7000就是如此；二是當多塊入方向接口板往一塊出方向接口板打流量的時候，流量可能都走到一塊交換芯片上，導致本來應(yīng)該在出接口板發(fā)生的擁塞，提前發(fā)生到交換芯片上，產(chǎn)生結(jié)構(gòu)性擁塞，影響其他經(jīng)過此芯片轉(zhuǎn)發(fā)的流量。而且交換芯片采用Cut-Through方式轉(zhuǎn)發(fā)是沒有緩存的，報文都會直接丟棄，對突發(fā)流量的處理不理想。

為解決這兩個問題，H3C的12500、Force10的E系列和Foundry BigIron RX等設(shè)備都引入了Clos架構(gòu)的概念（Cisco的CRS系列高端路由器也是Clos結(jié)構(gòu)，但Nexus7000不是）。Clos架構(gòu)是1953年貝爾實驗室研究員Charles Clos設(shè)計的一種多級交換結(jié)構(gòu)，最早應(yīng)用在電話網(wǎng)絡(luò)中。主要是兩個特點，一是可以多級交換，二是每個交換單元都連接到下一級的所有交換單元上。上述廠商設(shè)備中基本都是入接口板-交換網(wǎng)板-出接口板的3級交換結(jié)構(gòu)，而根據(jù)Clos設(shè)計，后續(xù)交換網(wǎng)可以擴展成多層結(jié)構(gòu)。Crossbar與Clos的主要區(qū)別如下圖所示。

全連接的方式滿足了對中間交換芯片的負載均衡需求，同時可以避免單交換芯片的架構(gòu)性阻塞。不過話說回來，目前機框式交換機的轉(zhuǎn)發(fā)能力提升瓶頸還是在轉(zhuǎn)發(fā)芯片上，像前面舉例的N7000和125都是結(jié)構(gòu)轉(zhuǎn)發(fā)能力遠遠大于實際接口板處理能力。所以暫時還不好說Clos就一定是趨勢或代表啥下一代結(jié)構(gòu)，就好像我現(xiàn)在一頓能吃2碗米飯，你給10碗還是20碗對我沒有啥區(qū)別，都得等我胃口先練起來再說，但當我胃口真練起來那天，說不定又改吃饅頭了呢。

多說一句，H3C的12500在交換芯片轉(zhuǎn)發(fā)流量時，報文是在入接口板先被切成等長信元再交給交換芯片的，到出接口板再組合，有些類似ATM轉(zhuǎn)發(fā)，號稱效率更高。而Force10的E系列則是按報文逐包轉(zhuǎn)發(fā)，號稱是為了避免亂序等問題。又是各有道理，管他呢，不出問題就什么都好。

目前新的分布式轉(zhuǎn)發(fā)交換機另一項重要的技術(shù)就是VOQ（Virtual Output Queues）。剛才說的Crossbar第二個擁塞問題在Clos架構(gòu)中，雖然流量不會在Switch Fabric擁塞，但是多打一的情況下仍然會在出接口板擁塞。VOQ就是在入接口板將報文發(fā)給Switch Fabric之前，先用VOQ緩存一下，然后通過中央裁決線路，發(fā)一個問詢給出接口板，看看那邊還有沒有空間接收，有的話就發(fā)，沒有先緩存一會兒，和FC網(wǎng)絡(luò)中實現(xiàn)零丟包的Bufer to Bufer Credit機制很相似（BB Credit機制詳見下文FCoE技術(shù)部分）。這樣就使出接口板的緩存能力擴充到多塊入接口板上，容量翻倍提升，可以有效的緩解突發(fā)擁塞導致的丟包問題。看下圖Cisco N7000的8口萬兆板結(jié)構(gòu)圖可以較好理解VOQ在接口板中的位置。

4.7?網(wǎng)絡(luò)小結(jié)

數(shù)據(jù)中心網(wǎng)絡(luò)看交換，交換機發(fā)展看芯片，分布式轉(zhuǎn)發(fā)是必然，Clos架構(gòu)有得盼。

本章內(nèi)容是下文數(shù)據(jù)中心內(nèi)部服務(wù)器通信網(wǎng)絡(luò)發(fā)展技術(shù)的重要鋪墊。充分了解機框式交換機，可以對后面提出的新一代數(shù)據(jù)中心網(wǎng)絡(luò)虛擬化技術(shù)，（如Cisco的VN-Tag、Fabric Extend和Fabric Path/E-TRILL等）在理解時起到巨大的幫助。

題外話，目前很多企業(yè)規(guī)模大了以后，網(wǎng)絡(luò)部門負責網(wǎng)絡(luò)，業(yè)務(wù)部門負責應(yīng)用和服務(wù)器，很多時候互不搭界，于是設(shè)計網(wǎng)絡(luò)和應(yīng)用的時候就各搞各的，等數(shù)據(jù)中心建起來之后發(fā)現(xiàn)這也是問題那也是問題，各個都變身救火隊員，不是啥好現(xiàn)象。有一本書建議所有的網(wǎng)絡(luò)規(guī)劃設(shè)計人員翻看，《自頂向下的網(wǎng)絡(luò)設(shè)計》，即使找不到或沒時間看也請一定要記住這個書名，終身受益的。對應(yīng)用業(yè)務(wù)設(shè)計人員，也請稍微了解下網(wǎng)絡(luò)，最少也得能估算出業(yè)務(wù)上線后理論上的平均帶寬和峰值帶寬，好向網(wǎng)絡(luò)設(shè)計人員提出需求，免得出事時焦頭爛額互相推諉。

5?、技術(shù)

終于到本文的根本了，前面balabala的說了那么多，都是本章的鋪墊，就是希望大家明白下面這些技術(shù)是為何而來，要解決什么樣的需求和問題。再次對前面的需求進行個匯總。

1、VM之間的互通

2、更多的接口，更多的帶寬

3、二層網(wǎng)絡(luò)規(guī)模擴大

4、數(shù)據(jù)中心站點間二層互聯(lián)

5、VM跨站點遷移與多站點選路

6、服務(wù)器前后端網(wǎng)絡(luò)融合（這個屬于廠家引導還是用戶需求真不好說）

下面就來看看下面這些網(wǎng)絡(luò)技術(shù)是如何解決上述需求問題的。

5.1?技術(shù)結(jié)構(gòu)

前面說了，數(shù)據(jù)中心網(wǎng)絡(luò)流量的根本出發(fā)點是Server，結(jié)合云計算最適合的核心-接入二層網(wǎng)絡(luò)結(jié)構(gòu)，可以把下面要介紹的各種技術(shù)分類如下圖所示。此處只做結(jié)構(gòu)上的介紹，具體技術(shù)細節(jié)將在下文展開。

Network1-VM本地互訪網(wǎng)絡(luò)，邊界是Access Switch，包括物理服務(wù)器本機VM互訪和跨Access Switch的不同物理服務(wù)器VM互訪兩個層面。原有技術(shù)以服務(wù)器內(nèi)部安裝軟件虛擬交換機VSwitch為主，新技術(shù)則分為以服務(wù)器為主體的802.1Qbg EVB（VEPA/Multi-channel）和Cisco以網(wǎng)絡(luò)交換機為主體的802.1Qbh BPE（Port Extend/VN-Tag/VN-Link）兩大IEEE標準體系。

Network2-Ethernet與FC融合，就是FCoE，邊界仍然是Access Switch。在服務(wù)器物理網(wǎng)卡到Access Switch這段，將FC數(shù)據(jù)承載在Ethernet的某個VLAN中傳輸。但實際上各個廠商當前實現(xiàn)都是做NPV交換機，并不是真正的FCoE，只有很少的產(chǎn)品如Cisco的Nexus5000系列和Brocade的8000系列等能夠支持做FCF。

Network3-跨核心層服務(wù)器互訪網(wǎng)絡(luò)，邊界是Access Switch與Core Switch?？衫斫鉃榉?wù)器互訪流量從進入Access Switch，經(jīng)過Core Switch，再從另一個Access Switch轉(zhuǎn)出過程的網(wǎng)絡(luò)處理技術(shù)。原有技術(shù)就是STP了，新技術(shù)分為設(shè)備控制平面虛擬化（VSS/vPC/IRF）和整網(wǎng)數(shù)據(jù)平面虛擬化（SPB/TRILL/Fabric Path）兩大體系。這兩個體系都是網(wǎng)絡(luò)虛擬化中的多虛一方向，在一虛多方向除去傳統(tǒng)的VLAN/VRF外，Cisco的N7000系列還依照X86架構(gòu)虛擬化整出了個VDC。

Network4-數(shù)據(jù)中心跨站點二層網(wǎng)絡(luò)，邊界是Core Switch。目標是跨越核心網(wǎng)為多個數(shù)據(jù)中心站點的Core Switch之間建立一條二層通道。根據(jù)站點間互聯(lián)核心網(wǎng)的區(qū)別，分為以下三類技術(shù)：

光纖直連（SDH/DWDM等）對應(yīng)Ethernet（RPR）

MPLS核心網(wǎng)對以L2VPN（VLL/VPLS）

IP核心網(wǎng)對應(yīng)IP隧道技術(shù)（VLLoGRE/VPLSoGRE/L2TPv3/OTV）

Cisco的OTV雖然主要應(yīng)用在IP核心網(wǎng)中，但實際前面兩種方式下同樣可以使用，只要多個數(shù)據(jù)中心站點的Core Switch設(shè)備間能夠建立可達的IP路徑即可部署。使用VLL/VPLS相關(guān)技術(shù)時必須要增加專門的PE設(shè)備為站點間的Core Switch建立二層隧道，而OTV可以直接部署在Core Switch上。

Network5-數(shù)據(jù)中心多站點選擇，技術(shù)邊界在數(shù)據(jù)中心與廣域網(wǎng)相連的邊緣。在云計算中，VM跨站點遷移后，業(yè)務(wù)服務(wù)器IP地址不變，網(wǎng)絡(luò)指向需要隨之變化。這塊前面也提到現(xiàn)有技術(shù)就是DNS域名解析與ServerLB的NAT配合，以及主機IP路由發(fā)布等方式。新技術(shù)則是Cisco提出LISP以IPinIP技術(shù)結(jié)構(gòu)繞開DNS，由網(wǎng)絡(luò)設(shè)備單獨處理Client在廣域網(wǎng)中選擇站點的情況。

5.2?網(wǎng)絡(luò)虛擬化

云計算就是計算虛擬化，而存儲虛擬化已經(jīng)在SAN上實現(xiàn)得很好了，那么數(shù)據(jù)中心三大件也就剩下網(wǎng)絡(luò)虛擬化了。那么為什么要搞網(wǎng)絡(luò)虛擬化呢？還是被計算逼的。云計算多虛一時，所有的服務(wù)資源都成為了一個對外的虛擬資源，那么網(wǎng)絡(luò)不管是從路徑提供還是管理維護的角度來說，都得跟著把一堆的機框盒子進行多虛一統(tǒng)一規(guī)劃。而云計算一虛多的時候，物理服務(wù)器都變成了一堆的VM，網(wǎng)絡(luò)怎么也要想辦法搞個一虛多對通路建立和管理更精細化一些不是。

5.2.1?網(wǎng)絡(luò)多虛一技術(shù)

先說網(wǎng)絡(luò)多虛一技術(shù)。最早的網(wǎng)絡(luò)多虛一技術(shù)代表是交換機集群Cluster技術(shù)，多以盒式小交換機為主，較為古老，當前數(shù)據(jù)中心里面已經(jīng)很少見了。而新的技術(shù)則主要分為兩個方向，控制平面虛擬化與數(shù)據(jù)平面虛擬化。

控制平面虛擬化

顧名思義，控制平面虛擬化是將所有設(shè)備的控制平面合而為一，只有一個主體去處理整個虛擬交換機的協(xié)議處理，表項同步等工作。從結(jié)構(gòu)上來說，控制平面虛擬化又可以分為縱向與橫向虛擬化兩種方向。

縱向虛擬化指不同層次設(shè)備之間通過虛擬化合多為一，代表技術(shù)就是Cisco的Fabric Extender，相當于將下游交換機設(shè)備作為上游設(shè)備的接口擴展而存在，虛擬化后的交換機控制平面和轉(zhuǎn)發(fā)平面都在上游設(shè)備上，下游設(shè)備只有一些簡單的同步處理特性，報文轉(zhuǎn)發(fā)也都需要上送到上游設(shè)備進行。可以理解為集中式轉(zhuǎn)發(fā)的虛擬交換機

橫向虛擬化多是將同一層次上的同類型交換機設(shè)備虛擬合一， Cisco的VSS/vPC和H3C的IRF都是比較成熟的技術(shù)代表，控制平面工作如縱向一般，都由一個主體去完成，但轉(zhuǎn)發(fā)平面上所有的機框和盒子都可以對流量進行本地轉(zhuǎn)發(fā)和處理，是典型分布式轉(zhuǎn)發(fā)結(jié)構(gòu)的虛擬交換機。Juniper的QFabric也屬于此列，區(qū)別是單獨弄了個Director盒子只作為控制平面存在，而所有的Node QFX3500交換機同樣都有自己的轉(zhuǎn)發(fā)平面可以處理報文進行本地轉(zhuǎn)發(fā)。

控制平面虛擬化從一定意義上來說是真正的虛擬交換機，能夠同時解決統(tǒng)一管理與接口擴展的需求。但是有一個很嚴重的問題制約了其技術(shù)的發(fā)展。在前面的云計算多虛一的時候也提到過，服務(wù)器多虛一技術(shù)目前無法做到所有資源的靈活虛擬調(diào)配，而只能基于主機級別，當多機運行時，協(xié)調(diào)者的角色（等同于框式交換機的主控板控制平面）對同一應(yīng)用來說，只能主備，無法做到負載均衡。

網(wǎng)絡(luò)設(shè)備虛擬化也同樣如此，以框式設(shè)備舉例，不管以后能夠支持多少臺設(shè)備虛擬合一，只要不能解決上述問題，從控制平面處理整個虛擬交換機運行的物理控制節(jié)點主控板都只能有一塊為主，其他都是備份角色（類似于服務(wù)器多虛一中的HA Cluster結(jié)構(gòu)）?？偠灾?，虛擬交換機支持的物理節(jié)點規(guī)模永遠會受限于此控制節(jié)點的處理能力。這也是Cisco在6500系列交換機的VSS技術(shù)在更新?lián)Q代到Nexus7000后被砍掉，只基于鏈路聚合做了個vPC的主要原因。三層IP網(wǎng)絡(luò)多路徑已經(jīng)有等價路由可以用了，二層Ethernet網(wǎng)絡(luò)的多路徑技術(shù)在TRILL/SPB實用之前只有一個鏈路聚合，所以只做個vPC就足矣了。另外從Cisco的FEX技術(shù)只應(yīng)用于數(shù)據(jù)中心接入層的產(chǎn)品設(shè)計，也能看出其對這種控制平面虛擬化后帶來的規(guī)模限制以及技術(shù)應(yīng)用位置是非常清晰的。

數(shù)據(jù)平面虛擬化

前面說了控制平面虛擬化帶來的規(guī)模限制問題，而且短時間內(nèi)也沒有辦法解決，那么就想個法子躲過去。能不能只做數(shù)據(jù)平面的虛擬化呢，于是有了TRILL和SPB。關(guān)于兩個協(xié)議的具體細節(jié)下文會進行展開，這里先簡單說一下，他們都是用L2 ISIS作為控制協(xié)議在所有設(shè)備上進行拓撲路徑計算，轉(zhuǎn)發(fā)的時候會對原始報文進行外層封裝，以不同的目的Tag在TRILL/SPB區(qū)域內(nèi)部進行轉(zhuǎn)發(fā)。對外界來說，可以認為TRILL/SPB區(qū)域網(wǎng)絡(luò)就是一個大的虛擬交換機，Ethernet報文從入口進去后，完整的從出口吐出來，內(nèi)部的轉(zhuǎn)發(fā)過程對外是不可見且無意義的。

這種數(shù)據(jù)平面虛擬化多合一已經(jīng)是廣泛意義上的多虛一了，相信看了下文技術(shù)理解一節(jié)會對此種技術(shù)思路有更深入的了解。此方式在二層Ethernet轉(zhuǎn)發(fā)時可以有效的擴展規(guī)模范圍，作為網(wǎng)絡(luò)節(jié)點的N虛一來說，控制平面虛擬化目前N還在個位到十位數(shù)上晃悠，數(shù)據(jù)平面虛擬化的N已經(jīng)可以輕松達到百位的范疇。但其缺點也很明顯，引入了控制協(xié)議報文處理，增加了網(wǎng)絡(luò)的復雜度，同時由于轉(zhuǎn)發(fā)時對數(shù)據(jù)報文多了外層頭的封包解包動作，降低了Ethernet的轉(zhuǎn)發(fā)效率。

從數(shù)據(jù)中心當前發(fā)展來看，規(guī)模擴充是首位的，帶寬增長也是不可動搖的，因此在網(wǎng)絡(luò)多虛一方面，控制平面多虛一的各種技術(shù)除非能夠突破控制層多機協(xié)調(diào)工作的技術(shù)枷鎖，否則只有在中小型數(shù)據(jù)中心里面刨食的份兒了，后期真正的大型云計算數(shù)據(jù)中心勢必是屬于TRILL/SPB此類數(shù)據(jù)平面多虛一技術(shù)的天地。當然Cisco的FEX這類定位于接入層以下的技術(shù)還是可以與部署在接入到核心層的TRILL/SPB相結(jié)合，擁有一定的生存空間。估計Cisco的云計算數(shù)據(jù)中心內(nèi)部網(wǎng)絡(luò)技術(shù)野望如下圖所示：（Fabric Path是Cisco對其TRILL擴展后技術(shù)的最新稱呼）

5.2.2?網(wǎng)絡(luò)一虛多技術(shù)

再說網(wǎng)絡(luò)一虛多，這個可是根源久遠，從Ethernet的VLAN到IP的VPN都是大家耳熟能詳?shù)某墒旒夹g(shù)，F(xiàn)C里面也有對應(yīng)的VSAN技術(shù)。此類技術(shù)特點就是給轉(zhuǎn)發(fā)報文里面多插入一個Tag，供不同設(shè)備統(tǒng)一進行識別，然后對報文進行分類轉(zhuǎn)發(fā)。代表如只能手工配置的VLAN ID和可以自協(xié)商的MPLS Label。傳統(tǒng)技術(shù)都是基于轉(zhuǎn)發(fā)層面的，雖然在管理上也可以根據(jù)VPN進行區(qū)分，但是CPU/轉(zhuǎn)發(fā)芯片/內(nèi)存這些基礎(chǔ)部件都是只能共享的。目前最新的一虛多技術(shù)就是Cisco在X86架構(gòu)的Nexus7000上實現(xiàn)的VDC，和VM一樣可以建立多個VDC并將物理資源獨立分配，目前的實現(xiàn)是最多可建立4個VDC，其中還有一個是做管理的，推測有可能是通過前面講到過的OS-Level虛擬化實現(xiàn)的。

從現(xiàn)有階段來看，VDC應(yīng)該是Cisco推出的一項實驗性技術(shù)，因為目前看不到大規(guī)模應(yīng)用的場景需求。首先轉(zhuǎn)發(fā)層面的流量隔離（VLAN/VPN等）已經(jīng)做得很好了，沒有必要搞個VDC專門做業(yè)務(wù)隔離，況且從當前VDC的實現(xiàn)數(shù)量（4個）上也肯定不是打算向這個方向使勁。如果不搞隔離的話，一機多用也沒有看出什么實用性，虛擬成多個數(shù)據(jù)中心核心設(shè)備后，一個物理節(jié)點故障導致多個邏輯節(jié)點歇菜，整體網(wǎng)絡(luò)可靠性明顯降低。另外服務(wù)器建VM是為了把物理服務(wù)器空余的計算能力都用上，而在云計算數(shù)據(jù)中心里面網(wǎng)絡(luò)設(shè)備的接口數(shù)應(yīng)該始終是供不應(yīng)求的，哪里有多少富裕的還給你搞什么虛擬化呢。作者個人對類似VDC技術(shù)在云計算數(shù)據(jù)中心里面的發(fā)展前景是存疑的。

SR-IOV

對網(wǎng)絡(luò)一虛多這里還有個東西要補充一下，就是服務(wù)器網(wǎng)卡的IO虛擬化技術(shù)。單根虛擬化SR-IOV是由PCI SIG Work Group提出的標準，Intel已經(jīng)在多款網(wǎng)卡上提供了對此技術(shù)的支持，Cisco也推出了支持IO虛擬化的網(wǎng)卡硬件Palo。Palo網(wǎng)卡同時能夠封裝VN-Tag（VN的意思都是Virtual Network），用于支撐其FEX+VN-Link技術(shù)體系。現(xiàn)階段Cisco還是以UCS系列刀片服務(wù)器集成網(wǎng)卡為主，后續(xù)計劃向盒式服務(wù)器網(wǎng)卡推進，但估計會受到傳統(tǒng)服務(wù)器和網(wǎng)卡廠商們的聯(lián)手狙擊。

SR-IOV就是要在物理網(wǎng)卡上建立多個虛擬IO通道，并使其能夠直接一一對應(yīng)到多個VM的虛擬網(wǎng)卡上，用以提高虛擬服務(wù)器的轉(zhuǎn)發(fā)效率。具體說是對進入服務(wù)器的報文，通過網(wǎng)卡的硬件查表取代服務(wù)器中間Hypervisor層的VSwitch軟件查表進行轉(zhuǎn)發(fā)。另外SR-IOV物理網(wǎng)卡理論上加塊轉(zhuǎn)發(fā)芯片，應(yīng)該可以支持VM本地交換（其實就是個小交換機啦），但個人目前還沒有看到實際產(chǎn)品。SR（Single Root）里面的Root是指服務(wù)器中間的Hypervisor，單根就是說目前一塊硬件網(wǎng)卡只能支持一個Hypervisor。有單根就有多根，多根指可以支持多個Hypervisor，但貌似目前單物理服務(wù)器里面跑多個Hypervisor還很遙遠，所以多根IO虛擬化MR-IOV也是個未來未來時。摘錄Cisco膠片對MR-IOV描述如下：（HW為Hardware，PF為Physical Function，VF為Virtual Functions）

SR-IOV只定義了物理網(wǎng)卡到VM之間的聯(lián)系，而對外層網(wǎng)絡(luò)設(shè)備來說，如果想識別具體的VM上面的虛擬網(wǎng)卡vNIC，則還要定義一個Tag在物理網(wǎng)卡到接入層交換機之間區(qū)分不同vNIC。此時物理網(wǎng)卡提供的就是一個通道作用，可以幫助交換機將虛擬網(wǎng)絡(luò)接口延伸至服務(wù)器內(nèi)部對應(yīng)到每個vNIC。Cisco UCS服務(wù)器中的VIC（Virtual Interface Card）M81-KR網(wǎng)卡（Palo），就是通過封裝VN-Tag使接入交換機（UCS6100）識別vNIC的對應(yīng)虛擬網(wǎng)絡(luò)接口。

網(wǎng)絡(luò)虛擬化技術(shù)在下一個十年中必定會成為網(wǎng)絡(luò)技術(shù)發(fā)展的重中之重，誰能占領(lǐng)制高點誰就能引領(lǐng)數(shù)據(jù)中心網(wǎng)絡(luò)的前進。從現(xiàn)在能看到的技術(shù)信息分析，Cisco在下個十年中的地位仍然不可動搖。

5.3?技術(shù)理解

進入正式介紹之前再多說兩句如何快速理解技術(shù)的思路。搞網(wǎng)絡(luò)的一般最頭疼最不情愿的就是去讀RFC等標準技術(shù)文檔了，至少心底里有抵觸。各種各樣的報文、狀態(tài)機、數(shù)據(jù)庫、鏈表充斥于字里行間，再加上標準文檔為了避免歧義，一句話能說清楚的也得分成三四句解釋來解釋去。也許是眼界不夠開闊，反正我還真不認識能把草案標準當成小說看的牛人。

這里只是簡單介紹一下協(xié)議入門的經(jīng)驗，如果想要深入甚至精通，那還得去一字一字的考究了，做學問來不得半點馬虎。

學習一門技術(shù)前，首先要了解的是由何而來與從何而去，既技術(shù)產(chǎn)生的背景和應(yīng)用的地方，這樣對其要解決什么樣的問題大致能有個印象。舉例來說PBB是運營商城域以太網(wǎng)技術(shù)，運營商技術(shù)的特點就是組網(wǎng)規(guī)模大，節(jié)點眾多，路徑眾多。而傳統(tǒng)以太網(wǎng)只能使用STP避免環(huán)路，阻塞了一堆鏈路，這個在運營商里面也是不可想象的，那一條條鏈路都是錢啊。因此PBB肯定是要在避免環(huán)路的同時，能夠增大以太網(wǎng)組網(wǎng)規(guī)模和將所有路徑都利用起來的技術(shù)。

再來就是看技術(shù)的類型， Routed Protocol和Routing Protocol兩個詞很好的對技術(shù)組成部分進行了分類。這里的Route可以進行廣義理解，不要只限于IP，作者傾向于將Routed解釋成封裝，Routing解釋成尋址。任何一段數(shù)據(jù)信息從起點A發(fā)送到終點B的過程中，中間網(wǎng)絡(luò)做的事情就是封裝與尋址兩件事。

由于中間網(wǎng)絡(luò)只做傳輸，是不需要了解數(shù)據(jù)信息的，因此要封裝一個可以識別的目的地址Tag，這個Tag可以理解為目的IP/目的MAC/MPLS標簽等等，所有中間設(shè)備只要能識別這個Tag即可，這就是封裝。

再說尋址，網(wǎng)絡(luò)設(shè)備能夠識別目的Tag后，還需要知道對應(yīng)的本地出接口在哪才能將報文轉(zhuǎn)發(fā)出去。最傻瓜的處理方式有兩種，一個是通過手工配置的方式將Tag靜態(tài)對應(yīng)到本地出接口上（如靜態(tài)路由、靜態(tài)MAC等），再有就是在所有接口廣播了（Ethernet）。高級的方式則是使用一種尋址用的動態(tài)協(xié)議，自動的進行鄰居發(fā)現(xiàn)、拓撲計算和Tag傳遞等動作，如使用RIP/OSPF/BGP/ISIS/LDP/PIM/MSDP等等。這里需要注意的是傳統(tǒng)Ethernet是通過廣播來尋址的，注定規(guī)模不能太大。STP的唯一作用就是防止環(huán)路，通過拓撲計算將多余的路徑阻塞掉，與尋址無關(guān)。而前面提到的那些尋址協(xié)議主要任務(wù)都是傳遞Tag計算轉(zhuǎn)發(fā)路徑，大部分協(xié)議會通過計算拓撲來防止環(huán)路，但也有如RIP這種不計算拓撲的協(xié)議，搞些水平分割、毒性逆轉(zhuǎn)和最大跳數(shù)等機制來避免環(huán)路。

封裝解封裝技術(shù)是網(wǎng)絡(luò)入口與出口節(jié)點在原始數(shù)據(jù)信息前將Tag進行加載剝離動作，尋址技術(shù)則是在網(wǎng)絡(luò)節(jié)點之間運行的交互動作。在很多協(xié)議技術(shù)中提到的數(shù)據(jù)平面其實就是封裝轉(zhuǎn)發(fā)，而控制平面就是標識尋址。

圖是不是很眼熟，大部分的網(wǎng)絡(luò)協(xié)議夠可以照著這個模型去套的。

對于IP來說，Sender和Receiver就是TCP協(xié)議棧，Edge就是IP協(xié)議棧，Core就是Router，Payload就是TCP數(shù)據(jù)，Tag就是IP頭中的目的IP；

對于Ethernet來說，Sender和Receiver就是IP協(xié)議棧，Edge就是網(wǎng)卡接口，Core就是Switch，Payload就是IP數(shù)據(jù)，Tag即使Ethernet頭中的目的MAC；

對于MPLS來說，Sender和Receiver就是CE，Edge就是PE，Core就是P；Payload就是Ethernet/IP數(shù)據(jù)，Tag就是MPLS標簽；

甚至對于分布式結(jié)構(gòu)機框交換機來說，Sender和Receiver就是接口板轉(zhuǎn)發(fā)芯片，Edge就是接口板上的交換接口芯片，Core就是交換芯片，Payload就是Ethernet數(shù)據(jù)報文，Tag就是目的Slot ID和Port ID（交換芯片轉(zhuǎn)發(fā)時只看Slot ID，目的接口板查看Port ID）。

傳統(tǒng)的FC/IP/Ethernet技術(shù)體系上面已經(jīng)玩不出來花了，現(xiàn)在新的技術(shù)大都是在FC/IP/Ethernet等數(shù)據(jù)載荷外面增加個新的Tag并設(shè)計一套對應(yīng)的尋址協(xié)議機制（如MPLS和下文的FEX/ TRILL等），或者干脆就還使用原有的IP/MAC作為外層封裝Tag，只對尋址進行變化。對于后者，作者喜歡稱呼其為嫁接技術(shù)，神馬MACinMAC，IPinIP，MACinIP等等都屬于此列。此類技術(shù)的好處是兼容，缺點是繼承，縫縫補補肯定沒有全新設(shè)計來得自由。

封裝比較好明白，協(xié)議理解的難點其實在于尋址。前面說了，靜態(tài)尋址要手工一條條配置，規(guī)模大了能累死人。動態(tài)尋址技術(shù)配置工作量小了很多，但復雜度就上升了好幾個臺階。不勞力就勞心，目前看來大家還是更喜歡勞心一些?；貋碚f動態(tài)尋址，除了RIP這種早期的靠廣播來傳遞路由Tag的尋址協(xié)議外，后面出來的都是先建鄰接，后畫拓撲，再傳Tag的三步走了，從OSPF/BGP/ISIS到下面要講到的TRILL/SPB/OTV皆是如此。對尋址技術(shù)主要內(nèi)容簡單歸納如下，細的就要看各協(xié)議具體實現(xiàn)了，希望有助于讀者在學習尋址協(xié)議時能夠少死些腦細胞。（文學素養(yǎng)有限，合轍押韻就算了吧）

建立鄰居靠Hello（Advertise），拆除鄰接等超時。各自為根繪周邊，主根擴散畫整網(wǎng)。Tag同步傳更新，本地過期發(fā)刪除。

技術(shù)理解部分就說這些，希望對讀者認識新技術(shù)時能夠有所幫助。下面開始進入技術(shù)主題。

5.4?VM本地互訪網(wǎng)絡(luò)技術(shù)

本章節(jié)重點技術(shù)名詞：EVB/VEPA/Multichannel/ SR-IOV/VN-Link/FEX/VN-Tag/ UCS/ 802.1Qbh/802.1Qbg

題目中的本地包含了兩個層面，一個是從服務(wù)器角度來看的物理服務(wù)器本地VM互訪，一個是從交換機角度來看的接入層交換機本地VM互訪。這兩個看問題的角度造成了下文中EVB與BPE兩個最新技術(shù)體系出發(fā)點上的不同。

在VM出現(xiàn)伊始，VMware等虛擬機廠商就提出了VSwitch的概念，通過軟件交換機解決同一臺物理服務(wù)器內(nèi)部的VM二層網(wǎng)絡(luò)互訪，跨物理服務(wù)器的VM二層互訪丟給傳統(tǒng)的Ethernet接入層交換機去處理。這時有兩個大的問題產(chǎn)生了，一是對于VSwitch的管理問題，前面說過大公司網(wǎng)絡(luò)和服務(wù)器一般是兩撥人負責的，這個東西是由誰來管理不好界定；二是性能問題，交換機在處理報文時候可以通過轉(zhuǎn)發(fā)芯片完成ACL packet-filter、Port Security（802.1X）、Netflow和QoS等功能，如果都在VSwitch上實現(xiàn)，還是由服務(wù)器的CPU來處理，太消耗性能了，與使用VM提高服務(wù)器CPU使用效率的初衷不符。

Cisco首先提出了Nexus1000V技術(shù)結(jié)構(gòu)來解決前面的問題一，也只解決了問題一。為了解決問題二， IEEE（Institute of Electrical and Electronics Engineers）標準組織提出了802.1Qbg EVB（Edge Virtual Bridging）和802.1Qbh BPE（Bridge Port Extension）兩條標準路線了，Cisco由802.1Qbh標準體系結(jié)構(gòu)實現(xiàn)出來的具體技術(shù)就是FEX+VN-Link。

在數(shù)據(jù)通信世界只有兩個陣營：Cisco和非Cisco。而就目前和能預見到的未來而言，非Cisco們都仍是Cisco的跟隨者和挑戰(zhàn)者，從數(shù)據(jù)中心新技術(shù)發(fā)展就可見一斑。在VM本地互訪網(wǎng)絡(luò)技術(shù)章節(jié)中會先介紹Cisco的相關(guān)技術(shù)與產(chǎn)品，再講講挑戰(zhàn)者們的EVB。

5.4.1?Cisco接入層網(wǎng)絡(luò)虛擬化

Cisco在其所有的VM接入技術(shù)中都有兩個主要思路：一是將網(wǎng)絡(luò)相關(guān)內(nèi)容都虛擬化為一臺邏輯的框式交換機來集中由網(wǎng)絡(luò)進行管理，二是給每個VM提供一個虛擬交換機接口（vETH/VIF）。目的都是以網(wǎng)絡(luò)為根，將枝葉一步步伸到服務(wù)器里面去。

802.1Qbh

先來看下802.1Qbh BPE（Bridge Port Extension），下圖是Cisco以UCS系列產(chǎn)品對應(yīng)的結(jié)構(gòu)圖。

802.1Qbh定義的是VM與接入層交換機之間的數(shù)據(jù)平面轉(zhuǎn)發(fā)結(jié)構(gòu)，不包括控制平面。這里可以將其看為一臺虛擬的集中式框式交換機，其中CB可以理解為帶轉(zhuǎn)發(fā)芯片的主控板，PE就是接口板。PE進入服務(wù)器內(nèi)部是通過硬件網(wǎng)卡來實現(xiàn)的，后續(xù)可能在Hypervisor層面會做軟件PE來實現(xiàn)。Cisco通過FEX來定義CB到PE以及PE到PE的關(guān)系，其數(shù)據(jù)平面是通過封裝私有的VN-Tag頭來進行尋址轉(zhuǎn)發(fā)；通過VN-Link來定義PE的最終點DI到VM的vNIC之間的關(guān)系，提出了Port Profile來定制DI的配置內(nèi)容。

在802.1Qbh結(jié)構(gòu)中，整個網(wǎng)絡(luò)是樹狀連接，每個PE只能上行連接到一個邏輯的PE/CB，因此不存在環(huán)路，也就不需要類似于STP這種環(huán)路協(xié)議。所有的VM之間通信流量都要上送到CB進行查表轉(zhuǎn)發(fā)，PE不提供本地交換功能。PE對從DI收到的單播報文只會封裝Tag通過UI上送，UI收到來的單播報文根據(jù)Tag找到對應(yīng)的DI發(fā)送出去。對組播/廣播報文根據(jù)Tag里面的組播標志位，CB和PE均可以進行本地復制泛洪。更具體的轉(zhuǎn)發(fā)處理流程請參考下文Nexus5000+Nexus2000的技術(shù)介紹。

Cisco根據(jù)802.1Qbh結(jié)構(gòu)在接入層一共虛擬出三臺框式交換機，Nexus1000V（VSM+VEM）、Nexus5000+Nexus2000和UCS。其中1000V還是基于Ethernet傳統(tǒng)交換技術(shù)的服務(wù)器內(nèi)部軟件交換機，沒有FEX，主要體現(xiàn)VN-Link；而Nexus5000+Nexus2000則是工作于物理服務(wù)器之外的硬件交換機盒子，以FEX為主，VN-Link基本沒有；只有到UCS才通過服務(wù)器網(wǎng)卡+交換機盒子，完美的將FEX+VN-Link結(jié)合在一起。下面來逐臺介紹。

Cisco Nexus1000V

Nexus1000V包含兩個組件VSM（Virtual Supervisor Module）與VEM（Virtual Ethernet Module）?？疵志湍芮瞥鯲SM對應(yīng)機框交換機的主控板Supervisor，而VEM對應(yīng)其接口板。

VEM就是一臺安裝運行在采用裸金屬虛擬化結(jié)構(gòu)的物理服務(wù)器中Hypervisor層次的軟件交換機，其虛擬接口vETH分為連接VM虛擬網(wǎng)卡vNIC的下行接口和連接到每個物理網(wǎng)卡接口的上行接口，使用Ethernet基于MAC方式進行報文轉(zhuǎn)發(fā)。由于其處于網(wǎng)絡(luò)的末端，不需要運行STP，通過不允許上行接口收到的報文從其他上行接口轉(zhuǎn)發(fā)的規(guī)則來避免環(huán)路的產(chǎn)生。與早期的VSwitch相比多了很多交換機相關(guān)功能。

VSM則有兩種形態(tài)，可以是獨立的盒子，也可以是裝在某個OS上的應(yīng)用軟件。要求VSM和VEM之間二層或三層可達，二層情況下VSM與VEM之間占用一個VLAN通過組播建立連接，三層情況下通過配置指定IP地址單播建立連接。VSM是一個控制平臺，對VEM上的vETH進行配置管理。通過VSM可以直接配置每臺VEM的每個vETH。

VSM在管理vETH的時候引入了Port Profile的概念，簡單理解就是個配置好的模板，好處是可以一次配置，四處關(guān)聯(lián)。在VM跨物理服務(wù)器遷移時，VSM就可以通過vCenter的通知了解到遷移發(fā)生，隨之將Port Profile下發(fā)到VM遷移后對應(yīng)的vETH上，使網(wǎng)絡(luò)能夠隨VM遷移自適應(yīng)變化。

VN-Link是CISCO在虛擬接入層的關(guān)鍵技術(shù)，VN-Link=vNIC+vETH+Port Profile。

Nexus1000V中的vETH是建立在軟件交換機上的，而下文UCS系統(tǒng)里面的vETH就建立在Cisco的網(wǎng)卡硬件上了，對應(yīng)到UCS虛擬交換機上就是VIF（Virtual Interface），同時UCS通過硬件實現(xiàn)可以把FEX里面要介紹的VN-Tag網(wǎng)絡(luò)封裝標識引入到物理服務(wù)器里面。

VEM之間通過普通Ethernet交換機相連，跨VEM轉(zhuǎn)發(fā)的流量也是傳統(tǒng)以太網(wǎng)報文，因此Nexus1000V雖然可以理解為一臺虛擬交換機，但不是集中式或分布式結(jié)構(gòu)，也不存在交換芯片單元，僅僅是配置管理層面的虛擬化，屬于對傳統(tǒng)VSwitch的功能擴展，只解決了最開始提到的管理邊界問題，但對服務(wù)器性能仍然存在極大耗費。

從產(chǎn)品與標準的發(fā)布時間上看，Nexus1000V是先于802.1Qbh推出的，因此推測Cisco是先做了增強型的VSwitch-Nexus1000V，然后才逐步理清思路去搞802.1Qbh的BPE架構(gòu)。1000V屬于過渡性質(zhì)的兼容產(chǎn)品，后續(xù)應(yīng)該會對其做些大的改動，如改進成可支持VN-Tag封裝的軟件PE，幫助N5000+N2000進入物理服務(wù)器內(nèi)部，構(gòu)造FEX+VN-Link的完整802.1Qbh結(jié)構(gòu)。

Nexus5000+Nexus2000

N5000+N2000組成了一臺集中式結(jié)構(gòu)的虛擬交換機，集中式是指所有的流量都要經(jīng)過N5000交互，N2000不提供本地交換能力，只是作為N5000的接口擴展。對應(yīng)802.1Qbh結(jié)構(gòu)，N5000就是CB，而N2000就是PE。組合出來的虛擬交換機中，N5000就是帶轉(zhuǎn)發(fā)芯片和交換芯片的主控板，而N2000則是接口板，整體更像Cisco早期的4500系列機框或使用主控板PFC進行轉(zhuǎn)發(fā)的6500系列機框，但是在N5000盒子內(nèi)部又是以分布式結(jié)構(gòu)處理轉(zhuǎn)發(fā)芯片與交換芯片連接布局的，可參考如下的N5000和6500結(jié)構(gòu)比較圖。整了半天其實數(shù)據(jù)平面轉(zhuǎn)發(fā)報文還是那幾個步驟。

N5000+N2000實現(xiàn)了Cisco的FEX典型結(jié)構(gòu)（Fabric Extend，等同于Port Extend）。在N5000上看到每臺N2000就是以一個FEX節(jié)點形式出現(xiàn)的接口板。N2000擁有兩種物理接口類型，連接下游設(shè)備（可以是服務(wù)器或N2000，F(xiàn)EX結(jié)構(gòu)支持級聯(lián)擴展）的HIF（Host Interface）和連接上游N5000和N2000的NIF（Network Interface），此兩種接口是固定于面板上的，且角色不可變更。以2248T舉例，右側(cè)黃色接口為NIF，其他為HIF。

Cisco將FEX結(jié)構(gòu)又稱為Network Interface Virtualization Architecture (NIV)，在NIV中將N2000上的HIF稱為Virtual Interface (VIF)，將N5000上對應(yīng)HIF的邏輯接口稱為Logical Interface (LIF)。截取Cisco膠片如下描述NIV的內(nèi)容。

在NIV模型中所有的數(shù)據(jù)報文進入VIF/LIF時均會被封裝VN-Tag傳遞，在從VIF/LIF離開系統(tǒng)前會剝離VN-Tag。VN-Tag就是在FEX內(nèi)部尋址轉(zhuǎn)發(fā)使用的標識，類似于前面框式交換機內(nèi)部在轉(zhuǎn)發(fā)芯片與交換芯片傳輸報文時定義槽位信息與接口信息的標識。VN-Tag格式與封裝位置如下：

d位標識報文的走向，0代表是由N2000發(fā)往N5000的上行流量，1代表由N5000發(fā)往N2000的下行流量。

p位標識報文復制，0代表不需要復制，1代表N2000收到此報文后需要向同VLAN的所有本地下行接口復制。此位只有N5000可以置位。

l位標識報文是否返回給源N2000，既0代表源和目的接口不在同一個N2000上，1代表目的與源接口都在同一個N2000設(shè)備上。

DVI（Destination Virtual Interface）標識目的HIF接口，SVI（Source Virtual Interface）標識源HIF接口。每個HIF接口ID在一組FEX系統(tǒng)中都是唯一的。

流量轉(zhuǎn)發(fā)時，N2000首先從源HIF收到報文，只需要標識SVI的對應(yīng)HIF信息，其他位都置0不用管，直接從NIF轉(zhuǎn)發(fā)到N5000上即可。N5000收到報文，記錄源HIF接口與源MAC信息到轉(zhuǎn)發(fā)表中，查MAC轉(zhuǎn)發(fā)表，如果目的MAC對應(yīng)非LIF接口則剝離VN-Tag按正常Ethernet轉(zhuǎn)發(fā)處理；如果目的接口為LIF接口，則重新封裝VN-Tag。其中DVI對應(yīng)目的HIF，SVI使用原始SVI信息（如果是從非LIF源接口來的報文則SVI置0），d位置1，如果是組播報文則p位置1，如果目的接口與源接口在一臺N2000上則l位置1。N2000收到此報文后根據(jù)DVI標識查找本地目的出接口HIF，剝離VN-Tag后進行轉(zhuǎn)發(fā)，如果p位置1則本地復制轉(zhuǎn)發(fā)給所有相關(guān)HIF。每個FEX的組播轉(zhuǎn)發(fā)表在5000上建立，所有2000上通過IGMP-Snooping同步。轉(zhuǎn)發(fā)過程截取Cisco膠片介紹如下：

從前面NIV的結(jié)構(gòu)圖中可以看到Cisco希望將FEX通過網(wǎng)卡推進到服務(wù)器內(nèi)部，但實際上目前階段由于Cisco在服務(wù)器網(wǎng)卡方面的市場地位，這個還只是一個夢想。N2000還是只能基于物理服務(wù)器的物理網(wǎng)卡為基本單元進行報文處理，搞不定VM的vNIC，因此前面說N5000+N2000這臺虛擬交換機只實現(xiàn)了FEX，但沒有VN-Link。

好吧，搞不定服務(wù)器就搞不定網(wǎng)卡，更沒有辦法推行FEX+VN-Link的802.1Qbh理念。于是Cisco一狠心，先搞了套UCS出來。

UCS

UCS（Unified Computing System）是包括刀箱、服務(wù)器、網(wǎng)卡、接口擴展模塊、接入交換機與管理軟件集合的系統(tǒng)總稱。這里面的各個單元獨立存在時雖然也能用，但就沒有太大的價值了，與其他同檔產(chǎn)品相比沒有任何優(yōu)勢，只有和在一起才是Cisco征戰(zhàn)天下的利器。UCS產(chǎn)品結(jié)構(gòu)如下圖所示：

其中服務(wù)器、刀箱機框和管理軟件都是標準的東西，沒啥可多說的。關(guān)鍵部件就是網(wǎng)卡、交換機和刀箱的擴展線卡（Fabric Extender，這個名字個人覺得不好，容易與FEX結(jié)構(gòu)混淆，可以叫個FE Blade或者Fabric Line Card什么的）。Interconnect交換機對應(yīng)N5000，F(xiàn)abric Extender對應(yīng)N2000，這樣加上Virtual Adapters就可以實現(xiàn)前面NIV結(jié)構(gòu)中將VIF（HIF）直接連到VM前的期望了，從而也就能夠完美實現(xiàn)802.1Qbh BPE（Cisco FEX+VN-Link）的技術(shù)體系結(jié)構(gòu)。

整個UCS系統(tǒng)結(jié)構(gòu)就在下面這三張圖中體現(xiàn)，分別對應(yīng)數(shù)據(jù)平面（轉(zhuǎn)發(fā)平面）、控制平面、管理平面。由于技術(shù)實現(xiàn)上和前面將的FEX和VN-Link沒有大的區(qū)別，不再做重復贅述，有興趣的同學可自行細琢磨。

再補充一張UCS VN-Link的示意圖，可以對應(yīng)看一下三要素vNIC、vEth和Port Profile的位置連接關(guān)系。

UCS就說這么多了，前面介紹的Cisco三臺虛擬交換機如果鋪開了講每個都有上百頁的內(nèi)容，本文只是希望能夠從結(jié)構(gòu)上幫助大家理解，將作者的知識大廈框架拿出來與讀者共享參考，至于每個人的樓要怎么蓋還需自己去添磚加瓦。包括下文的技術(shù)點講解也是如此，作者會將自己認為最重要的關(guān)鍵部分講出來，細節(jié)不會過于展開。

5.4.2?802.1Qbg EVB

說完了Cisco再說說非Cisco陣營，在如802.1Qbg EVB和802.1aq SPB等所謂挑戰(zhàn)技術(shù)的參與編纂者中，都會看到Cisco的身影。如下圖為2009年IEEE Atlanta, GA時發(fā)出的EVB所有撰稿相關(guān)人名單。

802.1Qbg當時的主要撰寫人是HP的Paul Congdon，不過最近幾稿主要Draft已經(jīng)由Paul Bottorff取代。其中Cisco的Joe Pelissier也是802.1Qbh的主要撰寫人，而Bottorff也同樣參與了802.1Qbh的撰寫工作。單從技術(shù)上講，這二者并不是對立的，而是可以互補的，上述兩位HP和Cisco的達人都正在為兩種技術(shù)結(jié)構(gòu)融合共存而努力。具體可以訪問http://www.ieee802.org/1/pages/dcbridges.html 對這兩個處于Active階段的Draft進行學習。

802.1Qbh通過定義新的Tag（VN-Tag）來進行接口擴展，這樣就需要交換機使用新的轉(zhuǎn)發(fā)芯片能夠識別并基于此新定義Tag進行轉(zhuǎn)發(fā)，因此目前除了Cisco自己做的芯片外，其他廠商都無法支持。只有等Broadcom和Marvel等芯片廠商的公共轉(zhuǎn)發(fā)芯片也支持了，大家才能跟進做產(chǎn)品，這就是設(shè)備廠商有沒有芯片開發(fā)能力的區(qū)別。而802.1Qbg就走了另外一條路，搞不定交換機轉(zhuǎn)發(fā)芯片就先想辦法搞定服務(wù)器吧。下面從IEEE截取的圖中可以看到EVB的四個主要組成部分，也可以看做四個發(fā)展階段。當前處于VEPA的成長期，已經(jīng)出現(xiàn)部分轉(zhuǎn)化完成的產(chǎn)品，而Multichannel還在產(chǎn)品轉(zhuǎn)化前的研究狀態(tài)。

先說VEB，這個最好理解，就是定義了物理服務(wù)器內(nèi)部的軟、硬件交換機。軟件交換機就是前面提過的VSwitch，硬件交換機就是從SR-IOV演進來的網(wǎng)卡交換機。SR-IOV已經(jīng)可以使VM的vNIC在物理網(wǎng)卡上一一對應(yīng)通道化了，那么再加個轉(zhuǎn)發(fā)芯片基本就可以做成最簡單的交換機了，當然這只是原理上可行，實際中作者還沒有見過成熟產(chǎn)品。VEB與普通Ethernet交換機的最大區(qū)別是定義了連接交換機的上行口與連接VM的下行口，而VEB的上行口間是不允許相互轉(zhuǎn)發(fā)報文的，這樣可以在不支持STP的情況下保證無環(huán)路產(chǎn)生。Cisco的N1000V 就可以認為是個VEB。VEB的優(yōu)點是好實現(xiàn)，在Hypervisor層面開發(fā)軟件或者改造網(wǎng)卡就可以出成品，缺點是不管軟件的還是硬件的相比較傳統(tǒng)交換機來說能力和性能都偏弱，網(wǎng)卡上就那么點兒大的地方，能放多少CPU、TCAM和ASIC啊。

于是有了VEPA，VEPA比VEB更簡單，不提供VM間的交換功能，只要是VM來的報文都直接扔到接入交換機上去，只有接入交換機來的報文才查表進行內(nèi)部轉(zhuǎn)發(fā)，同樣不允許上行接口間的報文互轉(zhuǎn)。這樣首先是性能提升了，去掉了VM訪問外部網(wǎng)絡(luò)的流量查表動作。其次是將網(wǎng)絡(luò)方面的功能都扔回給接入層交換機去干了，包括VM間互訪的流量。

這樣不但對整體轉(zhuǎn)發(fā)的能力和性能有所提升，而且還解決了前面最開始VSwitch所提出的網(wǎng)絡(luò)與服務(wù)器管理邊界的問題。相比Cisco將網(wǎng)絡(luò)管理推到VM的vNIC前的思路，這種做法更傳統(tǒng)一些，將網(wǎng)絡(luò)管理邊界仍然阻攔在服務(wù)器外面，明顯是出于服務(wù)器廠商的思路。在傳統(tǒng)Ethernet中，要求交換機對從某接口收到的流量不能再從這個接口發(fā)出去，以避免環(huán)路風暴的發(fā)生。而VEPA的使用要求對此方式做出改變，否則VM之間互訪流量無法通過。對交換機廠商來說，這個改變是輕而易舉的，只要變動一下ASIC的處理規(guī)則即可，不需要像VN-Tag那樣更新整個轉(zhuǎn)發(fā)芯片。從理論上講，如VEB一樣，VEPA同樣可以由支持SR-IOV的網(wǎng)卡來硬件實現(xiàn)，而且由于需要實現(xiàn)的功能更少，因此也更好做一些。個人認為VEPA的網(wǎng)卡可能會先于VEB的網(wǎng)卡流行起來。

下面說說Multichannel，這個東西就有點兒意思了。802.1Qbg的說法是在混雜場景中，物理服務(wù)器中同時有VEB、VEPA和需要直接通過SR-IOV連到交換機的vNIC，而當前對這多種流量在網(wǎng)卡到交換機這條鏈路上是無法區(qū)分識別的，于是整出個Multichannel。參見IEEE的膠片原文如下：

想在一條通道內(nèi)對相同類型流量進行更細的分類，看了前面技術(shù)理解一節(jié)大家應(yīng)該有個思路了，加Tag唄。Multichannel借用了QinQ中的S-VLAN Tag（就是個VLAN標簽）。在數(shù)據(jù)報文從網(wǎng)卡或交換機接口發(fā)出時封裝，從對端接口收到后剝離。簡單的轉(zhuǎn)發(fā)過程如下：

諸位看官看到這里可能會產(chǎn)生疑問，這個和Cisco的BPE很像啊，無非是用S-VLAN取代了VN-Tag作用在網(wǎng)卡和交換機之間。作者個人覺得Multichannel真正瞄準的目標也不是什么多VEB和VEPA之間的混雜組網(wǎng)，至少目前做虛擬化的X86服務(wù)器上還沒有看到這種混雜應(yīng)用的需求場景。

真正的目標應(yīng)該就是通過S-VLAN Tag建立一條VM上vNIC到交換機虛擬接口的通道，和Cisco FEX+VN-Link的目標是等同的，只是沒有考慮網(wǎng)絡(luò)接入層上面的FEX擴展而已。Cisco的達人Joe Pelissier目前在EVB工作組中做的事情也是將其與802.1Qbh在Port Extend方面做的盡量規(guī)則一致?？蓞⒖既缦履z片內(nèi)容：

Multichannel相比VN-Tag的優(yōu)勢是交換機目前大部分的轉(zhuǎn)發(fā)芯片就已經(jīng)支持多層VLAN標簽封裝的QinQ技術(shù)了，而網(wǎng)卡封裝VLAN Tag也是現(xiàn)成的，只要從處理規(guī)則上進行一些改動就可以完全實現(xiàn)。但由于其未考慮網(wǎng)絡(luò)方面的擴展，S-VLAN還不能進行交換機透傳，只能在第一跳交換機終結(jié)，所以從接入層網(wǎng)絡(luò)部署規(guī)模上很難與FEX抗衡。

最后一個是Remote Replication復制問題。Ethernet網(wǎng)絡(luò)當中廣播、組播和未知單播報文都需要復制，而前面的Multichannel結(jié)構(gòu)所有的復制工作都會在交換機完成，于是會造成帶寬和資源的極大浪費，如下圖所示：

此時需要定制一個標志位，以通知每個S-VLAN組件進行本地復制。當前在802.1Qbg中此標志位叫做M標識，其實和VN-Tag字段中的p標志位一個作用，因此這塊也是由Cisco的達人Joe Pelissier在完善。M標識的位置和作用如下圖所示：

整個EVB就這些內(nèi)容了，雖然目前還是在不斷改動，但都是些實現(xiàn)細節(jié)方面的東西，大的框架結(jié)構(gòu)應(yīng)該就如上所述不會再變化了。從工作內(nèi)容上就可以看出，HP等服務(wù)器廠商的思維范疇就到VEPA了，Multichannel只是提出個概念，實際上后續(xù)的東東還都要是借鑒Cisco的網(wǎng)絡(luò)思路來實現(xiàn)，個人甚至懷疑連Multichannel都可能是Pelissier提出的，誰專業(yè)誰知道。從大體上來說，EVB總的思路就是希望在盡量對現(xiàn)有設(shè)備最小變更的情況下解決VM接入互訪的問題，從改變Ethernet交換機接口轉(zhuǎn)發(fā)規(guī)則到增加S-VLAN標簽都是如此，但到M標識就不見得還能控制得住了。不過就目前協(xié)議技術(shù)完善和進行產(chǎn)品轉(zhuǎn)化的速度來看，還有得時間進行考慮變化。

5.4.3?小結(jié)

又到了小結(jié)的時間。該有人問了，講了半天802.1Qbh和802.1Qbg這兩個技術(shù)體系誰優(yōu)誰劣，誰勝誰敗啊？作者不是半仙也不是裁判，只能推測無法判斷。從技術(shù)角度講，尤其從網(wǎng)絡(luò)技術(shù)角度講，802.1Qbh BPE提出了一整套的網(wǎng)絡(luò)虛擬化解決方案，而802.1Qbg EVB則只是提出了解決幾個VM網(wǎng)絡(luò)接入問題的辦法，二者的技術(shù)深度不可同日而語。然而對于市場上來說，一時的技術(shù)優(yōu)勢并不能完全左右勝負，各方博弈會使結(jié)局充滿不可預測性，Nortel和3Com的沒落就是例子。從一名技術(shù)至上者的角度出發(fā)，作者更傾向于Cisco，不過一切都有待于市場的檢驗。當然在這個世界上還有些地方存在可以代表市場直接做出裁決的裁判們，他們的裁決結(jié)果看看各公司在當?shù)氐呢攧?wù)貢獻就可以簡單預測，和真正的市場選擇有沒有關(guān)系，你懂的。

順便說一句，802.1Qbh需要變更交換機的轉(zhuǎn)發(fā)芯片以適應(yīng)VN-Tag轉(zhuǎn)發(fā)，而802.1Qbg的VEPA和Multichannel目前則只需要交換機做做軟件驅(qū)動方面的變動即可支持。不論將來誰成為了市場技術(shù)主導，大家覺得Cisco設(shè)備同時支持兩套標準會有什么難度。從市場發(fā)展上大膽預測一下，Cisco會在802.1Qbg標準成熟后，在新一代N2000位置產(chǎn)品上實現(xiàn)對S-VLAN組件和M-Tag的支持，以后的主流結(jié)構(gòu)就是服務(wù)器內(nèi)部用VEPA+SR-IOV，網(wǎng)卡和N2000之間使用S-VLAN區(qū)分通道，N2000再往上到N5000還是封裝VN-Tag的FEX。BPE+EVB才是王道。

YY一下，還有木有啥其他的技術(shù)可以起到類似的作用呢？目前802.1Qbg和802.1Qbh都是通過定義一個Tag來為接入層交換機標識VM（VN-Tag/S-VLAN），那么實際上還有個現(xiàn)成的可用Tag，就是MAC，每個VM的vNIC都擁有獨一無二的MAC，那么是否可以讓交換機根據(jù)源和目的MAC來建立VIF去對應(yīng)處理每個VM的vNIC流量呢。當然細節(jié)上還要設(shè)計很多機制來保障各種情況的正常處理，但是暫時從方向上感覺應(yīng)該有些搞頭，回頭有時間細琢磨一下吧。能不能成標準無所謂，當做頭腦游戲鍛煉思維了。

短期來看，上述廠家標準有得一爭，但從長遠來看，其實硬件交換機進入服務(wù)器內(nèi)部才是王道。畢竟轉(zhuǎn)發(fā)芯片會越來越便宜，性能會越來越高，再發(fā)展幾年，不管是放在網(wǎng)卡上還是集成在主板上都沒有太大難度。

5.5?Ethernet與FC網(wǎng)絡(luò)融合技術(shù)-FCoE

本章節(jié)重點技術(shù)名詞：FC/FC ID/FCoE/FIP/FCF/DCB/NPV

服務(wù)器后端連接存儲設(shè)備的FC網(wǎng)絡(luò)與前端Ethernet網(wǎng)絡(luò)融合是目前傳統(tǒng)以太網(wǎng)交換機廠商進軍后端存儲網(wǎng)絡(luò)的陽謀，Cisco稱其為統(tǒng)一IO。下面會先介紹下FC，然后是FCoE，最后說說NPV。

5.5.1?FC

FC（Fibre Channel）在1994年由ANSI T11制定首個標準，從開始就達到1G帶寬，大家可以想想那時候Ethernet還是什么年代。同時由于其無丟包的協(xié)議特性，受到了存儲網(wǎng)絡(luò)的青睞，成為Server到Storage之間SAN網(wǎng)絡(luò)的霸主，相信由于Ethernet 40G/100G的緩慢發(fā)展速度，F(xiàn)C的地位至少在下個5年內(nèi)還是無可動搖的。在FC通信領(lǐng)域是典型的寡頭獨占市場，前三位中Brocade占據(jù)了70%的市場份額，Cisco占20%，Qlogic占個位數(shù)。2010年統(tǒng)計整個FC Switch市場銷售額約$2B，對眾多的傳統(tǒng)交換機廠商來說，誰不想通過FCoE進去分杯羹呢，即使是Cisco也忍不住想翻身把歌唱。

FC包含Base2與Base10兩套演進道路，Base10主要應(yīng)用在FC交換機之間，使用較少，已經(jīng)快消亡了。下面截圖可以看出其演進情況。

FC擁有自己的獨立層次結(jié)構(gòu)，F(xiàn)C-0到FC-4對應(yīng)OSI模型的1-5層，但也并非一一對應(yīng)，完整協(xié)議內(nèi)容請大家自行查閱標準文檔。其中FC-2定義了數(shù)據(jù)通信的內(nèi)容，是與網(wǎng)絡(luò)方面息息相關(guān)的，下面介紹的內(nèi)容也都是以FC-2為主。

在FC網(wǎng)絡(luò)中一共有三種主要的接口角色，NPort，F(xiàn)Port和EPort，其中N是服務(wù)器或存儲等終端節(jié)點連接FC網(wǎng)絡(luò)的的接口，F(xiàn)是FC交換機設(shè)備連接服務(wù)器或存儲等終端節(jié)點的接口，E是FC交換機互聯(lián)接口。還記得前面技術(shù)理解里面的典型結(jié)構(gòu)么？

FC設(shè)備都擁有2個重要標識：

WWN（World Wide Name）：64bit，節(jié)點和每個接口都有各自固定的WWN且所有的WWN均是唯一的，WWN的作用是為了身份識別和安全控制，有些類似于MAC，但不做轉(zhuǎn)發(fā)尋址使用。

FC ID：24bit，由8個bit的Domain ID，8bit的Area ID和8bit的Port ID組成，每個Domain ID代表一臺FC Switch（由此可以算出每個FC網(wǎng)絡(luò)最多支持256個Switch節(jié)點，減去部分保留ID，實際能夠支持最多239個Switch）。終端節(jié)點的FC ID是基于接口的，每個NPort的FC ID是由直連的FC Switch動態(tài)分配。FC ID的主要作用就是供數(shù)據(jù)報文在FC網(wǎng)絡(luò)中尋址轉(zhuǎn)發(fā)。

有了標識的Tag，那么就需要個動態(tài)協(xié)議供FC Switch互相學習了，F(xiàn)C網(wǎng)絡(luò)使用FSPF（Fabric Shortest Path First）進行FC ID的尋址學習，看名字就知道其協(xié)議機制和OSPF沒有什么大的區(qū)別，不多說了。

FC網(wǎng)絡(luò)中的另外兩個重要概念就是VSAN和Zone，VSAN和VLAN很類似，都是手工配置的，不同VSAN的流量相互隔離，這樣不同VSAN中可以分配相同的FC ID。而且由于VSAN是非公有定義協(xié)議字段，各個廠家實現(xiàn)并不見得一致，因此實際的FC組網(wǎng)中很難見到不同廠商設(shè)備的混合組網(wǎng)。Zone則是類似于ACL的安全特性，配置為同一個Zone的成員可以互訪，不同Zone的就會被隔離。Zone是作用于VSAN內(nèi)部的，可以理解VSAN是底層物理隔離，Zone是上層邏輯分隔。同一個設(shè)備節(jié)點可以屬于不同的Zone，Zone成員以WWN進行標識，可以簡單類比為ACL中的同一個源IP地址可以配置在不同的Rule中對應(yīng)不同的目的IP，以匹配不同的流量。Zone的控制可以是軟件實現(xiàn)，也有相應(yīng)的ASIC可以做硬件處理。

?

當然有隔離還得能互通，就好像做了VPN后還惦記著跨VPN互訪，有了FW還搞個HTTPS翻墻（目前又在研究怎么控制HTTPS內(nèi)容了），F(xiàn)C中也有IVR（Inter-VSAN Routing） Zone的概念，就是通過一些靜態(tài)配置的手段翻越已有的VSAN隔離。人們總是處在不斷的制造藩籬和打破藩籬的循環(huán)中。Zone、VSAN和IVR Zone的關(guān)系如下Cisco資料截圖所示：

FC技術(shù)體系還有最重要的一個關(guān)鍵流控技術(shù)Buffer to Buffer Credits用來確保無丟包轉(zhuǎn)發(fā)。BB Credits和TCP滑動窗口相似，規(guī)則很簡單，兩個相鄰FC節(jié)點在連接初始化的時候先協(xié)商一個度量收包設(shè)備Buffer大小的數(shù)值N出來，發(fā)包設(shè)備每發(fā)一個數(shù)據(jù)報文就做N-1，收包設(shè)備每收一個報文就回一個R_RDY報文回來，發(fā)包設(shè)備每收到一個R_RDY就做N+1，當N=0時，發(fā)包設(shè)備就停止發(fā)包。

這樣當突發(fā)擁塞時，上游設(shè)備們都把報文存在本地緩存中等著，下游有空間時再發(fā)，可以最簡單的避免丟包。BB Credits是以報文數(shù)目衡量buffer能力，與報文長度無關(guān)（FC報文最大長度2112Byte）。另外Credits協(xié)商數(shù)目大小與帶寬和距離存在比率關(guān)系，可參考如下圖示的Cisco建議：

FC設(shè)備（一般指服務(wù)器，稱為Initiator）在傳輸數(shù)據(jù)之前需要進行兩步注冊動作，NPort先通過FLOGI（Fabric Login）注冊到最近的Fabric交換機上，獲取FC ID及其他一些服務(wù)參數(shù)并初始化BB Credits。然后再通過PLOGI（Port Login）注冊到遠端的目的設(shè)備（一般指存儲，稱為Target）的NPort上建立連接，并在P2P直連的拓撲下初始化BB Credits。

FC從標準建立伊始就開始被研究跨傳統(tǒng)TCP/IP/Ethernet網(wǎng)絡(luò)傳播，目前主要有iSCSI（IP SAN）、FCIP、iFCP和FCoE四條道路。其中FCIP和iFCP應(yīng)用最少，iSCSI緩慢增長，F(xiàn)CoE后來居上。

SCSI不熟，這里不多說。FCP（Fibre Channel Protocol）是用來協(xié)助SCSI進行尋址的協(xié)議。iSCSI、FCIP和iFCP都是依靠TCP的可靠連接確保無丟包，但封的報頭多了開銷很大。iSCSI由于需要全新的存儲設(shè)備支持，過于激進，目前雖然有發(fā)展，但是受傳統(tǒng)存儲設(shè)備廠商制約始終很緩慢。FCIP和iFCP都是支持FC網(wǎng)絡(luò)跨IP核心網(wǎng)傳輸時用到的網(wǎng)絡(luò)協(xié)議，由于目前SAN還是本地組網(wǎng)或使用光纖直連方式的遠程組網(wǎng)較多，此場景并不多見，因此也應(yīng)用很少，其中FCIP已經(jīng)成為RFC，而iFCP止步于Draft。FCoE相比較來說對上層協(xié)議改動較少，開銷較低，且有利于減少服務(wù)器網(wǎng)絡(luò)接口數(shù)量，在傳統(tǒng)交換機廠商的大力鼓吹下當前發(fā)展最為迅猛，數(shù)據(jù)中心網(wǎng)絡(luò)畢竟會是交換機的天下。

5.5.2?FCoE

FCoE是在2007年INCITS(國際信息技術(shù)標準委員會)的T11委員會（和FC標準制定是同一組織）開始制定的標準，2009年6月標準完成（FC-BB-5）。FCoE基于FC模型而來，仍然使用FSPF和WWN/FC ID等FC的尋址與封裝技術(shù)，只是在外層新增加了FCoE報頭和Ethernet報頭封裝和相應(yīng)的尋址動作，可以理解為類似IP和Ethernet的關(guān)系。

FCoE標準定義了數(shù)據(jù)平面封裝與控制平面尋址兩個部分。封裝很好理解，大家看看下面這張圖就了然了。

尋址稍微說一下，F(xiàn)CoE使用FIP（FCoE Initialization Protocol）進行初始化連接，F(xiàn)IP運行于VFPort和VNPort之間或VEPort之間，所謂的V就是前面介紹FC的接口角色中的名稱前面加了個Virtual。FIP在接口使能后一共做了三件事：

1、使用本地VLAN（如VLAN1）確認FCoE數(shù)據(jù)報文將要使用的VLAN ID。

2、和FCF建立連接。

3、FLOGI/FDISC（Discover Fabric Service Parameters，F(xiàn)C節(jié)點設(shè)備第一次向FC交換機注冊請求FC ID時使用FLOGI，后面再續(xù)約或請求其他FC ID時都使用FDISC）

FCF（Fibre Channel Forwarder）是FCoE里面重要的角色，可以是軟件或者芯片硬件實現(xiàn)，需要占用Domain ID，處理FCoE交換機中所有與FC相關(guān)的工作，如封裝解封裝和FLOGI等。

Enode是指網(wǎng)絡(luò)中所有以FCoE形式轉(zhuǎn)發(fā)報文的節(jié)點設(shè)備，可以是服務(wù)器CAN網(wǎng)卡、FCoE交換機和支持FCoE的存儲設(shè)備。FCoE外層封裝的Ethernet報頭中MAC地址在Enode間是逐跳的，而FC ID才是端到端的。（不好理解就琢磨下IP/Ethernet轉(zhuǎn)發(fā)模型，將Enode想成路由器和主機，一樣一樣滴）

?

與三層交換機中的VLAN接口一樣，每個FCF都會有自己的MAC，由于FC ID是FCF分配給Enode的，繼承下來的終端Enode MAC也是由FCF分配的并具有唯一性，這個地址叫做FPMA（Fabric Provided MAC Address）。FPMA由兩部分組成，F(xiàn)C-MAP與FC ID，結(jié)構(gòu)如下所示，這樣當FCoE交換機收到此報文后可以根據(jù)FC-MAP判斷出是FC報文，直接送給FCF，F(xiàn)CF再根據(jù)FC ID查表轉(zhuǎn)發(fā)，處理起來更簡單。

由上面FC-MAP的定義也可以看出，每個FCF下聯(lián)的Enode終端最多也就255個（00-FF）。

DCB

由于Ethernet是沖突丟包的，為了保證FCoE的無丟包，IEEE引入了一系列的無丟包以太網(wǎng)技術(shù)（Lossless Ethernet），都定義在802.1Q DCB（Data Centre Bridging）標準系列中。DCB等同于DCE（Data Centre Ethernet）和CEE（Converged Enhanced Ethernet）的含義，就是不同廠商和工作組的不同稱謂，內(nèi)容都是一致的。DCB是IEEE為了在數(shù)據(jù)中心對傳統(tǒng)以太網(wǎng)技術(shù)進行擴展而制定的系列標準，前面說過的VM接入技術(shù)標準中802.1Qbg和802.1Qbh都是DCB中的一部分，另外還有802.1Qau CN（Congestion Notification），802.1Qaz ETS（Enhanced Transmission Selection）和802.1Qbb PFC（Priority-based flow control）。其中802.1Qau CN定義了擁塞通知過程，只能緩解擁塞情況下的丟包，加上其必須要全局統(tǒng)一部署與FCoE逐跳轉(zhuǎn)發(fā)的結(jié)構(gòu)不符，因此不被算成無丟包以太網(wǎng)技術(shù)的必要組成部分。常見的無丟包技術(shù)主要是PFC和ETS，另外還有個DCBX（Data Center Bridging Exchange Protocol）技術(shù)，DCBX也是一起定義在802.1Qaz ETS標準中。

PFC對802.3中規(guī)定的以太網(wǎng)Pause機制進行了增強，提供一種基于隊列的無丟包技術(shù)，實際達到的效果和FC的BB Credits一樣。簡單理解如下圖所示。

ETS是帶寬管理技術(shù)，可以在多種以太網(wǎng)流量共存情況下進行共享帶寬的處理，對FCoE的流量報文進行帶寬保障。簡單理解如下圖所示。

DCBX定義了通過LLDP在兩個相鄰Enode之間進行PFC, ETS等參數(shù)自協(xié)商交互的過程。

DCB的幾個標準目前都還處于Draft階段，其中PFC是由Cisco的Claudio DeSanti主編，ETS由Qlogic的Craig Carlson主編。

CNA

再補充一句服務(wù)器上的FCoE網(wǎng)卡CNA（Converged Network Adapter），這個東西就是萬兆Ethernet和FC HBA（Host Bus Adapter）網(wǎng)卡的合體，里面包含兩個獨立芯片處理Ethernet和FC各自的流量，在操作系統(tǒng)上看到的就是兩個獨立的Ethernet和FC網(wǎng)絡(luò)接口，其上再增加第三個芯片進行流量混合封包處理?？蓞⒖枷旅鎯蓮垐D示。

FCoE的技術(shù)要點就這么多了，需要記住的關(guān)鍵是，F(xiàn)CoE標準提供的是服務(wù)器到存儲設(shè)備端到端的網(wǎng)絡(luò)連接模型，F(xiàn)CF是FCoE交換機的關(guān)鍵特性。目前已經(jīng)有支持FCoE的存儲設(shè)備出現(xiàn)，估計服務(wù)器到存儲的全FCoE商用項目組網(wǎng)也很快就會在市場上出現(xiàn)。

5.5.3?NPV

目前市面上80%以上的標榜自己實現(xiàn)了FCoE的交換機產(chǎn)品其實都是只實現(xiàn)了NPV功能，和前面描述的FCoE標準內(nèi)容沾不上多少邊兒。那么NPV是啥呢？

先說NPIV（NPort ID Virtualization），這個還是FC里面的概念。前面說了Server的NPort需要向FC Switch進行FLOGI注冊獲取FC ID進行路由，那么如果一臺物理服務(wù)器里面搞了好多虛擬機后，每個VM都打算弄個FC ID獨立通信，但只有一塊FC HBA網(wǎng)卡咋辦呢。FC中通過NPIV解決了這種使用場景需求，可以給一個NPort分配多個FC ID，配合多個pWWN（private WWN）來進行區(qū)分安全控制。

理解了NPIV就好說NPV了，我們把上圖中的NPort拿出來作為個獨立設(shè)備給后面服務(wù)器代理進行FC ID注冊就是NPV（NPort Virtualization）了。NPV要做的兩件事：

1、自己先通過FLOGI向FC Switch注冊去要個FC ID

2、將后續(xù)Server過來的FLOGI請求代理成FDISC請求，向FC Switch再去申請更多的FC ID

NPV的好處是可以不需要Domain ID（每個FC區(qū)域最多只有255個），同時能將FC交換機下聯(lián)服務(wù)器規(guī)模擴大。NPV在FC網(wǎng)絡(luò)中最常見的應(yīng)用是在刀片交換機上。

隨之有人將FCoE的腦筋動到了NPV與服務(wù)器之間的網(wǎng)絡(luò)上，如下圖所示：

在FCoE中的NPV相比較FC中要多做三件事，參考前面FIP流程：

1、回應(yīng)節(jié)點設(shè)備關(guān)于FCoE承載VLAN的請求

2、回應(yīng)節(jié)點設(shè)備的FCF查找請求，根據(jù)自己初始化時從FC Switch得到的FC ID生成仿冒FCF使用的MAC地址

3、在CNA網(wǎng)卡和FC Switch之間對轉(zhuǎn)發(fā)的數(shù)據(jù)報文進行FCoE頭的封包解包。

NPV不是FCoE標準中定義的元素，因此各個廠家在一些細節(jié)上實現(xiàn)起來都各玩各的。比如都是將連接服務(wù)器的Ethernet接口和連接FC Switch的FC接口綁定起來使用，但是對應(yīng)的綁定規(guī)則就可能不同。再有如FC接口故障時，如何將服務(wù)器對應(yīng)的通道切換到其他FC接口去，是否通知服務(wù)器變化重新進行FLOGI注冊，及通知等待時長等設(shè)定都會有所區(qū)別。

說說NPV的好處，首先是實現(xiàn)容易，之前描述的那幾件主要的任務(wù)現(xiàn)在都已經(jīng)有公共芯片可以直接搞定，所以包裝盒子就是了。其次是部署簡單，不需要實現(xiàn)FCF，不用管FC轉(zhuǎn)發(fā)，不計算FSPF，不占Domain ID。最后是擴展方便，使用FC Switch的少量接口就可以連接大量的服務(wù)器。

由于NPV與服務(wù)器之間網(wǎng)絡(luò)為傳統(tǒng)以太網(wǎng)，因此NPV交換機也必須支持DCB標準中相關(guān)的無丟包以太網(wǎng)技術(shù)。

嚴格來講，NPV交換機不是FCoE標準中定義的FCoE交換機，但可以在接入層交換機上實現(xiàn)與服務(wù)器之間的Ethernet網(wǎng)絡(luò)復用，減少了服務(wù)器的物理網(wǎng)卡數(shù)量（并未減少操作系統(tǒng)層面的網(wǎng)絡(luò)通道數(shù)量），擴展了FC網(wǎng)絡(luò)接入服務(wù)器節(jié)點的規(guī)模，適用于云計算大規(guī)模服務(wù)器部署應(yīng)用。

補充一個ENPV（Ethernet NPV）的概念，這個東東是Cisco提的，就是在服務(wù)器與FCoE交換機（FCF）之間串個NPV進去，還是做些代理的工作，可以對FIP進行Snooping，監(jiān)控FIP注冊過程，獲取VLAN/FC ID/WWN等信息，對過路流量做些安全控制啥的。這種東東存在既有理，但以后有沒有搞頭就不好說了，市場是檢驗技術(shù)的唯一標準。

5.5.4?小結(jié)

FCoE是端到端的，F(xiàn)CF是不可少的，NPV是干代理的，目前是最合適的。

個人覺得NPV這個東西真的很彪悍，設(shè)計一套FCoE標準雖然是技術(shù)含量很高的活兒，但第一個搞出來NPV的才是真正的人精。如果沒有NPV，F(xiàn)CoE想從FC口里奪食難度至少會增加上百倍，沒準兒就跟iSCSI一樣落得個雞肋的地步。強烈建議FCoE標準盡快將NPV搞進來，要不單獨出個FC-BB-7/8啥的獨立標準體系也不錯。

隨著互聯(lián)網(wǎng)的發(fā)展，對網(wǎng)絡(luò)最大的需求就是帶寬增長，云計算更是如此，因此如果FC的帶寬演進繼續(xù)這么不緊不慢的話，勢必會被100G Ethernet取代，至于時間點就要看帶寬需求增速了，個人估計不會超過10年，到時就有FCoE的用武之地了，至于之前這段時間應(yīng)該都還是NPV在前面沖鋒陷陣。

繼續(xù)大膽YY，可否搞個什么技術(shù)沖擊下FCoE呢？由于IP是無連接的，Ethernet是沖突丟包的，因此想保證數(shù)據(jù)傳輸?shù)目煽啃跃椭荒芟駃SCSI一樣在TCP上做文章，但是層次做高了，報頭一多開銷又太大，矛盾啊矛盾。如果完全替代Ethernet，那就類似于重建一套FC協(xié)議了，但是目前也看不到帶寬速率發(fā)展能超過Ethernet的替代技術(shù)。那么中間手段就是搞下IP這個層面，像FCoE的思路可以理解為用SCSI/FCP替代TCP/IP在Ethernet上傳輸，由于SCSI/FCP這套協(xié)議和Ethernet已經(jīng)很成熟了，只是搞個接口（FCoE報頭）在中間承上啟下就夠了。不過FCoE需要引入無丟包以太網(wǎng)的設(shè)計，Pause幀會不會降低Ethernet的轉(zhuǎn)發(fā)效率還不好說。作者思路是設(shè)計一套帶連接狀態(tài)的傳輸機制（類似TCP帶重傳確認，而且可以像IP/FC一樣能夠?qū)ぶ罚┨娲鶬P/FCP這個層面，上面還是承載SCSI，下面跑著傳統(tǒng)以太網(wǎng)。不見得靠譜，僅供拓展一下思路，有興趣的同學可深思。

5.6?跨核心層服務(wù)器二層互訪

本章節(jié)重點技術(shù)名詞：L2MP/ VSS/IRF/ vPC/ TRILL/SPB/FabricPath/QFabric/VDC/VPN

在服務(wù)器跨核心層二層互訪模型中，核心層與接入層設(shè)備有兩個問題是必須要解決的，一是拓撲無環(huán)路，二是多路徑轉(zhuǎn)發(fā)。但在傳統(tǒng)Ethernet轉(zhuǎn)發(fā)中只有使用STP才能確保無環(huán)，但STP導致了多路徑冗余中部分路徑被阻塞浪費帶寬，給整網(wǎng)轉(zhuǎn)發(fā)能力帶來了瓶頸。因此云計算中需要新的技術(shù)在避免環(huán)路的基礎(chǔ)上提升多路徑帶寬利用率，這是推動下面這些新技術(shù)產(chǎn)生的根本原因。

前面網(wǎng)絡(luò)虛擬化章節(jié)部分提到了兩個解決上述需求的思路。

首先是控制平面多虛一，將核心層虛擬為一個邏輯設(shè)備，通過鏈路聚合使此邏輯設(shè)備與每個接入層物理或邏輯節(jié)點設(shè)備均只有一條邏輯鏈路連接，將整個網(wǎng)絡(luò)邏輯拓撲形成無環(huán)的樹狀連接結(jié)構(gòu)，從而滿足無環(huán)與多路徑轉(zhuǎn)發(fā)的需求。這種思路的代表技術(shù)就是VSS/IRF/vPC，前兩者都是控制平面全功能同步的整機虛擬化技術(shù)，vPC則是精簡后只處理控制平面與跨設(shè)備鏈路聚合使用相關(guān)功能的多虛一技術(shù)。此類技術(shù)必定都是私有技術(shù)，誰家的控制平面都不可能拿出來完全開放。

另一個思路是數(shù)據(jù)平面多虛一，在接入層與核心層交換機引入外層封裝標識和動態(tài)尋址協(xié)議來解決L2MP（Layer2 MultiPath）需求，可以理解這個思路相當于在Ethernet外面搞出一套類似IP+OSPF的協(xié)議機制來。對接入層以下設(shè)備來說，整個接入層與核心層交換機虛擬成了一臺邏輯的框式交換機，Ethernet報文進Ethernet報文出，中間系統(tǒng)就是個黑盒，就好像IP層面用不著了解到Ethernet是怎么轉(zhuǎn)發(fā)處理的一樣。這種思路的代表技術(shù)是IETF（Internet Engineering Task Force）標準組織提出的TRILL和IEEE提出的802.1aq SPB兩套標準，以及一些廠商的私有技術(shù)。如FabricPath是Cisco對TRILL做了一些變更擴展后的私有技術(shù)稱謂（以前也有叫E-TRILL），QFabric則是Juniper的私有技術(shù)，推測是基于MACinMAC封裝和自己搞的私有尋址協(xié)議來做的。

這里嘮叨兩句私有協(xié)議，從有網(wǎng)絡(luò)那天開始，私有協(xié)議就始終相生相隨。從早期的EIGRP和HSRP到現(xiàn)在的VSS/IRF/vPC/OTV/QFabric都是各廠家的私貨。即使是標準還有IETF/IEEE等不同的標準化組織呢，哪會有廠家就大公無私到研究出個啥東西都恨不得全人類共享，逐利才是企業(yè)發(fā)展的根本。私有協(xié)議還有兩個有趣的現(xiàn)象，首先單從技術(shù)角度來說，私有協(xié)議基本都代表了同時代同類技術(shù)的最先進生產(chǎn)力，如果是個落后的技術(shù)，只有腦袋進水了才會砸錢進去研發(fā)。還有就是只有在市場上占了一定地位的重量級廠商才會經(jīng)常推自己的私有協(xié)議，而且推得越多也代表著其地位越高。

從市場上看，最早由于沒得選，大家基本上都能接受使用私有協(xié)議，后來出于不想將所有雞蛋放在一個籃子里的心理，開始對私有協(xié)議有了抵觸情緒，尤其是運營商級別用戶明確要求不能使用私有協(xié)議。但就目前隨著云計算的爆炸式增長，數(shù)據(jù)中心網(wǎng)絡(luò)技術(shù)面臨著一次新的飛躍，傳統(tǒng)技術(shù)已經(jīng)無法滿足需求，因此私有協(xié)議再次進入了人們的視線。預計隨后幾年中，新的云計算數(shù)據(jù)中心會以站點Site為單位來部署單一廠商設(shè)備，如可以看到全Cisco設(shè)備運行FabricPath/vPC的Site，全Juniper設(shè)備QFabric的Site，或全H3C設(shè)備運行IRF的Site等等，站點之間或?qū)ν庠俨捎靡恍┕袇f(xié)議如MSTP、RPR、BGP等進行連接。

下面會分別介紹幾項主要技術(shù)，順序為控制平面多虛一技術(shù)VSS/IRF/vPC，數(shù)據(jù)平面多虛一技術(shù)TRILL/SPB/Fabric Path/QFabric和控制平面一虛多技術(shù)VDC。

5.6.1?控制平面多虛一技術(shù)

VSS/IRF

先說下VSS/IRF，這兩個技術(shù)基本上沒有啥差別。VSS（Virtual Switching System）是只在Cisco 6500系列交換機上實現(xiàn)的私有技術(shù)，IRF（Intelligent Resilient Framework）是在H3C所有數(shù)據(jù)中心交換機中實現(xiàn)的私有技術(shù)。二者的關(guān)鍵技術(shù)點如下：

1、專用鏈路跑私有協(xié)議：VSS使用VSL（Virtual Switch Link），IRF使用IRF link來承載各自的控制平面私有交互協(xié)議VSLP和IRF。專用鏈路使用私有協(xié)議來初始化建立鄰接、協(xié)商主備（描繪拓撲）、同步協(xié)議狀態(tài)，同時會在虛擬化完成后，傳輸跨機框轉(zhuǎn)發(fā)的數(shù)據(jù)流量。二者都推薦使用10GE鏈路捆綁來做專用鏈路，說明私有協(xié)議交互和跨框傳輸?shù)牧髁繒艽蟆?

2、基于引擎的主備模式：二者的控制平面都是只有一塊主控引擎做為虛擬交換機的主控制引擎，其他的引擎都是備份。所有的協(xié)議學習，表項同步等工作都是由這一塊引擎獨立完成。好在這些設(shè)備大都是分布式交換，數(shù)據(jù)轉(zhuǎn)發(fā)的工作由交換板自己完成了，只要不是類似OSPF鄰居太多，拓撲太大等應(yīng)用情況，一塊主控大部分也都能搞定了。注意Cisco 6500必須使用Supervisor720主控配合帶轉(zhuǎn)發(fā)芯片的接口板才能支持VSS。

3、跨設(shè)備鏈路聚合：前面說了網(wǎng)絡(luò)虛擬化主要是應(yīng)對二層多路徑環(huán)境下防止環(huán)路，因此跨設(shè)備鏈路聚合就是必須的了。Cisco配合VSS的專用技術(shù)名詞是MEC（Multichassis EtherChannel），IRF倒是沒有啥專門的名詞，其鏈路聚合也和單設(shè)備上配置沒有區(qū)別。

4、雙活檢測處理：當VSL或IRF link故障后，組成虛擬化的兩個物理設(shè)備由于配置完全相同會在網(wǎng)絡(luò)中出現(xiàn)雙活節(jié)點，對上下游設(shè)備造成IP網(wǎng)關(guān)混亂。因此VSS/IRF都設(shè)計了一些雙活處理機制以應(yīng)對專用鏈路故障。

1）首先網(wǎng)絡(luò)中如果有跨設(shè)備鏈路聚合時，VSS使用PAgP、IRF使用LACP擴展報文來互相檢測通知；2）如果有富裕接口在虛擬化的兩臺物理設(shè)備間可以單獨再拉根直連線路專門用做監(jiān)控，VSS使用VSLP Fast Hello、IRF使用BFD機制進行檢測通知；3）另外VSS還可以使用IP BFD通過互聯(lián)的三層鏈路進行監(jiān)控，IRF則支持使用免費ARP通過二層鏈路進行監(jiān)控。上述幾種方式都是監(jiān)控報文傳輸?shù)逆溌坊蛘咄鈱映休d協(xié)議不同。當發(fā)現(xiàn)專用鏈路故障時，VSS/IRF操作結(jié)果目前都是會將處于備份狀態(tài)的物理機框設(shè)備的所有接口全部關(guān)閉，直到專用鏈路恢復時再重新協(xié)商。需要注意這兩種虛擬化技術(shù)在進行初始協(xié)商時都需要將角色為備份的機框設(shè)備進行重啟才能完成虛擬化部署。下面以Cisco VSS的三種故障檢測方式舉例，IRF也差不多。

除了上述4個關(guān)鍵技術(shù)點外，VSS/IRF還有一些小的相似技術(shù)設(shè)定，如Domain的設(shè)定、版本一致性檢查、三層虛接口MAC協(xié)商等等，都是基于方方面面的細節(jié)需求來的。由于應(yīng)用環(huán)境相似，因此實現(xiàn)的東西也區(qū)別不大。想想RFC中的OSPF和BGP到現(xiàn)在都還在不斷的推出新的補充標準和Draft來查漏補缺，就知道細節(jié)的重要性了。

VSS特色一些的地方是結(jié)合了Cisco 6500的NSF（None Stop Forwarding）和SSO進行了主控板故障冗余和版本升級方面的可靠性增強。而IRF則是將虛擬化延伸到了H3C接入層設(shè)備5800系列盒式交換機上（最大支持8或9臺物理設(shè)備虛擬化為一臺邏輯設(shè)備），可以打造逐層虛擬化的數(shù)據(jù)中心網(wǎng)絡(luò)。

VSS和IRF都是當前較為成熟的虛擬化技術(shù)，其優(yōu)點是可以簡化組網(wǎng)，便捷管理，缺點則是擴展性有限，大量的協(xié)議狀態(tài)同步工作消耗系統(tǒng)資源，而且純主備的工作方式也導致了主控引擎的資源浪費。

?

vPC

Cisco在其新一代的數(shù)據(jù)中心交換機Nexus7000和5000系列中摒棄掉VSS，推出了vPC（virtual Port-Channel）特性。簡單一些理解，VSS/IRF是整機級別的虛擬化，vPC是接口級別的虛擬化，而且從名稱就可以看出是只支持鏈路聚合的虛擬化技術(shù)。從下圖的vPC結(jié)構(gòu)上就能看出，vPC和VSS從技術(shù)體系構(gòu)成上其實沒有大的區(qū)別。

其中Peer-Link對應(yīng)VSL，Peer-Keepalive Link對應(yīng)前面做雙活檢測的VSLP Fast Hello鏈路，CFS Protocol對應(yīng)VSLP。在vPC中只需要對成員接口進行鏈路聚合相關(guān)的信息同步即可，不需要對整機的所有協(xié)議進行狀態(tài)同步，大大減少了資源消耗和交互協(xié)議的復雜度。但是因為其控制平面機制與VSS一樣要協(xié)商出主備角色，并由唯一的Master來管理vPC接口組，因此在擴展性方面同樣被限制得很死，無法大規(guī)模進行部署，所以與VSS/IRF一同被歸類為控制平面多虛一技術(shù)。

另外vPC由于其只關(guān)注了二層鏈路聚合，因此在組網(wǎng)設(shè)計上無法離開HSRP/VRRP等多網(wǎng)關(guān)冗余協(xié)議或OSPF等多路徑路由協(xié)議，需要在路由層面獨立部署。從Cisco放出的vPC技術(shù)膠片就能看到，畫了一堆組網(wǎng)限制和注意事項，部署起來比VSS/IRF要更加復雜。

另外Arista的MLAG（Multi-Chassis Link Aggregation）技術(shù)和vPC很相似，學習時可以借鑒參考。

小結(jié)

控制平面多虛一技術(shù)總的來說比較成熟，VSS/IRF都已經(jīng)有了不少商用案例，vPC雖然協(xié)議簡單，但由于配合L3部署起來太復雜，應(yīng)用案例還不是很多。此類技術(shù)最大的缺點就是受主控引擎性能影響導致部署規(guī)模受限，當前規(guī)模最大的是H3C 12518兩臺物理交換機進行IRF虛擬化后，用一塊主控板管理支撐36塊接口板處理數(shù)據(jù)，而VSS最多的是Cisco 6513兩臺交換機虛擬化后共管理22塊接口板。目前VSS/IRF/vPC在市場上宣傳部署的都是只支持兩臺機框進行虛擬化，還沒有見到誰家的設(shè)備放出來支持4臺機框虛擬化的版本做商用推廣。估計得等到能夠支撐上百塊接口板的Super Supervisor出現(xiàn)，或者更完善的算法以提供多主控負載均擔，才能打破當下控制平面的多虛一規(guī)模限制了。

從Cisco Nexus系列產(chǎn)品的技術(shù)發(fā)展來看，在網(wǎng)絡(luò)虛擬化的路線上Cisco已經(jīng)開始偏向于數(shù)據(jù)平面虛擬化的TRILL等新興網(wǎng)絡(luò)技術(shù)，VSS/vPC等技術(shù)受主控引擎性能影響的部署規(guī)模局限性和協(xié)議私有化特征是制約其發(fā)展的硬傷，終將逐漸淡出大家的視線。

5.6.2?數(shù)據(jù)平面多虛一技術(shù)

數(shù)據(jù)平面多虛一技術(shù)的統(tǒng)一特征就是在二層Ethernet報文外面再封裝一層標識用于尋址轉(zhuǎn)發(fā)，這樣基于外層標識就可以做些多路徑負載均衡和環(huán)路避免等處理工作了。TRILL/SPB都是屬于此列，QFabric目前開放出來的資料較少，猜測其應(yīng)該也使用了類似MACinMAC之類的方式在其網(wǎng)絡(luò)內(nèi)部傳輸報文。

TRILL

先說TRILL（TRansparent Interconnect of Lots of Links）和FabricPath。2010年3月時TRILL已經(jīng)提交了IETF RFC 5556規(guī)范（Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement），此RFC只是描述了TRILL要解決的問題以及應(yīng)用范圍，定義協(xié)議細節(jié)的文檔目前都還處于Draft階段，形成完整的協(xié)議標準體系應(yīng)該還得1-2年。

TRILL并不是專門為數(shù)據(jù)中心開發(fā)的技術(shù)，其定義的是在大型Ethernet網(wǎng)絡(luò)中解決多路徑問題的方案。FabricPath是Cisco在TRILL標準之上加入了很多私貨的專門為數(shù)據(jù)中心而設(shè)計的一個超集，基本的控制平面與數(shù)據(jù)平面二者沒有明顯區(qū)別。

控制平面上TRILL引入了L2 ISIS做為尋址協(xié)議，運行在所有的TRILL RB（Routing Bridge）之間，部署于一個可自定義的獨立協(xié)議VLAN內(nèi)，做的還是建立鄰接、繪制拓撲和傳遞Tag那幾件事。數(shù)據(jù)平面在內(nèi)外層Ethernet報頭之間引入了TRILL報頭，使用NickName作為轉(zhuǎn)發(fā)標識，用于報文在TRILL網(wǎng)絡(luò)中的尋址轉(zhuǎn)發(fā)（可理解為類似IP地址在IP網(wǎng)絡(luò)里面轉(zhuǎn)發(fā)時的作用）。每個RB都具有唯一的Nickname，同時維護其他RB的TRILL公共區(qū)域MAC地址、Nickname和私有區(qū)域內(nèi)部MAC地址的對應(yīng)關(guān)系表。因為TRILL封裝是MACinMAC方式，因此在TRILL公共區(qū)域數(shù)據(jù)報文可以經(jīng)過傳統(tǒng)Bridge和Hub依靠外部Ethernet報頭轉(zhuǎn)發(fā)。TRILL報頭格式如下圖所示：

V (Version): 2 bit，當前Draft定義為0。

R (Reserved): 2 bits，預留。

M (Multi-destination): 1 bit，0為已知單播，1為未知單播/組播/廣播，此時Egress RBridge Nickname意味著當前轉(zhuǎn)發(fā)使用多播樹的根。

Op-Length (Options Length): 5 bit，Option字段長度。

Hop Count: 6 bit，最大跳數(shù)，逐跳減一，為0丟棄，防止環(huán)路風暴。

Egress RBridge Nickname: 16 bit，已知單播標示目的私網(wǎng)MAC對應(yīng)的RB，多播則標示多播樹根RB。中間傳輸RB節(jié)點不能改變此字段值。

Ingress RBridge Nickname: 16 bit，標示報文進入TRILL區(qū)域的初始邊緣RB，中間傳輸RB節(jié)點不能改變此字段值。

Options:目前只定義了CHbH (Critical Hop by Hop)和CItE (Critical Ingress to Egress)兩個1bit的標志位，用于說明后面的Option預留內(nèi)容是需要逐跳設(shè)備識別處理的或是首末端設(shè)備必須識別處理的。至于真正的Option目前都還沒有定義。下圖為Option字段內(nèi)容：

普通Ethernet報文在首次從TRILL邊緣RB設(shè)備進入TRILL區(qū)域時，作為未知單播還是依照傳統(tǒng)以太網(wǎng)傳播方式，廣播給所有其他的RB節(jié)點。但是除了邊緣RB外，TRILL區(qū)域中間的RB和傳統(tǒng)Bridge都不會學習此數(shù)據(jù)報文中私有區(qū)域內(nèi)部MAC地址信息，有效的降低了中間設(shè)備的MAC地址表壓力。為了防止環(huán)路同時做到多路徑負載均衡，TRILL的每個RB在初始建立鄰接繪制拓撲時，都會構(gòu)造出多個多播樹，分別以不同的Nickname為根，將不同的未知單播/組播/廣播流量Hash到不同的樹，分發(fā)給其他所有RB。

由于全網(wǎng)拓撲唯一且構(gòu)造樹時采用的算法一致，可保證全網(wǎng)RB的組播/廣播樹一致。在RB發(fā)送報文時，通過將報文TRILL頭中的M標志位置1來標識此報文為多播，并填充樹根Nickname到目的Nickname字段，來確保沿途所有RB采用同一顆樹進行廣播。組播與廣播報文的轉(zhuǎn)發(fā)方式與未知單播相同。已知單播報文再發(fā)送的時候，會根據(jù)目的RB的Nickname進行尋路，如果RB間存在多條路徑時，會逐流進行Hash發(fā)送，以確保多路徑負載分擔。

另外TRILL除了支持外層Ethernet封裝在傳統(tǒng)以太網(wǎng)中傳輸外，還規(guī)定了一種外層PPP封裝方式可以跨廣域網(wǎng)技術(shù)傳輸。以下是兩種典型的TRILL報文封裝方式：

TRILL的主要技術(shù)結(jié)構(gòu)就是上面這些了，對更細節(jié)內(nèi)容感興趣的同學可以自行去IETF翻翻相關(guān)Draft。目前各個芯片廠商都已經(jīng)進入TRILL Ready的階段，只要技術(shù)標準完善發(fā)布并被廣泛客戶所接受，相關(guān)產(chǎn)品商用是So快的。

FabricPath

FabricPath是Cisco 2010年6月底正式發(fā)布的專門針對數(shù)據(jù)中心設(shè)計的私有技術(shù)，以前也叫做L2MP/E-TRILL，Cisco資料上的原話是：

The Cisco engineers who developed L2MP only pushed part of it to IETF TRILL.

Functionality-wise, L2MP is a superset of TRILL

L2MP = TRILL + Cisco extensions

控制平面和轉(zhuǎn)發(fā)規(guī)則上FabricPath和TRILL沒有大的區(qū)別，一些主要變化如下，也可以說這些是Cisco專門針對數(shù)據(jù)中心網(wǎng)絡(luò)對TRILL做出的變更：

1、FabricPath只支持RB間的點到點直連，不能加入傳統(tǒng)Bridge等設(shè)備。因此FabricPath的報文格式相比較TRILL就更加簡化，不再需要依靠外層的目的MAC進行Ethernet轉(zhuǎn)發(fā)，數(shù)據(jù)報文封裝有較大不同，F(xiàn)abricPath的報文格式如下圖所示。

其中的Switch ID就是TRILL里面的Nickname。TTL字段用于避免環(huán)路風暴

2、采用FTAG（Forwarding TAG）標示不同的多播樹Graph，用于多拓撲中未知單播/組播/廣播報文的轉(zhuǎn)發(fā)。多拓撲指可以在同一套FabricPath網(wǎng)絡(luò)中支持不同的拓撲轉(zhuǎn)發(fā)，而目前TRILL的多拓撲還未明確定義。每套拓撲缺省使用2個Graph，每個Graph可以用一個FTAG標示。目前NOS發(fā)布版本只開放支持2棵樹Graph，既一套拓撲，據(jù)稱最多可擴展至64棵樹。多拓撲結(jié)構(gòu)如下圖所示。

3、MAC基于會話進行學習。當FabricPath的邊緣設(shè)備從FabricPath區(qū)域中收到報文進行MAC地址學習時，會進行目的MAC地址檢查，只有目的MAC在本地私有區(qū)域存在的，才會學習報文的源MAC到地址表中，這樣可以避免MAC的不必要擴散。TRILL中RB設(shè)備還是傳統(tǒng)的Ethernet方式，收到報文就會學習源MAC，不做判斷。

4、FabricPath支持基于vPC、FHRP等Cisco私有協(xié)議的組合應(yīng)用擴展。

在當前TRILL還未有完整明確的標準出臺情況下，Cisco已經(jīng)用FabricPath走在了所有人前面，可以支持云計算大規(guī)模節(jié)點二層通信的數(shù)據(jù)中心建設(shè)，當然其主要的被攻擊點就是私有協(xié)議。另外在Cisco的發(fā)布資料中也指出，其產(chǎn)品均已進入TRILL Ready狀態(tài)，以后只需要命令變更就可以切換設(shè)備分別運行于純粹的TRILL和擴展的FabricPath模式下。

SPB

要說SPB需要先談?wù)凱BB。PBB（Provider Backbone Bridging）是IEEE于2008年完成的802.1ah標準，為運營商城域以太網(wǎng)定義了一整套MACinMAC的轉(zhuǎn)發(fā)機制。但PBB只定義了轉(zhuǎn)發(fā)平面的封裝內(nèi)容，當報文封裝上外層Ethernet報頭在運營商骨干區(qū)域二層網(wǎng)絡(luò)中時，仍然需要依靠傳統(tǒng)的STP進行環(huán)路避免和轉(zhuǎn)發(fā)控制。于是IEEE在2009年又定義了802.1Qay PBB-TE（Provider Backbone Bridge Traffic Engineering），用于在運營商的骨干區(qū)域中進行拓撲管理與環(huán)路保護，說白了就是通過手工方式配置一堆指定路徑取代STP的自動收斂。目前IEEE還有個相關(guān)的標準P802.1Qbf, PBB-TE infrastructure protection處于草案階段，預計2011年發(fā)布。

PBB-TE靜態(tài)規(guī)劃轉(zhuǎn)發(fā)路徑，明顯無法適用于大型二層網(wǎng)絡(luò)擴展，于是IEEE再搞出個 P802.1aq SPB（Shortest Path Bridging）來，當前也還處于草案階段。從IEEE的資料上看SPB主要是為了解決STP阻塞鏈路浪費帶寬的問題而研究出來的。從實現(xiàn)上來看，同樣是采用了L2 ISIS作為其控制平面協(xié)議進行拓撲學習計算，用MACinMAC封裝方式在SPB區(qū)域內(nèi)部進行報文傳輸。和TRILL很像吧，好在IEEE和IETF都是開放的標準化組織，不存在專利之爭，不然肯定要掐架了。

SPB可細分為SPBV（VLAN QinQ）和SPBM（MACinMAC）兩個部分，目前看主要用到的是SPBM。

SPBM是標準的MACinMAC封裝，在SPB區(qū)域中數(shù)據(jù)報文也都是依靠外層MAC做傳統(tǒng)Ethernet轉(zhuǎn)發(fā)。外層Ethernet報頭中的源目的MAC就代表了SPB區(qū)域邊緣的UNI設(shè)備，此設(shè)備MAC是由L2 ISIS在SPB區(qū)域中傳遞的。

由于在SPB網(wǎng)絡(luò)中還是采用傳統(tǒng)Ethernet進行轉(zhuǎn)發(fā)，因此需要定義一系列的軟件算法以保證多路徑的廣播無環(huán)和單播負載均衡。下面介紹幾個主要的部分：

1、首先SPB定義了I-SID來區(qū)分多個拓撲，I-SID信息在數(shù)據(jù)報文中以BVID（外層Ethernet報頭中的VLAN Tag）形式攜帶，這樣可以解決不同業(yè)務(wù)多拓撲轉(zhuǎn)發(fā)的問題。

2、每個SPB節(jié)點都會為每個I-SID計算三棵樹：到達所有相關(guān)UNI節(jié)點的SPT（Shortest Path Tree）用于單播與組播報文的轉(zhuǎn)發(fā)；ECT（Equal Cost Tree）以處理兩個UNI間存在多條等價路徑時負載均衡轉(zhuǎn)發(fā)；自己為根的多播樹MT（Multicast Tree）用于未知單播與廣播報文轉(zhuǎn)發(fā)。

3、任意兩點間的Shortest Path一定是對稱的；ECT的負載均衡是基于不同I-SID分擔的；

總的來說，SPB和TRILL/FabricPath相比主要有以下不同：

SPB目前的最大困擾是轉(zhuǎn)發(fā)路徑靠軟件算法保障，尤其在多路徑負載分擔時，對CPU計算壓力遠遠超過TRILL和FabricPath，因此實際轉(zhuǎn)發(fā)效率令人存疑。而且SPB的出發(fā)點是運營商的城域以太網(wǎng)環(huán)境應(yīng)用，是否能適用于數(shù)據(jù)中心網(wǎng)絡(luò)還有待觀察。當前802.1aq SPB已經(jīng)進入到Draft4.0，對其細節(jié)有興趣的同學可以去IEEE網(wǎng)站注冊下載學習。

多說一句，SPB是純軟件的解決方案，不需要更新轉(zhuǎn)發(fā)芯片去支持，因此只要其標準化后，任何廠家都可以很快推出支持的版本，包括Cisco。

QFabric

Juniper的QFabric也是目前喊得很大聲的數(shù)據(jù)中心下一代網(wǎng)絡(luò)技術(shù)，但由于還沒有正式發(fā)布，開放的技術(shù)原理性文檔基本沒有，大都是些市場方面的資料。個人理解有以下幾個要點：

1、首先控制平面一定是Juniper的私有協(xié)議，肯定要全J設(shè)備建設(shè)才成

2、由于J是自己沒有芯片研發(fā)能力的，因此采購的基本只能是Broadcom/Marvel等幾家通用芯片廠商的片子，再因此其轉(zhuǎn)發(fā)肯定是基于MACinMAC的標準報文封裝方式。

3、由1和2可以推斷其實現(xiàn)方式應(yīng)該是轉(zhuǎn)發(fā)平面公共化，控制平面私有化。

4、從其如下的結(jié)構(gòu)圖中可以看出，對于虛擬后的邏輯交換機，可以理解Director、Interconnect和Nodes應(yīng)該分別對應(yīng)一臺框式交換機的主控引擎、交換網(wǎng)板和接口板。

目前Juniper只發(fā)布了Nodes節(jié)點的QFX3500設(shè)備，等Interconnect和Director都出來估計怎么也得2012了。

小結(jié)

TRILL/FabricPath/SPB/QFabric都引入了控制平面協(xié)議來處理拓撲管理和轉(zhuǎn)發(fā)路徑判定的工作，都肯定會導致轉(zhuǎn)發(fā)效率上，相比較傳統(tǒng)Ethernet的下降，同時引入拓撲變化影響流量路徑變更收斂速度的問題。但是這些技術(shù)畢竟比以前的STP在帶寬上多了一倍的擴充，組網(wǎng)規(guī)模上也得到擴展，更適用于云計算數(shù)據(jù)中心的網(wǎng)絡(luò)需求，總體來講得大于失，屬于更先進的生產(chǎn)力。

從開放標準上講，個人傾向于IETF的TRILL。畢竟SPB出身不正，定位于運營商城域互聯(lián)應(yīng)用，而且就連IEEE都沒有將其放入DCB（DataCenter Bridging）的大技術(shù)體系中。

從私有技術(shù)來看，VSS/IRF受到組網(wǎng)規(guī)模有限的硬傷限制，隨著云計算網(wǎng)絡(luò)規(guī)模的增大會逐漸退出大型數(shù)據(jù)中心的舞臺，但用戶服務(wù)器規(guī)模也不是說上就能上來的，至少還能有2、3年的賺頭。而FabricPath/QFabric會較前者有更寬廣的舞臺和更長久的生存期，但由于其私有化的特征，當開放標準成熟鋪開后，部署規(guī)模也只會日漸萎縮?？梢韵胂隣SPF和EIGRP的昨天和今天。

下面說些個人極度主觀的預測（每寫到這里都有些神棍的感覺）：

1、未來2-3年投入使用的云計算數(shù)據(jù)中心將是FabricPath/IRF/QFabric這些私有技術(shù)亂戰(zhàn)的天下。在舊有開放技術(shù)不能滿足使用，而新的標準仍未完善的情況下，私有技術(shù)成了人們唯一的選擇。（VSS由于基于Cisco6500系列產(chǎn)品，受設(shè)備性能影響1-2年內(nèi)會完全退出數(shù)據(jù)中心的歷史舞臺）

2、未來5年左右大型數(shù)據(jù)中心網(wǎng)絡(luò)將會是TRILL一統(tǒng)天下，SPB半死不活，而各種私有技術(shù)也會延續(xù)之前的一部分市場，但很難得到進一步普及和推廣。

最后完全依據(jù)個人喜好將上述技術(shù)做個排位，僅供參考，請勿拍磚。

FabricPath > TRILL > QFabric > IRF/VSS > SPB

5.6.3?控制平面一虛多技術(shù)

這個目前就是VDC了，沒有看到任何廠家有類似的技術(shù)出來，另外由于此技術(shù)完全是本地有效的使用范圍，也不會存在什么標準化的互通問題，就算有人去提個標準大家也不會理睬的，可以參考VMware ESX/XEN/HyperV之間的關(guān)系。

VDC（Virtual Device Contexts）是Cisco基于操作系統(tǒng)級別的一虛多網(wǎng)絡(luò)虛擬化技術(shù)。下面列表用于展示幾項主要網(wǎng)絡(luò)一虛多技術(shù)的區(qū)別。

從下圖的NXOS模型和VDC模型，可以看出VDC是建立在底層OS之上的，因此推測其采用的應(yīng)該是前文中提到的OS-Level虛擬化技術(shù)。

現(xiàn)階段Cisco公布的軟件規(guī)格為每物理設(shè)備最多虛擬4個VDC，并支持每VDC 4k VLANs和200 VRFs進行分層次虛擬化部署。按照云計算的需求來看，一般給每個用戶分配的都是以帶寬為度量的網(wǎng)絡(luò)資源，不會以交換機為單位進行虛擬網(wǎng)絡(luò)資源非配。即使是給的話，一臺N7000只能虛擬4個VDC也不夠用戶分的。如果純粹的流量隔離需求，最多使用到VRF也就夠了，再多層次的虛擬化目前還看不清使用場景需求。

舉個類似的例子，分層QoS一段時間以來也很火爆，但個人認為分2層也好，分10層也好，業(yè)務(wù)用不上都是白搭，當然在不考慮具體應(yīng)用情況，純粹拼指標時還是很有用的。又回到了前面的老話，正確的網(wǎng)絡(luò)設(shè)計原則永遠是自頂向下的。

VDC可說的東西就這么多了，更多的就涉及到NXOS的核心設(shè)計了，Cisco也不太可能會向外公布。從Cisco的行業(yè)地位來看，未來的1-2年左右，其他各個設(shè)備廠商相應(yīng)的私有技術(shù)都會隨之跟進。也許實現(xiàn)手段和市場宣傳各有春秋，但就技術(shù)使用和用戶體驗來說不會有多大差別。

再簡單聊兩句VLAN和VPN這兩個熟透了的一虛多技術(shù)。VLAN好理解，就是在Ethernet報頭中加個Tag字段，多了個層次區(qū)分，將Ethernet層面數(shù)據(jù)報文劃分從一維轉(zhuǎn)成二維，瞬間規(guī)模就大了N倍，隨之也使Ethernet的復雜度大大增加。VPN就稍微復雜些了，誰讓當初IP設(shè)計時候沒有考慮預留其他Tag標識字段這塊呢。

VPN（Virtual Private Network）分為本地有效的VRF（Virtual Routing and Forwarding，也有說是VPN Routing and Forwarding）和用于跨設(shè)備的MPLS VPN兩個部分。VRF就是將本地的路由表、轉(zhuǎn)發(fā)表和三層接口都給個VPN Tag，統(tǒng)一做IP層面的路由轉(zhuǎn)發(fā)處理。例如從屬于VPN A的接口進入設(shè)備的報文，只能查VPN A的路由表和轉(zhuǎn)發(fā)表，從VPN A的其他接口轉(zhuǎn)發(fā)出設(shè)備。當然后來又根據(jù)需求設(shè)計了一些跨VPN互訪的技術(shù)，就不多說了。由于每個VPN都要維護自己的路由轉(zhuǎn)發(fā)表，因此需要將各個路由協(xié)議RIP/OSPF/ISIS/BGP等都通過VPN標識隔離出多個數(shù)據(jù)庫進程用于分開構(gòu)造各自的路由表。這個也沒啥難的，不管是數(shù)據(jù)報文還是協(xié)議報文都是基于接口出入設(shè)備的，因此只要將不同接口綁定到不同的VPN中，就可以做到IP路由層面的隔離了。而且這個VRF都是本地有效，各個廠家做的小有區(qū)別也不會相互影響。

跨設(shè)備轉(zhuǎn)發(fā)時就麻煩了。首先得設(shè)計個Tag來讓所有設(shè)備統(tǒng)一VPN Tag，于是有了MPLS Label；再就得讓數(shù)據(jù)報文傳輸過程中帶著這個Label四處游走，于是有了MPLS報頭；還得讓全體設(shè)備能夠統(tǒng)一MPLS報頭中Label對應(yīng)本地VPN及IP路由的關(guān)系，于是有了LDP/BGP VPNv4等專用和擴展協(xié)議用于傳遞Label。繼續(xù)通過萬能圖解釋VPN跨設(shè)備轉(zhuǎn)發(fā)。

大的體系有了，還得補充細節(jié)。MPLS報頭在IP報頭外面，而且字段又少，只能多裹層頭，分層標識不同PE設(shè)備和PE設(shè)備上的不同VPN（公網(wǎng)Label與私網(wǎng)Label）；規(guī)模大了，不同區(qū)域的Label無法互相識別，于是要想辦法VPN跨域；三層IP報文搞定了又想在VPN里面?zhèn)鞫覧thernet報文，于是有了VLL/VPLS。。。

有興趣的同學可以去IETF統(tǒng)計下VPN跨設(shè)備轉(zhuǎn)發(fā)相關(guān)的RFC，個人是實在數(shù)不過來了，到今天都還有各種相關(guān)Draft不斷地推陳出新，排隊審核呢。

5.6.4?小結(jié)

數(shù)據(jù)中心內(nèi)部的服務(wù)器互訪技術(shù)介紹到這里就告一段落了，無論是前面的服務(wù)器跨接入層互訪還是后面的跨核心層互訪模型，都對網(wǎng)絡(luò)虛擬化提出了嚴峻的要求?？梢哉f在后面的云計算數(shù)據(jù)中心建設(shè)中，非虛擬化的網(wǎng)絡(luò)將很快的被擠出市場舞臺。未來10年的大型數(shù)據(jù)中心網(wǎng)絡(luò)是屬于網(wǎng)絡(luò)虛擬化的，從技術(shù)層面，目前只能看到一個獨領(lǐng)風騷的前行者。

PS：聲明一下，作者不是唯Cisco派的，是唯技術(shù)派的。

5.7?數(shù)據(jù)中心跨站點二層網(wǎng)絡(luò)

本章節(jié)重點技術(shù)名詞：RPR/ VLL/VPLS/A-VPLS/GRE/L2TPv3/OTV

前面說了，數(shù)據(jù)中心跨站點二層網(wǎng)絡(luò)的需求來源主要是集中云時的多站點服務(wù)器集群計算和分散云時的虛擬機vMotion遷移變更。搭建二層網(wǎng)絡(luò)時，依據(jù)中間網(wǎng)絡(luò)的承載方式不同，主要分為光纖直連、MPLS核心和IP核心三類。這里的多站點一般指3個及3個以上，只搞兩個站點的云計算喊出去會比較掉價。

5.7.1?光纖直連

兩個站點就不多說了，直接在兩個站點的核心或匯聚設(shè)備之間拉兩根光纖就OK了，也用不到什么特別的技術(shù)。唯一需要注意的是在兩個站點之間的鏈路上做些報文控制，對廣播和STP等報文限制一下發(fā)送速率和發(fā)送范圍，避免一個站點的廣播風暴或拓撲收斂影響到其他站點的轉(zhuǎn)發(fā)。

當站點較多時，理論上有兩種結(jié)構(gòu)可用：

星形結(jié)構(gòu)：專門找?guī)着_設(shè)備作為交換核心，所有站點都通過光纖直連到此組交換核心設(shè)備上，缺點是可靠性較低，核心掛掉就都連不通了，而且交換核心放置的位置也不易規(guī)劃。這種結(jié)構(gòu)不是值得推薦的模型。

環(huán)形結(jié)構(gòu)：推薦模型，尤其在云計算這種多站點等同地位互聯(lián)的大型數(shù)據(jù)中心組網(wǎng)下，環(huán)形結(jié)構(gòu)既省設(shè)備省錢，又能提供故障保護，以后肯定會成為建設(shè)趨勢。

從技術(shù)上講星形拓撲不需要額外的二層互聯(lián)技術(shù)，只部署一些報文過濾即可，可以通過鏈路捆綁增強站點到核心間鏈路故障保護和鏈路帶寬擴展。而環(huán)形拓撲必須增加專門的協(xié)議用于防止環(huán)路風暴，同樣可以部署鏈路捆綁以增加帶寬冗余。

環(huán)形拓撲的公共標準控制協(xié)議主要是STP和RPR（Resilient Packet Ring IEEE802.17），STP的缺點前面說了很多，RPR更適合數(shù)據(jù)中心多站點連接的環(huán)形拓撲。另外很多廠商開發(fā)了私有協(xié)議用于環(huán)路拓撲的控制，如EAPS（Ethernet Automatic Protection Switching，IETF RFC 3619，Extreme Networks），RRPP（Rapid Ring Protection Protocol，H3C），MRP（Metro Ring Protocol，F(xiàn)oundry Networks），MMRP（Multi Mater Ring Protocol，Hitachi Cable），ERP（Ethernet Ring Protection，Siemens AG）等。

這里簡單介紹一下RPR。從控制平面看，環(huán)路拓撲組網(wǎng)相對簡單，控制協(xié)議交互規(guī)則制定也比較前面的TRILL/SPB更加簡化，了解了全網(wǎng)各節(jié)點位置后，確定內(nèi)外環(huán)兩條通路即可。在數(shù)據(jù)平面上，RPR通過MACinMAC方式在環(huán)上封裝外層節(jié)點MAC信息方式確認已知單播傳遞節(jié)點對象，非目標節(jié)點會將數(shù)據(jù)報文直接轉(zhuǎn)給環(huán)上的下一跳，只有當目標節(jié)點收到此報文后根據(jù)外層目的MAC信息確認本地為終點，將報文下環(huán)轉(zhuǎn)發(fā)。環(huán)上每個節(jié)點都會對未知單播/組播/廣播報文著做下環(huán)復制和逐跳轉(zhuǎn)發(fā)處理，直到轉(zhuǎn)了一圈后，源節(jié)點再次收到此報文丟棄終止轉(zhuǎn)發(fā)。

由于RPR在環(huán)路傳輸數(shù)據(jù)報文封裝時增加了1個Byte的基本環(huán)控制和1個Byte的擴展環(huán)控制用于環(huán)路信息識別，因此也必須使用專用硬件處理環(huán)路接口的報文收發(fā)封裝工作。RPR雖然很早就確立了標準內(nèi)容，但由于其初始應(yīng)用針對運營商城域以太網(wǎng)，且只能支持環(huán)路拓撲，因此各個廠商并沒有花太大力氣去開發(fā)產(chǎn)品進行支撐推廣，當前使用不多。

就作者看來，未來幾年的云計算數(shù)據(jù)中心建設(shè)時，除非在所有站點采用相同廠家的設(shè)備還有可能使用一些私有協(xié)議組環(huán)（可能性比較低），前文提到預測會以站點為單位選擇不同廠家進行建設(shè)，這時就需要公共標準用于多站點互聯(lián)了。在光纖直連方式下成熟技術(shù)中最好的選擇就是RPR，但如果TRILL能夠?qū)⒍嗤負溥@塊內(nèi)容定義好，未來是能夠?qū)⑵淙《摹?

5.7.2?MPLS核心網(wǎng)

一些大型的行業(yè)企業(yè)（如政府軍工）自建內(nèi)部網(wǎng)絡(luò)時，會使用MPLS技術(shù)搭建各個地方的互聯(lián)核心網(wǎng)。此時可以將各地的數(shù)據(jù)中心站點復用MPLS核心網(wǎng)進行跨地域連接，省錢才是王道。在自建的MPLS核心網(wǎng)中，需要在各個站點的PE設(shè)備間搭建VPLS隧道用于傳輸Ethernet報文。如果是租用運營商的VPLS隧道則不需要考慮這么多，那時PE是由運營商提供的，對用戶來說組網(wǎng)部署和前面的光纖直連沒有區(qū)別。

VLL

如果是只有兩個站點互聯(lián)的情況，可以使用VLL（Virtual Leased Line）。VLL是一種點到點的虛擬邏輯鏈路技術(shù)，數(shù)據(jù)報文從隧道入口入，只能從定義好的另外一端出口出，不存在多個隧道終點一說。數(shù)據(jù)平面沒啥可說的，A點收到的二層報文進隧道直接封裝上MPLS報頭發(fā)給B點就OK了，整個過程框架可參考前面的MPLS轉(zhuǎn)發(fā)圖?？刂破矫嬗捎谒淼蓝际屈c到點連接方式，不需要復雜尋址，只要在數(shù)據(jù)流量傳輸時，給VPN分配外層封裝的對應(yīng)Label即可。分配方式有以下四種：

CCC（Circuit Cross Connect）：全網(wǎng)靜態(tài)為VPN分配一個Label，包括所有路徑的PE和P設(shè)備都需要手工配置。此Draft已經(jīng)處于Dead狀態(tài)，目前基本也沒人用了。

SVC（Static Virtual Circuit）：只在PE上靜態(tài)配置私網(wǎng)VPN的Label，公網(wǎng)標簽不管。有用的但也不多，靜態(tài)配置這種方式對故障處理總是心有余而力不足的。

Martini：RFC4762，使用LDP協(xié)議在PE間建立連接，為VPN動態(tài)分配Label，省事好用。

Kompella：RFC4761，使用BGP協(xié)議在PE間建立連接，使用BGP VPNv4擴展字段攜帶VPN對應(yīng)Label信息進行傳遞，這個實現(xiàn)起來比Martini復雜一點點，用得也就少了一些些。

后面兩種Martini和Kompella方式在MPLS L3 VPN和VPLS里面也都有應(yīng)用，都是作為控制協(xié)議來為VPN分配和傳遞Label用的。

VPLS

當存在多個站點時，A站點收到的二層報文就有個選B還是選C進行轉(zhuǎn)發(fā)的問題。于是有了VPLS（Virtual Private Lan Service）。VPLS是支持點到多點的虛擬鏈路技術(shù)，從隧道入口進入后，可以根據(jù)VPLS MAC地址表從多個隧道出口中去選擇正確的出口，或者廣播給所有出口。控制平面還是通過Martini和Kompella兩種方式分配與傳遞VPN對應(yīng)的Label。數(shù)據(jù)平面則要多維護一張VPN的MAC對應(yīng)VC（Virtual Circuit）轉(zhuǎn)發(fā)表，既前面提到的VPLS MAC地址表，本地接口收到的報文，MAC地址學習方式還是和傳統(tǒng)Ethernet一樣；只有當報文從遠端PE過來時，記錄的源MAC需對應(yīng)遠端PE的VC ID。

由于VPLS透傳的是二層Ethernet報文，就涉及到VLAN標識處理的問題。VPLS可以配合QinQ技術(shù)，將用戶側(cè)發(fā)來的帶VLAN標簽報文打上外層VLAN標簽，以擴展VLAN數(shù)量規(guī)模。當然現(xiàn)在的交換機一般都是最大支持4k的VLAN，大部分場景都是夠用的了，還沒有聽說誰家的數(shù)據(jù)中心VLAN部署超過4k。但云計算服務(wù)器節(jié)點數(shù)量規(guī)模成倍增加以后就不好說了，留出冗余總是好的。

為了防止廣播風暴，VPLS做了水平分割特性，PE設(shè)備從遠端PE收到的廣播/未知單播報文只能發(fā)給本地的CE，不能轉(zhuǎn)發(fā)給其他PE。還有其他的分層PE和Hub-Spoke等技術(shù)在數(shù)據(jù)中心多站點互聯(lián)環(huán)境中一時還應(yīng)用不上，這里也就不過多介紹了。

VPLS技術(shù)已經(jīng)很完善了，喜歡細節(jié)的同學可以去查下RFC相關(guān)文檔。這里再說下其在數(shù)據(jù)中心多站點互聯(lián)應(yīng)用中的不足之處。數(shù)據(jù)中心要求的是全冗余，無單點故障點或單點故障鏈路，而VPLS在雙PE冗余方面沒有專門的定義，因此造成技術(shù)上的使用不便，一是會形成如下圖所示的跨站點二層環(huán)路，二是本端CE無法感知對端CE-PE間鏈路狀態(tài)情況，故障時導致流量黑洞問題。

解決上述問題有以下兩個思路：

首先是使用萬能的STP構(gòu)建出整網(wǎng)拓撲，即可避免環(huán)路，還可檢測故障切換。缺點和前面在其他地方使用時一樣，浪費帶寬與收斂速度慢，另外就是要讓STP跨站點組網(wǎng)，會導致一個站點出現(xiàn)問題，其他站點全部受影響。此方案的好處就是公共標準大家都能做，而且不存在互通問題。

其次是使用控制平面多虛一技術(shù)，如VSS/IRF和vPC，使多個物理節(jié)點變?yōu)槲ㄒ坏倪壿嫻?jié)點將整個拓撲由環(huán)狀變?yōu)殒湢睿员苊猸h(huán)路。同時通過鏈路檢測監(jiān)控聯(lián)動路徑切換動作以避免流量黑洞問題，如Cisco的EEM。這些小技術(shù)組合起來可以解決上述問題，但缺點是都是私有技術(shù)，沒有統(tǒng)一標準，無法支持不同廠商產(chǎn)品混合組網(wǎng)。

另外可以一提的是Cisco的私有技術(shù)A-VPLS（Advanced VPLS），此技術(shù)配合其VSS，可以將多條VPLS的PW（Pseudo Wire，可理解等同于VC）虛擬化為一條邏輯的Fat PW，達到多PW路徑負載分擔的效果，和鏈路聚合很類似。如下圖所示。

此技術(shù)由于需要往MPLS報頭中添加一個Flow Label的標簽字段，用于處理多PW的流量路徑Hash，因此別的廠家設(shè)備肯定無法識別，只能在全Cisco設(shè)備環(huán)境下部署。其他廠商也有開發(fā)出類似的技術(shù)，對多PW進行流量負載分擔，但也都是私有的小特性，無法互通組網(wǎng)。估計再有1-2年IETF可以搞出個多PW負載分擔的標準來，到時大家就好做了。

5.7.3?IP核心網(wǎng)

全球最大的公共IP核心網(wǎng)就是Internet了，只要解決了報文加密的安全問題，且Internet出口帶寬足夠大，誰說以后的數(shù)據(jù)中心站點間二層互聯(lián)不能走Internet呢。另外也有很多大企業(yè)的核心網(wǎng)采用IP建網(wǎng)，國內(nèi)的如金融電力，國外則遍地開花。

從技術(shù)上來看，公共的技術(shù)標準主要有VLLoGRE/VPLSoGRE和L2TPv3，私有技術(shù)就是Cisco的OTV了。VLLoGRE/VPLSoGRE沒啥好說的，就是在IP層打通個GRE隧道，再把Ethernet報文扔到隧道里面?zhèn)?。下面主要說說L2TPv3和OTV。

L2TPv3

L2TP（Layer 2 Tunneling Protocol）是IETF RFC2661（L2TPv2）定義的，已經(jīng)有不少年頭了，主要應(yīng)用于移動辦公通過Internet進行VPN接入等場景。L2TPv2的標準封裝是基于PPP格式的，后來為了進行應(yīng)用擴展，推出了L2TPv3，RFC3931。L2TPv3可以封裝在IP/UDP層之上，擺脫了PPP的束縛。

LAC（L2TP Access Concentrator）是L2TP的角色名稱，作為IP隧道的起終點，另外還有個LNS（L2TP Network Server）角色，但在數(shù)據(jù)中心多站點互聯(lián)場景中應(yīng)用不到，這里就不做介紹了?？梢院唵卫斫釲AC等同于VPLS的PE。

從控制平面看，L2TPv3使用自己的控制協(xié)議報文建立IP隧道，由于隧道都是點到點的，也不存在什么拓撲學習的問題，這點和VLL相同。數(shù)據(jù)平面就是進隧道封包轉(zhuǎn)發(fā)了，封裝時只需在原始L2報文和外層IP頭之間插入一個L2TPv3報頭即可，里面包含SessionID和Cookie字段，其中SessionID字段32Bit ，Cookie字段可選，最長64Bit，整個L2TPv3報頭最大12Byte，要大于前面那兩個oGRE的了。整體結(jié)構(gòu)可參考下面Cisco膠片的截圖。但是注意里面雖然畫了3個PE，但是實際上L2TPv3和VLL一樣只能支持點到點的傳輸，如果CE3上也有VLAN50想和CE1/CE2一起組成二層網(wǎng)絡(luò)L2TPv3是搞不定的。這個圖有那么點兒混淆概念的意思。其中的Control和L2-specialfic sublayer字段在數(shù)據(jù)中心互聯(lián)場景中就是指Ethernet報頭，而在其他場景中也可以使用PPP等其他二層鏈路協(xié)議報頭，畢竟L2TP定義的是要承載所有L2數(shù)據(jù)報文。

L2TPv3是RFC標準，誰家都能用，但只能像VLL一樣支持兩站點互通的場景，因此使用并不廣泛，當前也就看到Cisco有在小范圍推廣。VPLSoGRE還是大部分廠商在多中心互聯(lián)中主推的技術(shù)。順便一提，L2TPv3只解決跨IP封裝傳輸?shù)膯栴}，對于前面提到的多PE和流量黑洞的問題并沒有對應(yīng)方案，還是得配合VSS/IRF和探測處理等私有技術(shù)才能適用于數(shù)據(jù)中心。

OTV

前面說了，在IP核心網(wǎng)情況下，公共標準只有使用VPLSoGRE才能支持多站點的二層互聯(lián)，而VPLSoGRE同樣存在前面VPLS組網(wǎng)中的多PE連接和流量黑洞問題，需要配合其他一系列的私有技術(shù)才能一并解決，部署起來相當繁瑣，而且真出了問題定位也很困難。公共標準在這種場景下不是不能用，而是不好用，只能看私有技術(shù)了。

Cisco在其新一代數(shù)據(jù)中心交換機Nexus 7000中推出了OTV（Overlay Transport Virtualization）私有技術(shù)來專門處理數(shù)據(jù)中心多站點二層互聯(lián)使用場景。數(shù)據(jù)平面OTV以MACinIP方式封裝原始Ethernet報文，報文結(jié)構(gòu)如下：

可以看到對比VPLSoGRE只是將8字節(jié)GRE頭替換成OTV標識，長度沒有變化。因此轉(zhuǎn)發(fā)效率估計和VPLSoGRE相當。

控制平面上，OTV有組播與單播兩種方式建立鄰接拓撲，組播方式適用于支持組播的IP核心網(wǎng)，個人覺得還是很少見的。單播方式需要設(shè)置一臺AS（Adjacency Server），保存所有的鄰接設(shè)備信息列表oAL（overlay Adjacency List）。所有OTV節(jié)點需要手工設(shè)定此AS地址，上線時去取得其他鄰居節(jié)點信息以建立鄰接。當然還可以配置備份AS節(jié)點避免單點故障。OTV單播鄰接建立方式如下截圖所示。

針對數(shù)據(jù)中心多站點互聯(lián)的場景，OTV設(shè)計了一系列的機制處理。

1、STP隔離。將STP BPDU報文在OTV邊緣設(shè)備ED（Edge Device）上進行阻塞，禁止其跨站點傳播。

2、未知單播隔離。將未知單播數(shù)據(jù)報文在ED上進行阻塞，禁止跨站點廣播。同時可以手工配置靜態(tài)MAC地址對應(yīng)遠端OTV接口的表項，以應(yīng)對部分靜默主機應(yīng)用場景。

3、ARP控制。對遠端站點返回的ARP Reply報文進行Snoop和Cache，當再收到本地查詢同樣目的IP的ARP Request時直接代答，不向其他OTV站點擴散，減少跨站點的ARP Request廣播。

4、MAC地址學習控制。由于未知單播報文被隔離了，因此需要通過OTV協(xié)議報文進行站點間的MAC地址學習同步。過程如下圖所示?？缯军c的廣播報文的MAC地址學習規(guī)則仍然與傳統(tǒng)Ethernet相同，而且OTV不會對其做特殊控制。廣播報文限速這種功能現(xiàn)在基本是個交換機就能支持了，算不上特色技術(shù)。

5、站點ED雙機冗余?？梢栽谝粋€站點使用多臺ED接入OTV核心網(wǎng)，前提是要保證多ED在站點內(nèi)部可以二層互通。運行控制協(xié)議進行AED（Authoritative Edge Device）設(shè)備的選舉，只有AED可以轉(zhuǎn)發(fā)和接收廣播/組播報文，以避免環(huán)路風暴。如下截圖所示。

另外可以在多個ED間基于VLAN進行不同的AED選舉，達到全局意義上的流量轉(zhuǎn)發(fā)負載均衡。如下截圖所示。

6、HSRP隔離。不管二層技術(shù)再怎么搞，除非采用VSS/IRF等私有技術(shù)去做控制平面整體虛擬化，否則網(wǎng)關(guān)冗余在數(shù)據(jù)中心里面都是必不可少的。而當多個站點二層通信時，也必然存在網(wǎng)關(guān)部署位置的選擇問題。如果站點A的主機每次和外界通信都走站點B的網(wǎng)關(guān)，則會導致大量的非必要流量途徑站點間二層互聯(lián)鏈路，浪費帶寬且路途繞遠。Cisco提出了更好的處理方式，OTV在ED上通過過濾HSRP HELLO報文，將HSRP進行站點間隔離，這樣各個站點的網(wǎng)關(guān)相同，但各自為政，上下行流量路徑最優(yōu)。

OTV的主要內(nèi)容差不多就這些了。從技術(shù)上來講，其細節(jié)考慮最全面，而且瞄準的市場是所有站點間IP可達的應(yīng)用場景，既OTV同樣可以部署在光纖直連和MPLS核心網(wǎng)的場景中，遠遠領(lǐng)先于其他的數(shù)據(jù)中心多站點互聯(lián)技術(shù)方案，但由于其私有協(xié)議的地位和可能的性能瓶頸，在市場上最終能占到多大地盤還有待觀察。這里有兩點猜測：

1、OTV如果今年仍在米國拿不下專利，估計明年就該去IETF提Draft了。米國的專利還是很嚴格的，這種繼承性居多的技術(shù)審查通過不易。再想想國內(nèi)的一些相關(guān)領(lǐng)域技術(shù)專利，都是神馬的浮云。

2、未來的一兩年間，其他各個瞄準數(shù)據(jù)中心的設(shè)備廠商類似（用仿字不好聽）OTV的私有技術(shù)將會如雨后春筍般發(fā)布出來。

5.7.4?小結(jié)

數(shù)據(jù)中心跨站點二層互聯(lián)目前還是個比較新的需求，實際上馬的項目并不多，以前大多是滿足存儲需求的光纖直通。但大潮已經(jīng)漲起來了，國內(nèi)的各大運營商紛紛啟動測試，國外估計也有一些項目應(yīng)用。各個廠商最好盡快做好弄潮的準備，不然很快就會被淹沒的。

從各個角度分析，個人認為上述三種互聯(lián)方式中還是光纖直連最靠譜。

首先從省錢角度來看，建得起數(shù)據(jù)中心多站點的就不會差那幾個錢拉不起光纖，如果使用CWDM/DWDM等波分復用設(shè)備可以在一對光纖上建多個通道供存儲和不同業(yè)務(wù)共享使用，總帶寬最高可以上T，性價比不見得比租用和復用MPLS/IP核心網(wǎng)絡(luò)要低。

其次從重要性角度來說，需要跨站點運算的應(yīng)用程序肯定是以企業(yè)關(guān)鍵業(yè)務(wù)為主，給關(guān)鍵業(yè)務(wù)拉根專線，不去和其他業(yè)務(wù)攪合，也是可靠性設(shè)計的必要需求。

最后從當前可使用技術(shù)的角度考慮，VLL/VPLS的數(shù)據(jù)報文查表封裝處理工作，新一些的轉(zhuǎn)發(fā)芯片可以搞定，但L2TPv3/GRE/OTV一般的轉(zhuǎn)發(fā)芯片肯定是搞不定的，這樣就需要額外的CPU或NP去處理數(shù)據(jù)報文，性能上自然也不會有什么太好的期待，萬兆線速都是奢求。而且不管是怎么封裝，傳輸?shù)臅r候外面一堆報頭都很損耗帶寬，列舉個極限的例子，OTV和VPLSoGRE外層報頭要封42Byte，對64Byte載荷的數(shù)據(jù)小包，報頭帶寬損耗達到了42/(42+64)=40%，一條10G鏈路，跑滿了才能用6G傳數(shù)據(jù)，效率那是相當?shù)牡桶　?

而光纖直連方式目前主要技術(shù)瓶頸在多站點互聯(lián)時，缺少專業(yè)高效的公共標準技術(shù)，RPR如果想在數(shù)據(jù)中心有所作為，還需要進行一些協(xié)議上的標準改進，多考慮一些如未知單播/廣播數(shù)據(jù)報文和STP/ARP/VRRP等協(xié)議報文的數(shù)據(jù)中心場景專門處理，以及站點多邊緣設(shè)備冗余接入應(yīng)用場景處理。另外各個廠商對相關(guān)產(chǎn)品的高調(diào)發(fā)布和大力市場推廣也是必不可少的。個人覺得在數(shù)據(jù)中心多站點互聯(lián)這塊，私有技術(shù)早期也許能忽悠住一些用戶，但最終肯定是站不住腳的。

5.8?數(shù)據(jù)中心多站點選擇

本章節(jié)重點技術(shù)名詞：SLB/GSLB/LISP

數(shù)據(jù)中心多站點建設(shè)時考慮應(yīng)用服務(wù)冗余，則必然面臨著以下問題：1）Client訪問Server的時候選A站點還是B站點；2）A站點的Server故障或服務(wù)遷移到B站點后，Client訪問如何能隨之快速切換。

前面已經(jīng)提到，在選路技術(shù)中主要有兩個解決方案思路，一是DNS，二是路由。

DNS方案的缺點首先是應(yīng)用擴展性不強。DNS協(xié)議以處理HTTP/HTTPS的應(yīng)用為主，其他類型應(yīng)用較少。不過話說回來，目前的應(yīng)用中基于WEB的BS（Browser-Server）結(jié)構(gòu)快打遍天下無敵手了，這個問題倒也影響不大。還有個問題就是DNS自身協(xié)議設(shè)計時，沒有考慮多IP選擇問題，所以此類解決方案都要和主機探測、遷移同步等私有技術(shù)配合起來使用，一般都得好幾個盒子聯(lián)動起來才行。DNS的好處是簡單，使用的技術(shù)都是成熟技術(shù)，準備好接口寫兩行代碼誰都能分上一杯羹，只要操心優(yōu)化處理性能方面即可。目前的典型技術(shù)代表就是GSLB+SLB（可選）+vMotion通知（可選），下面會進行詳細介紹。

路由的方案是完全基于IP技術(shù)出發(fā)，網(wǎng)絡(luò)設(shè)備廠商自己就能搞定，不需要找DNS或vMotion去聯(lián)動。其中的主備中心的路由掩碼比明細和主機路由發(fā)布兩種方案都不是啥好招，屬于拆了東墻補西墻，會造成其他的問題。而稍微完整一點兒的LISP目前也還是試驗探索階段，vMotion后主動路由刷新這個最主要需求，也沒能得到太好的解決。下文會簡單介紹LISP，并探討更優(yōu)的處理方案。

5.8.1?GSLB

GSLB（Global Server Load Balance）全局負載均衡技術(shù)，這個貌似是Redware先提出來的叫法，其他各個廠家叫法都有區(qū)別，如F5的3DNS和Cisco的GSS等。作者覺得這個詞更貼切而且技術(shù)性普適一些，就按這個名詞進行技術(shù)介紹，從原理上講和3DNS/GSS什么的沒有啥大的區(qū)別。

GSLB就是一臺DNS解析服務(wù)器。最主要功能就是對不同Client發(fā)往相同域名服務(wù)的請求，以一定算法規(guī)則進行Hash，回應(yīng)不同Server IP地址。常見的算法包括輪詢（90%都用的）、最少連接數(shù)和服務(wù)器最快響應(yīng)速度等。增強功能是可以對Server IP進行探測，如果探測到某臺Server故障，則會使用其他正常的Server IP進行Client的DNS響應(yīng)。常見的探測方式有ICMP（90%都用的）、TCP以及上層應(yīng)用如FTP/HTTP等。當然也可以再搞些HTTP重定向等特性，將GSLB設(shè)備放在數(shù)據(jù)中心站點的入口便于故障快速切換。

在vMotion應(yīng)用場景中，由于VM在遷移前后的IP地址不變，因此兩個數(shù)據(jù)中心站點的VM對外提供服務(wù)的Server IP地址相同，GSLB此時就需要服務(wù)器前面的SLB（Server Load Balance）設(shè)備進行配合了。SLB是個NAT（Network Address Translation）服務(wù)器，主要作用就是將后端真實服務(wù)器的IP和TCP/UDP Port等映射為對外提供服務(wù)的虛擬IP和TCP/UDP Port，然后將不同Client訪問虛擬IP的流量修改目的IP后，分別發(fā)到后端的不同真實服務(wù)器上，以達到對后端多臺真實服務(wù)器的流量負載均擔效果。SLB同樣需要對真實服務(wù)器進行探測，以及根據(jù)不同的算法規(guī)則將Client流量均勻Hash到不同的真實服務(wù)器上。使用不同的SLB可以將后端相同的真實服務(wù)器IP映射為對外的不同虛IP地址，此時配合GSLB就可以解決vMotion前后VM服務(wù)IP相同的遷移切換問題。另外如VMware的VM管理控制平臺vCenter可以將vMotion動作通知GSLB設(shè)備，達到快速切換效果。下面以Cisco的技術(shù)結(jié)構(gòu)截圖舉例，其中的GSS就是GSLB，ACE為SLB。其他廠家的方案在技術(shù)結(jié)構(gòu)上也沒有啥根本區(qū)別。

說實話個人覺得GSLB技術(shù)沒有啥難度可言，DNS解析和調(diào)度算法都是現(xiàn)成的東東，稍微有點兒技術(shù)實力的廠商都能做個盒子出來。這個東西關(guān)鍵在于性能，由于DNS解析等上述功能行為都得靠CPU實現(xiàn)，沒有啥公用芯片，那么就看誰家的算法實現(xiàn)效率高，誰家支持的新建并發(fā)規(guī)格大。如果性能規(guī)格差不多，都能滿足需求，再要考慮的就是可靠性和性價比了。關(guān)于衡量數(shù)據(jù)中心性能和可靠性的問題，會在本文的相關(guān)外篇中再深入討論。

5.8.2?LISP

LISP（Locator/ID Separation Protocol）實質(zhì)是個IPinIP的協(xié)議，其主要思想早在15年前就已經(jīng)被人提出來進行研究，然而一直沒有太具體的東西產(chǎn)出。直到2006年，Cisco重新開始投入資源進行研究，目前已經(jīng)提交了很多的IETF Draft，最新版是今年4月份的Draft Version12。但就應(yīng)用來說。Cisco的LISP目前也只處于試驗階段，距離能夠推廣商用還有不短的時間，很多技術(shù)細節(jié)方面問題需要解決。

LISP的應(yīng)用結(jié)構(gòu)如下截圖所示：

LISP提出將標識Locator的IP（RLOC）和標識目的節(jié)點ID的IP（EID）進行區(qū)分和疊加封裝，在公網(wǎng)傳輸時只根據(jù)Locator IP轉(zhuǎn)發(fā)，只有到達站點邊緣時才會剝離外層IP，使用內(nèi)層標識EID的IP進行轉(zhuǎn)發(fā)。從下面的報文封裝截圖就可以看到其IPinIP的思想。

LISP有兩個主要的目標：一是公網(wǎng)設(shè)備不需要學習站點內(nèi)部明細IP路由項，可以有效減少公網(wǎng)的路由數(shù)目；二是當訪問的目標服務(wù)在站點間遷移時，可以只變更Locator的外層IP，不需要對服務(wù)節(jié)點的內(nèi)部IP地址進行變更，可以避免TCP等上層應(yīng)用的中斷重建，此點主要是應(yīng)用于數(shù)據(jù)中心vMotion和手機上網(wǎng)漫游的場景。

?

LISP的技術(shù)結(jié)構(gòu)如下截圖所示：

上圖的名詞很多，通過簡單描述整個數(shù)據(jù)轉(zhuǎn)發(fā)過程來幫助大家進行理解：

1、由源主機發(fā)往目的主機的數(shù)據(jù)報文第一次到達客戶區(qū)域的LISP邊界設(shè)備ITR。

2、ITR會根據(jù)報文的目的IP地址EID，向Directory區(qū)域的本地查詢服務(wù)器MR請求EID對應(yīng)的目的站點邊緣設(shè)備公網(wǎng)Locator IP。

3、MR會根據(jù)本地EID所屬路由網(wǎng)段與MS的對應(yīng)表項將查詢請求提交給數(shù)據(jù)服務(wù)器MS。

4、MS上擁有EID對應(yīng)目的站點邊緣設(shè)備ETR的對應(yīng)表項信息，MS會查表將此請求轉(zhuǎn)發(fā)給ETR。

5、ETR會根據(jù)自身設(shè)置的規(guī)則（如優(yōu)先級等）選擇站點的某個公網(wǎng)IP作為Locator IP反饋會ITR。

6、ITR會根據(jù)ETR回應(yīng)報文中的Locator IP封裝外層報頭將數(shù)據(jù)報文發(fā)到公網(wǎng)上，同時記錄此EID與Locator IP的臨時對應(yīng)表項，當再有去往此EID的數(shù)據(jù)報文流經(jīng)時直接封裝轉(zhuǎn)發(fā)。封裝轉(zhuǎn)發(fā)的過程如下截圖所示，也有些眼熟吧。

如果覺得1-5步的過程復雜不易理解，請回想一下DNS整套的域名解析過程，都是相通的。注意上述名稱都是技術(shù)角色，一臺設(shè)備可以實現(xiàn)多個LISP的角色功能，如同時實現(xiàn)ITR/ETR功能，或同時實現(xiàn)MR/MS功能等。

另外ALT是用于搭建MR和MS之間Directory區(qū)域互聯(lián)用的中間角色，通過BGP擴展報文為MR和MS之間傳遞路由信息；PITR和PETR是用于LISP與不支持LISP的網(wǎng)絡(luò)對接時做ITR和ETR代理用的角色。由于目前LISP也還沒有定稿，此部分設(shè)備功能沒有完整定義，有興趣的同學請自行深入研究。

LISP中各角色之間大都通過手工指定的方式建立連接關(guān)系，如ITR上需要指定MR地址， ETR上需要指定MS地址，只有MR和MS之間可通過BGP來建立鄰接關(guān)系并通過擴展報文傳遞EID表項信息，但目前實現(xiàn)出來的還是以手工指定方式為主。而且ETR上要將哪些EID信息發(fā)送到MS上，也同樣需要通過配置網(wǎng)段掩碼的方式手工進行指定。

LISP并不是專門為數(shù)據(jù)中心開發(fā)的技術(shù)，因而Cisco如果想將其在數(shù)據(jù)中心場景進行研究推廣，估計會進行一些協(xié)議改造使其更加適用于數(shù)據(jù)中心的場景需求。目前Cisco給出的LISP數(shù)據(jù)中心實現(xiàn)vMotion過程如下截圖所示：

上圖是能找到的里面相對描述最清楚的了，但說實話感覺還是很糙。個人理解如果希望LISP應(yīng)用于數(shù)據(jù)中心多站點選路，還需要解決以下一些技術(shù)問題：（下面這幾段讀起來可能會有些費勁，珍惜腦細胞的同學慎入）

1、遷移后服務(wù)器EID在新站點的ETR注冊問題。既VM遷移后，新站點的ETR如何知道它此時需要向外發(fā)布對應(yīng)EID。Cisco的當前做法是使用IP報文偵聽，先配置個偵聽范圍，既可能會遷移過來的IP地址段，當監(jiān)聽到本地出現(xiàn)此地址段為源IP地址的IP報文時，會激活此EID表項并發(fā)給MS進行注冊。個人感覺偵聽免費ARP會更方便一些，vMotion后VM肯定會發(fā)免費ARP報文的，但發(fā)IP報文就得看服務(wù)器的應(yīng)用層協(xié)議設(shè)置了。不過此方案需要在站點間過濾免費ARP，不能使其跨站點傳輸，否則二層隧道會將免費ARP擴散到所有站點，偵聽就沒意義了，而過濾后會不會有其他問題還需細琢磨。這里只隨口提個思路，什么方案都是有利就有弊的，需權(quán)衡清楚再實現(xiàn)。另外也可以讓vCenter等管理平臺去通知ETR，類似于前面的GSLB方案，這樣由必須和VMware等虛擬機廠商做強聯(lián)動，有些違背使用LISP的初衷。

2、遷移后通知ITR快速切換新的Locator IP問題。這個就更加復雜了，VM剛由站點A遷移到站點B，ITR不知道啊，還是在用舊的Locator IP封包發(fā)送，此時應(yīng)用業(yè)務(wù)肯定就斷了，直到ITR獲取到新的Locator IP后才能再建立起連接恢復業(yè)務(wù)。如果是時間敏感型的業(yè)務(wù)，中斷個幾分鐘，上下幾百萬就沒了不是。當前LISP提了很多解決方向出來，但還沒有什么確定的技術(shù)方案。個人思路如下，此問題需分解為兩個小問題各自解決：

首先是要解決ITR如何感知遷移發(fā)生的問題：1）管理平臺通知，需要聯(lián)動，而且ITR那么多，也不會都注冊到管理平臺上去。不太靠譜。2）由ITR探測EID存活狀態(tài)，探測范圍太大，EID可能以主機路由居多，對ITR負擔太重，可行但不是很好。3）由原始站點ETR探測EID狀態(tài)，當遷移后探測到EID不在本地站點，則通知ITR刪除臨時表項。ETR上是保存了所有ITR表項的，可以很方便知道都要通知誰。但由于各站點間服務(wù)器前端網(wǎng)絡(luò)二層互通，因此還要想辦法將此探測報文在站點間隔離，否則遷移前后始終都是通的，和前面的ARP偵聽方案存在相同的問題。4）在問題一已經(jīng)解決的情況下，當服務(wù)器EID在新站點的ETR注冊完成后，由新站點ETR向所有原始站點ETR發(fā)通知，再由原始站點ETR通知ITR刪除臨時表項。這個方案感覺相對更靠譜一些，可以將所有可能運行同組業(yè)務(wù)的數(shù)據(jù)中心站點ETR都設(shè)定到一個組里面，大家有事沒事互通有無一下。

再有要解決ITR感知遷移后如何切換EID對應(yīng)的Locator IP問題：1）使用上面幾種感知遷移發(fā)生的方法后，都可以將ITR的EID對應(yīng)Locator IP臨時表項刪除，由ITR重新發(fā)起一套EID的尋址流程獲取新的Locator IP，缺點是稍慢。2）在上面第4種解決方案中，原始ETR收到新ETR的通知后，向ITR發(fā)個EID變更信息告知新的ETR地址，由ITR向新的ETR直接發(fā)請求獲取新的Locator IP，不經(jīng)MR/MS倒騰一遍手了，這樣需要在LISP中多定義一個EID變更報文和相關(guān)處理流程。切換速度能提升些，但也稍微復雜了些。

提問題->找多個解決方案->比較不同方案的利弊，協(xié)議設(shè)計就是這么個過程。

LISP即使能夠成事，至少也得2年以后了，所以大家可以先看個熱鬧，等RFC標準立起來再介入也不遲。也許Cisco回頭覺著整這個太費勁，說不定哪天就偃旗息鼓了。別的廠商又真不見得有這么大號召力能把LISP忽悠起來。全當學著玩了，目前別拿LISP太當真。

另外多說一句LISP在Mobile里面的應(yīng)用場景，Cisco已經(jīng)今年5月份已經(jīng)向IETF提出了draft-meyer-lisp-mn-05，其中mn就是mobile node縮寫。簡單來說就是在手機上支持ITR/ETR功能，可參考下圖：

技術(shù)上很有想法，市場發(fā)展上不咋看好。感覺Cisco把手伸到手機里面，還不如前文提到的伸進服務(wù)器虛擬化里面有搞頭。

小結(jié)

小結(jié)一下，數(shù)據(jù)中心多站點選路目前網(wǎng)絡(luò)廠商單從路由角度來看沒有什么好的方案，還是用DNS搞定更靠譜一些，只要應(yīng)用程序的BS結(jié)構(gòu)始終領(lǐng)先前行，暫時就還不用考慮其他的解決方案。讓那些有錢有勢的大廠商去試驗吧，大家在后面跟進就是了。搞預研是有一定風險的行為，資源消耗了，萬一路沒選對，大廠商還能壯士斷腕，小廠商就得折腰而終了，須慎研慎行。

凡事都有兩面，換而言之，混亂的局面也是崛起的機會，如果誰能想到個啥招，搞個盒子出來，從路由或者其他層面獨立解決多站點選路的問題，還是可以一試的。大賺不好說，但搞到像F5/Redware/Citrix這種規(guī)模并不是沒得奔頭。

5.9?技術(shù)總結(jié)

對數(shù)據(jù)中心網(wǎng)絡(luò)而言，當前的技術(shù)發(fā)展正處于一個關(guān)鍵時期，雖然Cisco暫時占先，但只是通過技術(shù)的先進性增大了其市場話語引導能力，為其在今后10年的數(shù)據(jù)中心市場的競爭中增加了一些砝碼，絕不是說就一定會所向披靡。未來充滿變數(shù)，哪怕是什么時候Google或Tencent推出了應(yīng)用于云計算數(shù)據(jù)中心的網(wǎng)絡(luò)設(shè)備或技術(shù)，作者都完全不會感到吃驚，一切皆有可能。就像Arista這兩年橫空出世，徹底的取代了Force10在作者心中“傻快”的霸者地位，預計其在今后幾年的數(shù)據(jù)中心市場中勢必會有所斬獲，天下武功，唯快不破。

新技術(shù)是層出不窮的，前文介紹的這些技術(shù)只是作者知道的內(nèi)容，眼界有限，相信還有更多更先進的技術(shù)在此章介紹之外。期望通過本文能夠?qū)ψx者學習其他技術(shù)也有所幫助，萬事萬物有果必有因，透過紛亂的報頭字段、狀態(tài)機變化和報文交互等協(xié)議機制設(shè)計表象，去了解清楚技術(shù)產(chǎn)生的背景原因和要解決的問題，勢必在學習時可以達到事倍功半的效果。

用以下言語與技術(shù)同好共勉：在技術(shù)之路上，了解得越多，敬畏之心越重，但仍需不斷前行，即使無法成為引領(lǐng)者，也必將超越原地踏步者。

6、?終章

完了就是完了，其實沒啥好多說的，想說的要說的該說的前面都已經(jīng)說過了。文中做了不少預測，根據(jù)作者的惡趣味，最后在這里對那些神棍內(nèi)容再總結(jié)一下湊湊字數(shù)。

在未來5-10年間作者認為：

市場方面

1、云計算市場出現(xiàn)不了如Microsoft于操作系統(tǒng)、Google于網(wǎng)絡(luò)搜索或Cisco于數(shù)據(jù)通信的一家獨大局面，但對多虛一的集中云與一虛多的分散云，市場劃分會更加清晰，客戶抗忽悠能力也將得到大幅度提升。

2、解決了安全問題后，基于服務(wù)的SaaS會占據(jù)更多的業(yè)務(wù)租用市場，中小企業(yè)自身IT資源消耗進而降低，業(yè)務(wù)能力反而提升。例如同時租用Google云的數(shù)據(jù)管理，Amazon云的人力資源，Microsoft云的ERP，Cisco云的統(tǒng)一通信和作者云的客戶關(guān)系管理等系統(tǒng)來綜合搭建企業(yè)IT平臺，會成為很時髦很常見的思路。（想創(chuàng)業(yè)的抓緊，SaaS機會賊多的，而且初始投入規(guī)模并不需要太大）

3、提供云服務(wù)（以SaaS為主）的產(chǎn)業(yè)將如雨后春筍般出現(xiàn)，這些服務(wù)提供商將會搭建大量的數(shù)據(jù)中心為客戶提供云租用服務(wù)，也會成為網(wǎng)絡(luò)設(shè)備廠商們的衣食父母。需求較小的企業(yè)都去直接租用服務(wù)了，因此數(shù)據(jù)中心步入了大型與巨型為主的時代，動輒成千上萬的服務(wù)器節(jié)點絕對是小Case。數(shù)據(jù)中心產(chǎn)品的銷售也將隨之進入規(guī)?；少忞A段，搞定幾個大客戶，廠商一年下來就吃穿不愁了。

技術(shù)方面

1、VM之間互通技術(shù)之爭會以硬件交換機進入服務(wù)器內(nèi)部為最終結(jié)局，有可能是在網(wǎng)卡上實現(xiàn)，也有可能直接在主板上加轉(zhuǎn)發(fā)芯片。畢竟從現(xiàn)在發(fā)展情況來看，芯片價格會越來越便宜，集成度會越來越高。

2、存儲方面FCoE基于Ethernet帶寬發(fā)展方面的優(yōu)勢，必將取代FC，當然過程會是比較漫長的，估計10年之后FC也還能占有一定的空間。

3、數(shù)據(jù)中心站點內(nèi)部TRILL將會一統(tǒng)天下。巨型數(shù)據(jù)中心內(nèi)，基于IP層面的交互會導致傳輸效率降低和部署復雜度提升，因此仍然會以Ethernet技術(shù)為主，而TRILL是目前看得到的最有希望勝出的公共標準。各個廠商的私有技術(shù)會將在規(guī)模稍小一些的大中型數(shù)據(jù)中心內(nèi)有所應(yīng)用，比如前面說的SaaS創(chuàng)業(yè)企業(yè)，其可能會更看重網(wǎng)絡(luò)的高可靠性、高性能、易管理和易維護等私有技術(shù)強項的地方。而且網(wǎng)絡(luò)規(guī)模較小，搞一家廠商的設(shè)備就差不多了，不需要考慮互通。

4、數(shù)據(jù)中心跨站點二層互聯(lián)方面，RPR由于是公共標準可以成為種子選手，但其成長空間目前并不充分，還要看技術(shù)發(fā)展演進和各個廠家的態(tài)度。當然如果有哪家廠商愿意把自己的私有技術(shù)拿出來推成標準，也還是很有希望在市場上占據(jù)高點的。

5、在多站點選路方面，應(yīng)該會有些新的技術(shù)標準出來，DNS方案一統(tǒng)天下的局面不會長久。這塊誰都有機會，就看投入與機遇了。

7?、感言

瀝瀝拉拉寫了小兩個月，長度和時間都遠遠超出了最初的計劃，也耗費了不少的熱情和精力，以后是不敢隨便寫這種大文章了。但整個寫作過程對作者來說受益匪淺，不斷總結(jié)是自我提升的重要動力。后面休息休息還會再整理一些關(guān)于云計算數(shù)據(jù)中心安全、存儲、性能和可靠性等方面的外篇，先在這里立個目標好做自我督促。

套用一些書中?？吹降脑?，謹以此文獻給我的家人朋友和同事，并紀念作者步入而立之年。順便感謝每一位能從頭讀到這里的讀者，你們的存在是我寫作樂趣的源泉。

fanz

<u id="0d7xp"></u>