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

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

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

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

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

說(shuō)完公共的，該講些私貨了。

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

2.1 集中云

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

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

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

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

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

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

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

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

2.2?分散云

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

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

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

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

主機(jī)虛擬化Hosted

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

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

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

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

裸金屬虛擬化Bare-metal

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

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

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

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

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

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

vMotion

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

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

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

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

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

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

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

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

2.3?云計(jì)算小結(jié)

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

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

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

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

3、?VM間通信管理

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

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

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

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

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

3.1?Client與Server

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

所有數(shù)據(jù)中心需要處理的業(yè)務(wù)就是CS和SS兩種，CS肯定是基于IP進(jìn)行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ù)，再如有個(gè)員工離職，職工管理系統(tǒng)會(huì)同步通知薪酬管理、考勤管理、績(jī)效管理等一系列系統(tǒng)進(jìn)行刪除信息的相關(guān)操作?；贛AC的SS通信則是同一類服務(wù)器間的數(shù)據(jù)同步計(jì)算，比如使用WEB集群分流用戶訪問時(shí)，需要對(duì)修改或增刪的數(shù)據(jù)進(jìn)行集群同步；再比如多虛一中集群一起計(jì)算任務(wù)時(shí)協(xié)調(diào)者和執(zhí)行者之間的大量通信進(jìn)行任務(wù)調(diào)度。

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

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

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

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

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

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

3.2?層次化與扁平化

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

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

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

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

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

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

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

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

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

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

3.4?Server與Storage

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

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

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

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

先簡(jiǎn)單說(shuō)下，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)移的重要武器。如下圖，就是看誰(shuí)做太陽(yáng)，誰(shuí)做星星。相比較IP SAN的壯烈犧牲，F(xiàn)CoE采用了一條更為迂回的兼容道路，目前已經(jīng)出現(xiàn)了支持FCoE的存儲(chǔ)設(shè)備，也許Ethernet完全替代FC的時(shí)代真的能夠到來(lái)。

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

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

?

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

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

建多個(gè)數(shù)據(jù)中心站點(diǎn)主要有兩個(gè)目的，一是擴(kuò)容，二是災(zāi)備。

擴(kuò)容

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

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

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

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

災(zāi)備

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

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

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

簡(jiǎn)單來(lái)說(shuō)RPO衡量存儲(chǔ)數(shù)據(jù)恢復(fù)，RTO衡量服務(wù)器應(yīng)用恢復(fù)，RAO衡量網(wǎng)絡(luò)訪問恢復(fù)。一般來(lái)說(shuō)RPO設(shè)計(jì)都應(yīng)小于RTO。國(guó)外按照RTO/RPO的時(shí)間長(zhǎng)短對(duì)災(zāi)難恢復(fù)分級(jí)參考由高到低為：

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

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

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

小結(jié)

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

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

3.6?多站點(diǎn)選擇

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

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

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

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

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

當(dāng)前的站點(diǎn)選擇技術(shù)也可以對(duì)應(yīng)上面兩個(gè)步驟分為兩大類。

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

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

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

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

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

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

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

2、?站點(diǎn)內(nèi)部物理服務(wù)器和虛擬機(jī)數(shù)量增大，導(dǎo)致二層拓?fù)渥兇蟆?

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

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

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

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

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

4.1?路由與交換

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

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

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

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

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

4.2?EOR與TOR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

盒子說(shuō)完了講講框，盒式設(shè)備發(fā)展到一定程度，接口密度就成了天花板，必須要搞成機(jī)框式才能繼續(xù)擴(kuò)展了?？梢园褭C(jī)框里面的板卡理解為一個(gè)個(gè)獨(dú)立的盒子，然后通過交換網(wǎng)絡(luò)將其連接起來(lái)形成整體。

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

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

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

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

再簡(jiǎn)單說(shuō)說(shuō)H3C的12500，由于其公布資料太少，說(shuō)多了會(huì)有問題。還是從網(wǎng)站公布的宣傳值來(lái)看。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)板，當(dāng)前主要接口板與N7000相似，含48GE和4萬(wàn)兆、8萬(wàn)兆的線速接口板，32萬(wàn)兆非線速接口板。

1、從背板算起，首先16.65-7.65=9T就是10個(gè)槽位的容量，考慮到廠商的宣傳值都是雙向，那么每接口板槽位應(yīng)該是預(yù)留了9000/2/10=450G的最大出口帶寬。根據(jù)12508推算，雙主控每主控板槽位應(yīng)該是預(yù)留(7650/2-450*8)/2=112.5G的最大出口帶寬。由此背板預(yù)留通道數(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，由此可以推算出實(shí)際每塊接口板的出口帶寬為90*4=360G，同樣由于3.06T肯定是個(gè)雙向值，則每接口板最大交換即可偶帶寬理論值為180G（比較Cisco N7000的230G理論值要低一些）?！敖粨Q容量3.06T/6.12T”的寫法應(yīng)該指新一代的交換網(wǎng)板芯片能力翻倍或者是數(shù)量翻倍，那時(shí)其接口板理論帶寬就可以達(dá)到360G了，還是小于前面計(jì)算的背板預(yù)留450G的最大帶寬，說(shuō)明背板設(shè)計(jì)還是考慮不錯(cuò)的。

3、再來(lái)算算接口板，從8萬(wàn)兆接口板支持線速轉(zhuǎn)發(fā)看來(lái)，首先4個(gè)通道應(yīng)該對(duì)應(yīng)到4塊轉(zhuǎn)發(fā)芯片，每轉(zhuǎn)發(fā)芯片對(duì)應(yīng)2個(gè)萬(wàn)兆接口，處理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)該是使用類似于前面盒式交換機(jī)中的12.5G帶寬線路類型，每塊轉(zhuǎn)發(fā)芯片對(duì)應(yīng)2組12GE接口或2個(gè)10GE接口?？紤]其所有接口板采用完全相同轉(zhuǎn)發(fā)芯片是因?yàn)榇罅坎少?gòu)時(shí)存在價(jià)格優(yōu)勢(shì)，不像Cisco自己做芯片。

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

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

前面算了這么多，希望不會(huì)導(dǎo)致頭暈吧。

4.6?Clos與VOQ

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

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

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

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

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

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

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

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

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

5?、技術(shù)

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

1、VM之間的互通

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

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

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

5、VM跨站點(diǎn)遷移與多站點(diǎn)選路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

控制平面虛擬化

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

縱向虛擬化指不同層次設(shè)備之間通過虛擬化合多為一，代表技術(shù)就是Cisco的Fabric Extender，相當(dāng)于將下游交換機(jī)設(shè)備作為上游設(shè)備的接口擴(kuò)展而存在，虛擬化后的交換機(jī)控制平面和轉(zhuǎn)發(fā)平面都在上游設(shè)備上，下游設(shè)備只有一些簡(jiǎn)單的同步處理特性，報(bào)文轉(zhuǎn)發(fā)也都需要上送到上游設(shè)備進(jìn)行?？梢岳斫鉃榧惺睫D(zhuǎn)發(fā)的虛擬交換機(jī)

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

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

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

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

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

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

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

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

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

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

SR-IOV

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

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

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

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

5.3?技術(shù)理解

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

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

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

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

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

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

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

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

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

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

對(duì)于MPLS來(lái)說(shuō)，Sender和Receiver就是CE，Edge就是PE，Core就是P；Payload就是Ethernet/IP數(shù)據(jù)，Tag就是MPLS標(biāo)簽；

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

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

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

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

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

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

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

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

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

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

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

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

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

802.1Qbh

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

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

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

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

Cisco Nexus1000V

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

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

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

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

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

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

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

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

Nexus5000+Nexus2000

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

N5000+N2000實(shí)現(xiàn)了Cisco的FEX典型結(jié)構(gòu)（Fabric Extend，等同于Port Extend）。在N5000上看到每臺(tái)N2000就是以一個(gè)FEX節(jié)點(diǎn)形式出現(xiàn)的接口板。N2000擁有兩種物理接口類型，連接下游設(shè)備（可以是服務(wù)器或N2000，F(xiàn)EX結(jié)構(gòu)支持級(jí)聯(lián)擴(kuò)展）的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上對(duì)應(yīng)HIF的邏輯接口稱為L(zhǎng)ogical Interface (LIF)。截取Cisco膠片如下描述NIV的內(nèi)容。

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

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

p位標(biāo)識(shí)報(bào)文復(fù)制，0代表不需要復(fù)制，1代表N2000收到此報(bào)文后需要向同VLAN的所有本地下行接口復(fù)制。此位只有N5000可以置位。

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

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

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

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

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

UCS

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

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

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

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

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

5.4.2?802.1Qbg EVB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4.3?小結(jié)

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

順便說(shuō)一句，802.1Qbh需要變更交換機(jī)的轉(zhuǎn)發(fā)芯片以適應(yīng)VN-Tag轉(zhuǎn)發(fā)，而802.1Qbg的VEPA和Multichannel目前則只需要交換機(jī)做做軟件驅(qū)動(dòng)方面的變動(dòng)即可支持。不論將來(lái)誰(shuí)成為了市場(chǎng)技術(shù)主導(dǎo)，大家覺得Cisco設(shè)備同時(shí)支持兩套標(biāo)準(zhǔn)會(huì)有什么難度。從市場(chǎng)發(fā)展上大膽預(yù)測(cè)一下，Cisco會(huì)在802.1Qbg標(biāo)準(zhǔn)成熟后，在新一代N2000位置產(chǎn)品上實(shí)現(xiàn)對(duì)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都是通過定義一個(gè)Tag來(lái)為接入層交換機(jī)標(biāo)識(shí)VM（VN-Tag/S-VLAN），那么實(shí)際上還有個(gè)現(xiàn)成的可用Tag，就是MAC，每個(gè)VM的vNIC都擁有獨(dú)一無(wú)二的MAC，那么是否可以讓交換機(jī)根據(jù)源和目的MAC來(lái)建立VIF去對(duì)應(yīng)處理每個(gè)VM的vNIC流量呢。當(dāng)然細(xì)節(jié)上還要設(shè)計(jì)很多機(jī)制來(lái)保障各種情況的正常處理，但是暫時(shí)從方向上感覺應(yīng)該有些搞頭，回頭有時(shí)間細(xì)琢磨一下吧。能不能成標(biāo)準(zhǔn)無(wú)所謂，當(dāng)做頭腦游戲鍛煉思維了。

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

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

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

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

5.5.1?FC

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

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

FC擁有自己的獨(dú)立層次結(jié)構(gòu)，F(xiàn)C-0到FC-4對(duì)應(yīng)OSI模型的1-5層，但也并非一一對(duì)應(yīng)，完整協(xié)議內(nèi)容請(qǐng)大家自行查閱標(biāo)準(zhǔn)文檔。其中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ù)器或存儲(chǔ)等終端節(jié)點(diǎn)連接FC網(wǎng)絡(luò)的的接口，F(xiàn)是FC交換機(jī)設(shè)備連接服務(wù)器或存儲(chǔ)等終端節(jié)點(diǎn)的接口，E是FC交換機(jī)互聯(lián)接口。還記得前面技術(shù)理解里面的典型結(jié)構(gòu)么？

FC設(shè)備都擁有2個(gè)重要標(biāo)識(shí)：

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

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

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

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

?

當(dāng)然有隔離還得能互通，就好像做了VPN后還惦記著跨VPN互訪，有了FW還搞個(gè)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ù)體系還有最重要的一個(gè)關(guān)鍵流控技術(shù)Buffer to Buffer Credits用來(lái)確保無(wú)丟包轉(zhuǎn)發(fā)。BB Credits和TCP滑動(dòng)窗口相似，規(guī)則很簡(jiǎn)單，兩個(gè)相鄰FC節(jié)點(diǎn)在連接初始化的時(shí)候先協(xié)商一個(gè)度量收包設(shè)備Buffer大小的數(shù)值N出來(lái)，發(fā)包設(shè)備每發(fā)一個(gè)數(shù)據(jù)報(bào)文就做N-1，收包設(shè)備每收一個(gè)報(bào)文就回一個(gè)R_RDY報(bào)文回來(lái)，發(fā)包設(shè)備每收到一個(gè)R_RDY就做N+1，當(dāng)N=0時(shí)，發(fā)包設(shè)備就停止發(fā)包。

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

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

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

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

5.5.2?FCoE

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

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

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

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

2、和FCF建立連接。

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

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

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

?

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

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

DCB

由于Ethernet是沖突丟包的，為了保證FCoE的無(wú)丟包，IEEE引入了一系列的無(wú)丟包以太網(wǎng)技術(shù)（Lossless Ethernet），都定義在802.1Q DCB（Data Centre Bridging）標(biāo)準(zhǔn)系列中。DCB等同于DCE（Data Centre Ethernet）和CEE（Converged Enhanced Ethernet）的含義，就是不同廠商和工作組的不同稱謂，內(nèi)容都是一致的。DCB是IEEE為了在數(shù)據(jù)中心對(duì)傳統(tǒng)以太網(wǎng)技術(shù)進(jìn)行擴(kuò)展而制定的系列標(biāo)準(zhǔn)，前面說(shuō)過的VM接入技術(shù)標(biāo)準(zhǔn)中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ú)丟包以太網(wǎng)技術(shù)的必要組成部分。常見的無(wú)丟包技術(shù)主要是PFC和ETS，另外還有個(gè)DCBX（Data Center Bridging Exchange Protocol）技術(shù)，DCBX也是一起定義在802.1Qaz ETS標(biāo)準(zhǔn)中。

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

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

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

DCB的幾個(gè)標(biāo)準(zhǔn)目前都還處于Draft階段，其中PFC是由Cisco的Claudio DeSanti主編，ETS由Qlogic的Craig Carlson主編。

CNA

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

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

5.5.3?NPV

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

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

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

1、自己先通過FLOGI向FC Switch注冊(cè)去要個(gè)FC ID

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

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

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

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

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

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

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

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

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

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

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

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

5.5.4?小結(jié)

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

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

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

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

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

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

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

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

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

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

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

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

下面會(huì)分別介紹幾項(xiàng)主要技術(shù)，順序?yàn)榭刂破矫娑嗵撘患夹g(shù)VSS/IRF/vPC，數(shù)據(jù)平面多虛一技術(shù)TRILL/SPB/Fabric Path/QFabric和控制平面一虛多技術(shù)VDC。

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

VSS/IRF

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

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

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

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

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

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

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

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

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

?

vPC

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

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

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

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

小結(jié)

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

從Cisco Nexus系列產(chǎn)品的技術(shù)發(fā)展來(lái)看，在網(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報(bào)文外面再封裝一層標(biāo)識(shí)用于尋址轉(zhuǎn)發(fā)，這樣基于外層標(biāo)識(shí)就可以做些多路徑負(fù)載均衡和環(huán)路避免等處理工作了。TRILL/SPB都是屬于此列，QFabric目前開放出來(lái)的資料較少，猜測(cè)其應(yīng)該也使用了類似MACinMAC之類的方式在其網(wǎng)絡(luò)內(nèi)部傳輸報(bào)文。

TRILL

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

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

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

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

R (Reserved): 2 bits，預(yù)留。

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

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

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

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

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

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

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

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

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

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

FabricPath

FabricPath是Cisco 2010年6月底正式發(fā)布的專門針對(duì)數(shù)據(jù)中心設(shè)計(jì)的私有技術(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ū)別，一些主要變化如下，也可以說(shuō)這些是Cisco專門針對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)對(duì)TRILL做出的變更：

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

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

2、采用FTAG（Forwarding TAG）標(biāo)示不同的多播樹Graph，用于多拓?fù)渲形粗獑尾?組播/廣播報(bào)文的轉(zhuǎn)發(fā)。多拓?fù)渲缚梢栽谕惶譌abricPath網(wǎng)絡(luò)中支持不同的拓?fù)滢D(zhuǎn)發(fā)，而目前TRILL的多拓?fù)溥€未明確定義。每套拓?fù)淙笔∈褂?個(gè)Graph，每個(gè)Graph可以用一個(gè)FTAG標(biāo)示。目前NOS發(fā)布版本只開放支持2棵樹Graph，既一套拓?fù)?，?jù)稱最多可擴(kuò)展至64棵樹。多拓?fù)浣Y(jié)構(gòu)如下圖所示。

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

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

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

SPB

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

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

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

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

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

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

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

3、任意兩點(diǎn)間的Shortest Path一定是對(duì)稱的；ECT的負(fù)載均衡是基于不同I-SID分擔(dān)的；

總的來(lái)說(shuō)，SPB和TRILL/FabricPath相比主要有以下不同：

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

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

QFabric

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

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

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

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

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

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

小結(jié)

TRILL/FabricPath/SPB/QFabric都引入了控制平面協(xié)議來(lái)處理拓?fù)涔芾砗娃D(zhuǎn)發(fā)路徑判定的工作，都肯定會(huì)導(dǎo)致轉(zhuǎn)發(fā)效率上，相比較傳統(tǒng)Ethernet的下降，同時(shí)引入拓?fù)渥兓绊懥髁柯窂阶兏諗克俣鹊膯栴}。但是這些技術(shù)畢竟比以前的STP在帶寬上多了一倍的擴(kuò)充，組網(wǎng)規(guī)模上也得到擴(kuò)展，更適用于云計(jì)算數(shù)據(jù)中心的網(wǎng)絡(luò)需求，總體來(lái)講得大于失，屬于更先進(jìn)的生產(chǎn)力。

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

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

下面說(shuō)些個(gè)人極度主觀的預(yù)測(cè)（每寫到這里都有些神棍的感覺）：

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

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

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

FabricPath > TRILL > QFabric > IRF/VSS > SPB

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

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

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

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

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

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

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

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

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

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

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

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

5.6.4?小結(jié)

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

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

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

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

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

5.7.1?光纖直連

兩個(gè)站點(diǎn)就不多說(shuō)了，直接在兩個(gè)站點(diǎn)的核心或匯聚設(shè)備之間拉兩根光纖就OK了，也用不到什么特別的技術(shù)。唯一需要注意的是在兩個(gè)站點(diǎn)之間的鏈路上做些報(bào)文控制，對(duì)廣播和STP等報(bào)文限制一下發(fā)送速率和發(fā)送范圍，避免一個(gè)站點(diǎn)的廣播風(fēng)暴或拓?fù)涫諗坑绊懙狡渌军c(diǎn)的轉(zhuǎn)發(fā)。

當(dāng)站點(diǎn)較多時(shí)，理論上有兩種結(jié)構(gòu)可用：

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

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

從技術(shù)上講星形拓?fù)洳恍枰~外的二層互聯(lián)技術(shù)，只部署一些報(bào)文過濾即可，可以通過鏈路捆綁增強(qiáng)站點(diǎn)到核心間鏈路故障保護(hù)和鏈路帶寬擴(kuò)展。而環(huán)形拓?fù)浔仨氃黾訉ｉT的協(xié)議用于防止環(huán)路風(fēng)暴，同樣可以部署鏈路捆綁以增加帶寬冗余。

環(huán)形拓?fù)涞墓矘?biāo)準(zhǔn)控制協(xié)議主要是STP和RPR（Resilient Packet Ring IEEE802.17），STP的缺點(diǎn)前面說(shuō)了很多，RPR更適合數(shù)據(jù)中心多站點(diǎn)連接的環(huán)形拓?fù)?。另外很多廠商開發(fā)了私有協(xié)議用于環(huán)路拓?fù)涞目刂?，如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）等。

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

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

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

5.7.2?MPLS核心網(wǎng)

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

VLL

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

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

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

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

Kompella：RFC4761，使用BGP協(xié)議在PE間建立連接，使用BGP VPNv4擴(kuò)展字段攜帶VPN對(duì)應(yīng)Label信息進(jìn)行傳遞，這個(gè)實(shí)現(xiàn)起來(lái)比Martini復(fù)雜一點(diǎn)點(diǎn)，用得也就少了一些些。

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

VPLS

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

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

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

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

解決上述問題有以下兩個(gè)思路：

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

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

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

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

5.7.3?IP核心網(wǎng)

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

從技術(shù)上來(lái)看，公共的技術(shù)標(biāo)準(zhǔn)主要有VLLoGRE/VPLSoGRE和L2TPv3，私有技術(shù)就是Cisco的OTV了。VLLoGRE/VPLSoGRE沒啥好說(shuō)的，就是在IP層打通個(gè)GRE隧道，再把Ethernet報(bào)文扔到隧道里面?zhèn)鳌Ｏ旅嬷饕f(shuō)說(shuō)L2TPv3和OTV。

L2TPv3

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

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

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

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

OTV

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

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

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

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

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

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

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

3、ARP控制。對(duì)遠(yuǎn)端站點(diǎn)返回的ARP Reply報(bào)文進(jìn)行Snoop和Cache，當(dāng)再收到本地查詢同樣目的IP的ARP Request時(shí)直接代答，不向其他OTV站點(diǎn)擴(kuò)散，減少跨站點(diǎn)的ARP Request廣播。

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

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

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

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

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

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

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

5.7.4?小結(jié)

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

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

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

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

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

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

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

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

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

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

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

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

5.8.1?GSLB

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

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

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

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

5.8.2?LISP

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

LISP即使能夠成事，至少也得2年以后了，所以大家可以先看個(gè)熱鬧，等RFC標(biāo)準(zhǔn)立起來(lái)再介入也不遲。也許Cisco回頭覺著整這個(gè)太費(fèi)勁，說(shuō)不定哪天就偃旗息鼓了。別的廠商又真不見得有這么大號(hào)召力能把LISP忽悠起來(lái)。全當(dāng)學(xué)著玩了，目前別拿LISP太當(dāng)真。

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

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

小結(jié)

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

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

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

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

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

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

6、?終章

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

在未來(lái)5-10年間作者認(rèn)為：

市場(chǎng)方面

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

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

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

技術(shù)方面

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

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

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

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

5、在多站點(diǎn)選路方面，應(yīng)該會(huì)有些新的技術(shù)標(biāo)準(zhǔn)出來(lái)，DNS方案一統(tǒng)天下的局面不會(huì)長(zhǎng)久。這塊誰(shuí)都有機(jī)會(huì)，就看投入與機(jī)遇了。

7?、感言

瀝瀝拉拉寫了小兩個(gè)月，長(zhǎng)度和時(shí)間都遠(yuǎn)遠(yuǎn)超出了最初的計(jì)劃，也耗費(fèi)了不少的熱情和精力，以后是不敢隨便寫這種大文章了。但整個(gè)寫作過程對(duì)作者來(lái)說(shuō)受益匪淺，不斷總結(jié)是自我提升的重要?jiǎng)恿Α：竺嫘菹⑿菹⑦€會(huì)再整理一些關(guān)于云計(jì)算數(shù)據(jù)中心安全、存儲(chǔ)、性能和可靠性等方面的外篇，先在這里立個(gè)目標(biāo)好做自我督促。

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

fanz