Trill、SPB與堆疊+埠聚合哪種方案更適合數據中心橫向流量呢?


謝邀。

題主這裡的東西流量是指:數據中心之間的大二層網路內的流量,先來看看這三項技術的應用場景:

Trill ( Transparent Interconnect Lots of Link)

這項技術由Intel、華為等公司發起,使用鏈路狀態路由協議IS-IS來學習、交換終端的MAC地址,數據轉發,將依據以太幀頭的目的MAC地址,嚴格按照MAC地址-埠號來轉發。

這點類似IP包的轉發,IP包的轉發也是依據IP包的目的IP,來查詢路由表,找到下一跳來轉發。

對於未知的MAC,丟棄,而不會像傳統交換機泛洪處理,依賴路由協議自身的防環功能,所以在Trill網路里完全可以不用Spanning Tree 來防環,即使有物理冗餘鏈路也不會造成環路,充分高效利用物理鏈路。

傳統交換機完全依賴用戶流量的源MAC記憶功能來轉發流量,對於未知MAC泛洪處理,只要有物理環路就會引起廣播風暴,為了克服環路,引入Spanning Tree這個控制協議,來邏輯阻斷可能會引起環路的物理鏈路,哪些被阻斷的物理鏈路相當於白白閑置了,所以這不是高效利用帶寬的方法,而是補救措施。

Trill適合一個大型的二層乙太網,有很多冗餘物理鏈路。

SPB(Short Path Bridge)

最早由Nortel公司提出的一項技術,主要用於運營商的城域網,在城域網的邊緣,通過MAC-in-MAC的隧道方式,將用戶的以太幀完全封裝在運營商的幀頭裡,這樣只有邊緣設備需要維護客戶VLAN、MAC地址,對於城域網非邊緣設備,則只需要依據城域網內部的VLAN、MAC來轉發流量。

SPB也將IS-IS引入當控制協議,這點和Trill很像,但是SPB更偏重於隧道這個功能,用於運營商城域網給用戶提供二層VPN服務。

Stack Port Channel

這個組合是為了克服spanning tree 邏輯阻斷備份鏈路,將多個交換機堆疊在一起,外在表現是一台大交換機,或者將多條物理鏈路綁定成一條邏輯鏈路,這樣在spanning tree 眼裡,就是一條鏈路,自然也不會有環路了,這樣多條物理鏈路都可以被充分利用。

這項技術沒有引入控制協議來避免二層環路,所以還依然需要Spanning Tree來防環,如果數據中心依賴這個方案來實現數據中心互聯,則所有數據中心將處在一個Spanning Tree域,廣播風暴會影響所有的數據中心,無法隔離廣播風暴,故不適宜。

三者如果一定選其一,那就選Trill,但支持Trill的廠家可能很有限,選擇它,就意味著選擇廠商。

如果更靈活數據中心互聯,轉發東西流量,VxLAN 是更好的選擇,畢竟支持的廠家更多,優點多多,關於VxLAN 寫過一篇回答:http://www.zhihu.com/question/24393680/answer/132219127。

如果我的答案對您有幫助,請投票支持我,非常感謝!

https://club.zhihu.com/votes?domain=internet


以上三種,都已經成為數據中心發展過程中的墊腳石。

然後,你這個橫向流量是什麼類型的流量呢?我覺得如果純粹是IP可達就可以的流量,那麼做Layer3 ECMP的組網,把網關下沉到接入層就足夠了,當然,堆疊+埠聚合也不是不可以,很多公司也是這麼做的,但是堆疊+埠聚合不可避免的存在廣播域之類的問題,對於自動化做的夠好的客戶,維護一個layer3 ecmp的網路似乎也不複雜。

如果你的數據中心的橫向流量里包含了一定需要二層互通的流量而且還不小,那麼堆疊+埠聚合構建的這種網路就不是很可靠了,這個時候嘛……就要請出VXLAN了。為什麼一定是VXLAN呢?因為它標準化、支持廠家多……以及最重要的是VXLAN可以把邊界做到伺服器內部的虛擬化層面上去,讓物理設備完全變成純IP轉發的盒子……可以部署到虛擬化層面就意味著可以用上Open vSwitch,就意味著可以更好的實現自動化……再說下去就變成SDN了……

基本上來說,有龐大東西向流量的數據中心,十有八九都是因為虛擬化(傳統網路誰去沒事把伺服器亂接啊……)


想有更好的擴展性的話,可能還是基於l3 ecmp的clos組網比較好,如果規模不大,推薦埠聚合和stacking,至於trill和spb基本上已經沒多少人用了


簡單說吧,能不用二層技術的就不用,三層轉發可以更好的控制和迴避廣播,規划下你的dc間共享一個ip地址段


推薦閱讀:

如何評價@左耳朵耗子 的《關於阿里雲經典網路的問題》?
分散式的一致性hash問題?
國內優秀的響應式WEB網站有哪些?
怎麼用dht網路標誌獲得bt種子或磁力鏈接?

TAG:雲計算 | 計算機網路 | 數據中心 |