【51CTO.com譯稿】網(wǎng)絡(luò)架構(gòu)師希望成長(zhǎng)中的數(shù)據(jù)中心運(yùn)行速度越來(lái)越快，讓用戶越來(lái)越滿意，管理越來(lái)越簡(jiǎn)單。思科表示其FabricPath技術(shù)可以滿足這三大愿望，它使數(shù)據(jù)中心交換機(jī)之間的連接比傳統(tǒng)的生成樹協(xié)議（STP）更好，在這個(gè)獨(dú)家測(cè)試中，我們?cè)u(píng)估了FabricPath在提高帶寬，重整問(wèn)題路由和簡(jiǎn)化網(wǎng)絡(luò)管理方面的能力，在這三個(gè)方面，F(xiàn)abricPath最終提交了滿意的答卷，思科采用了IETF即將發(fā)布的TRILL預(yù)標(biāo)準(zhǔn)規(guī)范，它比基于STP的設(shè)計(jì)表現(xiàn)確實(shí)要好得多。

但有一個(gè)問(wèn)題：目前只有思科Nexus 7000裝備F1 1/10GB以太網(wǎng)線卡才可以支持FabricPath，隨著思科對(duì)FabricPath支持的擴(kuò)大，這種情況肯定會(huì)得到改善，思科最近宣布Nexus 5500也會(huì)支持FabricPath，相信會(huì)有越來(lái)越多的新產(chǎn)品會(huì)兼容TRILL規(guī)范。

初識(shí)TRILL

成長(zhǎng)中的數(shù)據(jù)中心至少要面臨三個(gè)網(wǎng)絡(luò)方面的挑戰(zhàn)：更多的帶寬，更靈活和更簡(jiǎn)單的管理，思科聲稱FabricPath是多鏈接透明互聯(lián)（Transparent Interconnection of Lots of Links，TRILL）協(xié)議的一種實(shí)現(xiàn)，一舉解決了這三個(gè)挑戰(zhàn)，TRILL規(guī)范在IETF內(nèi)部仍然處于草案狀態(tài)，因此今天的任何實(shí)現(xiàn)都是基于預(yù)定義標(biāo)準(zhǔn)的。

從本質(zhì)上講，F(xiàn)abricPath是一種鏈路層路由協(xié)議，開啟FabricPath的交換機(jī)和傳統(tǒng)的以太網(wǎng)交換機(jī)有兩個(gè)地方不一樣：它們使用IS-IS上傳輸?shù)目刂葡⒂?jì)算出二層路徑，使用FabricPath頭封裝入站以太網(wǎng)幀，消息頭包含路由的源和目標(biāo)交換機(jī)地址，以及阻止循環(huán)的TTL值。

FabricPath減小了配置難度，不需要掌握IS-IS知識(shí)，只需要兩行交換機(jī)配置命令就可以開啟FabricPath，唯一強(qiáng)制性要求是要區(qū)別邊緣端口和Fabric端口，在測(cè)試中，我們分配了交換機(jī)ID，并設(shè)置了通信流使用的哈希算法，每個(gè)都只需要一行命令就能搞定。

FabricPath相對(duì)STP***的優(yōu)勢(shì)是帶寬和多用途，STP提供冗余和阻止循環(huán)，但它使用的是主/備用模式，因此，STP網(wǎng)絡(luò)為任何流量提供了兩個(gè)可能的路徑，但只有其中一個(gè)可以轉(zhuǎn)發(fā)流量，生成樹設(shè)計(jì)要求路由器在廣播域之間傳輸信息，進(jìn)一步限制了可用帶寬，并增加了復(fù)雜度。反過(guò)來(lái)，路由器增加了延遲，并需為冗余準(zhǔn)備額外的鏈路。

與此相反，F(xiàn)abricPath跨所有參與的交換機(jī)創(chuàng)建一個(gè)簡(jiǎn)單的交換機(jī)網(wǎng)絡(luò)，增加了二層域內(nèi)的可用帶寬，F(xiàn)abricPath使用等成本多路徑（ECMP）路由跨所有可用鏈路轉(zhuǎn)發(fā)流量，因此它是一個(gè)主動(dòng)/主動(dòng)模式的技術(shù)。

擴(kuò)大的二層域也需要少量的三層路由跳數(shù)，減少延遲，它讓VMware的VMotion這樣的遷移服務(wù)變得更簡(jiǎn)單，更大的二層域簡(jiǎn)化了變更管理，因?yàn)橐苿?dòng)連接的主機(jī)不再需要IP地址和/或修改VLAN配置。

FabricPath也減少了洪水廣播和MAC地址表大小，這兩個(gè)在大型二層網(wǎng)絡(luò)中是眾所周知的問(wèn)題，F(xiàn)abricPath交換機(jī)發(fā)送到未知的目的地時(shí)使用多播而不是洪水式轉(zhuǎn)發(fā)，它使用從Fabric學(xué)到的信息和邊緣交換機(jī)上的源MAC地址計(jì)算出路由表。

此外，它使用一個(gè)叫做“會(huì)話學(xué)習(xí)”的技術(shù)，交換機(jī)只使用會(huì)話真正使用到的端口填充MAC地址表，這和傳統(tǒng)的交換機(jī)不一樣，傳統(tǒng)交換機(jī)會(huì)看到廣播域內(nèi)的所有洪水流量，并把每個(gè)地址都放入MAC表，與此相反，F(xiàn)abricPath交換機(jī)不需要龐大的MAC地址表，即使二層域覆蓋了數(shù)以萬(wàn)計(jì)的主機(jī)。

思科聲稱FabricPath可以縱向擴(kuò)展到256條活躍路徑，每條路徑包括多達(dá)16個(gè)使用鏈路聚合的鏈路（按思科的叫法即EtherChannel），我們沒(méi)有核實(shí)這是否屬實(shí)，因?yàn)橐?yàn)證的話需要將近1萬(wàn)個(gè)測(cè)試端口，我們只能按比例縮小規(guī)模進(jìn)行測(cè)試，每個(gè)交換機(jī)設(shè)置16條活動(dòng)路徑，每條路徑***可以支持16個(gè)鏈路。

FabricPath的***缺陷是支持它的產(chǎn)品數(shù)量有限，在9月份的測(cè)試中，只有思科Nexus 7000交換機(jī)支持，并且需要裝備F1 32口 1/10GB以太網(wǎng)線卡。思科最近宣布Nexus 5500也將支持FabricPath，但要等到2011年發(fā)布新的軟件版本。除此之外，目前尚不能將FabricPath延伸到其它思科交換機(jī)上，更不用說(shuō)其它廠家的產(chǎn)品了。

雖然FabricPath一開始就被大家看好，但在評(píng)估數(shù)據(jù)中心交換機(jī)時(shí)，它不會(huì)成為唯一的評(píng)判標(biāo)準(zhǔn)。因?yàn)槲覀兊臏y(cè)試主要關(guān)注的是FabricPath的功能，其它問(wèn)題我們暫時(shí)不談，如可擴(kuò)展性和延遲。

另一個(gè)問(wèn)題是價(jià)格，150萬(wàn)美元的價(jià)格不得不叫人吃驚，但它包含6個(gè)Nexus 7000和384個(gè)10G以太網(wǎng)和光纖端口，現(xiàn)有Nexus 7000用戶可以添加F1 FabricPath線卡，每個(gè)大約3.5萬(wàn)美元。

出色的性能

我們測(cè)試了FabricPath五個(gè)方面的功能，所有這些都是在由6個(gè)Nexus 7000連接而成的一個(gè)FabricPath網(wǎng)絡(luò)中完成的，總共連接了128000個(gè)模擬主機(jī)，Spirent TestCenter流量產(chǎn)生器/分析器模擬每端口100個(gè)主機(jī)，為6個(gè)交換機(jī)上128個(gè)10G以太網(wǎng)端口提供流量。

在***次測(cè)試中，我們?cè)噲D驗(yàn)證FabricPath是否可以支持交換機(jī)之間的16條冗余路徑，在配置好兩個(gè)邊緣交換機(jī)上的16個(gè)EtherChannel端口后（每個(gè)端口4條鏈路），我們使用Spirent TestCenter在所有模擬主機(jī)之間連續(xù)發(fā)送5分鐘的流量。

在這個(gè)測(cè)試中，交換機(jī)轉(zhuǎn)發(fā)了所有通信，沒(méi)有出現(xiàn)幀丟失的情況，驗(yàn)證了FabricPath跨16個(gè)冗余連接負(fù)載共享的能力。

雖然EtherChannel組的數(shù)量很重要，也就是每個(gè)組中的鏈路數(shù)量，主機(jī)之間包含大規(guī)模應(yīng)用程序數(shù)據(jù)傳輸，因此這里是重點(diǎn)，我們使用和***次測(cè)試相同的物理拓?fù)浣Y(jié)構(gòu)，但這次每個(gè)邊緣交換機(jī)配置了四個(gè)EtherChannels，每個(gè)EtherChannels包含16個(gè)10G以太網(wǎng)鏈路，系統(tǒng)再次圓滿完成了任務(wù)，沒(méi)有幀丟失。

我們也分析了FabricPath如何處理主機(jī)MAC地址，在前面的測(cè)試中我們已經(jīng)看到了問(wèn)題，交換機(jī)的哈希算法導(dǎo)致跨多個(gè)鏈路的測(cè)試流量分布非常不平衡。然后我們使用完全不同的偽隨機(jī)MAC地址進(jìn)行重復(fù)測(cè)試，獲得了幾乎完全相同的結(jié)果，因此交換機(jī)可以跨所有核心鏈路統(tǒng)一分配它們。

不會(huì)出現(xiàn)組播性能損失

思科也聲稱FabricPath可以跨多個(gè)交換機(jī)管道負(fù)載共享組播源接收器樹，而STP網(wǎng)絡(luò)只有單個(gè)樹，我們?cè)谝粋€(gè)非常大的組播設(shè)置中對(duì)此進(jìn)行了測(cè)試，Spirent TestCenter在兩個(gè)邊緣交換機(jī)的每個(gè)端口上模擬100個(gè)組播源（總共128個(gè)端口），每個(gè)交換機(jī)的每個(gè)端口也加入了源自其它邊緣交換機(jī)上所有端口的50個(gè)組，相當(dāng)于二層設(shè)備有64萬(wàn)條組播路由（128個(gè)邊緣交換機(jī)端口*50個(gè)組*每個(gè)組100源）。

為了確定FabricPath是否能夠負(fù)載共享組播流量，每次測(cè)試完畢后，我們都檢查了各個(gè)EtherChannel接口的數(shù)據(jù)包計(jì)數(shù)，結(jié)果顯示組播比單播流量的變化要大，但也不是很明顯，最多的時(shí)候，跨多個(gè)EtherChannels的數(shù)據(jù)包計(jì)數(shù)約相差2.5%.

隨后，我們混合單播和組播流量重復(fù)了相同的測(cè)試，F(xiàn)abricPath再次成功將所有幀傳輸出去，但單播和組播數(shù)據(jù)包計(jì)數(shù)的差異和單獨(dú)測(cè)試單播或組播時(shí)的情況一致，這表明向傳輸單播流量的FabricPath為了加入組播流量不會(huì)對(duì)負(fù)載共享帶來(lái)負(fù)面影響，反之亦然。

FabricPath故障轉(zhuǎn)移

對(duì)于數(shù)據(jù)中心網(wǎng)絡(luò)而言，彈性比高性能更重要，不管是FabricPath還是STP，最關(guān)鍵的問(wèn)題是盡快重新路由故障鏈路或交換機(jī)上的通信流量，使用快速生成樹時(shí)進(jìn)行故障轉(zhuǎn)移需要1-3秒，如果是標(biāo)準(zhǔn)的生成樹則需要45-60秒，你可能想問(wèn)，既然FabricPath那么優(yōu)秀，那么它在發(fā)生故障后需要多長(zhǎng)的時(shí)間轉(zhuǎn)移呢？

為了找到答案，我們?cè)谒臈l路徑，16個(gè)鏈路上做了相同流量的測(cè)試，通過(guò)關(guān)閉骨干交換機(jī)來(lái)模擬故障轉(zhuǎn)移，我們重復(fù)測(cè)試了四次，測(cè)試結(jié)果表明FabricPath比生成樹確實(shí)要快，就平均值而言，系統(tǒng)重新路由發(fā)送到故障骨干交換機(jī)的通信流量的時(shí)間只有162毫秒，較快速生成樹的1-3秒有一定的改善。

我們也測(cè)試了向FabricPath網(wǎng)絡(luò)增加交換機(jī)后的匯聚時(shí)間，即將先前關(guān)閉的骨干交換機(jī)加電啟動(dòng)，在這個(gè)測(cè)試中，我們發(fā)現(xiàn)匯聚時(shí)間為0，IS-IS協(xié)議識(shí)別新的路徑，然后開始在它上面路由通信流量，在重新計(jì)算路由期間沒(méi)有幀丟失。

數(shù)據(jù)中心網(wǎng)絡(luò)管理器（DCNM）

在***的測(cè)試中，我們檢查了思科的數(shù)據(jù)中心網(wǎng)絡(luò)管理器（Data Center Network Manager，DCNM）軟件，它用于配置和監(jiān)控FabricPath網(wǎng)絡(luò)，DCNM使用簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議（Simple Object Access Protocol，SOAP） - 一個(gè)基于XML的數(shù)據(jù)表示方法，它允許第三方Web服務(wù)調(diào)用它。

在我們的測(cè)試中，我們的重點(diǎn)放在DCNM執(zhí)行常見的FabricPath管理任務(wù)上，所有測(cè)試的任務(wù)都包含在DCNM的基礎(chǔ)版本中，免費(fèi)提供給管理Nexus交換機(jī)，一些額外的功能，如配置歷史管理是需要額外付費(fèi)購(gòu)買的，因此我們沒(méi)有測(cè)試它們。此外，DCNM主要負(fù)責(zé)Nexus交換機(jī)管理，雖然它可以使用思科發(fā)現(xiàn)協(xié)議（Cisco Discovery Protocol，CDP）發(fā)現(xiàn)非Nexus交換機(jī)，但它管理的信息僅限于CDP發(fā)現(xiàn)的，使用Nexus設(shè)備時(shí)，管理工具包更能發(fā)揮作用。

在我們的***次測(cè)試中，我們配置的DCNM發(fā)現(xiàn)了6臺(tái)Nexus交換機(jī)，第二次測(cè)試時(shí)，我們配置DCNM當(dāng)FabricPath鏈路上的流量超過(guò)80%的利用率時(shí)發(fā)送文本和電子郵件，第三次測(cè)試時(shí)，我們配置DCNM在鏈路失效時(shí)自動(dòng)報(bào)警（我們是通過(guò)拔掉邊緣交換機(jī)和骨干交換機(jī)之間的線纜觸發(fā)的），***，我們配置DCNM應(yīng)用早前檢測(cè)到的加權(quán)隨機(jī)數(shù)給所有交換機(jī)配置排隊(duì)，然后移除所有交換機(jī)配置的WRED部分，DCNM成功地完成了所有任務(wù)。

結(jié)語(yǔ)

我們希望盡快看到更多的交換機(jī)支持FabricPath，毫無(wú)疑問(wèn)，在網(wǎng)絡(luò)領(lǐng)域，它是一個(gè)顯著的進(jìn)步，正如我們的測(cè)試顯示，F(xiàn)abricPath簡(jiǎn)化了網(wǎng)絡(luò)設(shè)計(jì)，提高了網(wǎng)絡(luò)可擴(kuò)展性和彈性，對(duì)于那些在意圖擴(kuò)大數(shù)據(jù)中心的網(wǎng)絡(luò)架構(gòu)師而言，現(xiàn)在使用FabricPath是個(gè)***的選擇。

【51CTO.com譯稿，非經(jīng)授權(quán)謝絕轉(zhuǎn)載！合作媒體轉(zhuǎn)載請(qǐng)注明原文出處及作者】

原文出處：http://www.computerworld.com/s/article/9192820/Cisco_FabricPath

作者：David Newman