25GbE可以解決資料中心過載問題嗎?
25GbE通過在物理架構上降低硬體成本,提供更靈活的通道,可以解決資料中心過載問題。
“世間萬物,變得越多,留的越多”——這是大家一直贊同的觀念,也是網路行業流傳許久的口頭禪“萬變不離其宗”。但是現在貌似已不再是“真理”。
今天,25千兆乙太網(GbE, Gigabit Ethernet)可能會成為我們新的護身符,帶領我們戰勝過載問題。
在區域網內,網路速度一直以相當可預見的方式遞增:10 Mbps 讓位給了100 Mbps, 不久,100 Mbps又給1 Gbps讓位。因為如此可預見,所以並不刺激,反而對於我們這些不得不花錢來支援網速增長的人來說,也並不總是受歡迎。
與此同時,不要忘了無線網速,它也在隨著時間的推移不停增長,但也總是在接入層滯後於有線客戶端。目前,大部分有線客戶端都以1 Gbps的傳輸速率連線,看起來似乎這就是蜜月點。因為沒有人願意花費升級電纜,網路卡等費用以提供更高的網速,但這樣的速度又正好可以讓搞笑貓的視訊很快傳遞到終端使用者。
其實我們現在站在一個十字路口。這是無線技術問世以來第一次,消費者要使用的無線速率超過了基礎設施可支援的範圍。大多數無線射頻通過一個超五類(Cat-5e)網線以1 Gbps的速率連線到一個接入埠。一些電纜站點有不同的電纜,甚至可能有超六類(Cat-6). 然而,所有常見的佈線,最大吞吐量都是1 Gbps.
隨著無線裝置現在升級到802.11ac, 速率大於1 Gbps, 一個問題開始出現。因為現在的無線電系統提供越來越高的密度,每個無線裝置回程連線到有線交換結構都出現嚴重的過載現象。20個不同的人以1 Gbps速率連線到一個無線裝置,和一個人以1 Gbps速率連線到一個無線裝置能一樣嗎?當然不可能。
換裝現有的電纜,以提供所需的吞吐量
兩個相互競爭的標準提案:在相同的超五類電纜及以上規格電纜提供2.5 Gbps和5 Gbps的速度。這兩個標準的背後都有一批業內堅定擁護者,而且兩者的目標都是要成為IEEE標準。很多廠商傳言有預標準版本的產品,然而,我們可以篤定沒有哪個無線廠商有這麼快的速度。
推翻現有的電纜裝置重來是非常昂貴的,有一些廠商估算成本約300美元/根電纜。任意給定的大型企業電纜數量都數以千計,這就意味著改造到更高規格的超六類(Cat-6e)電纜或光纖電路的總成本是相當巨大的。而且事實上,無線射頻廠商並沒有迫不及待地提供10 Gbps速率支援,你就可以很快明白為什麼在現有電纜基礎上提供更快速度的新標準會如此受歡迎。
考慮到目前普遍無線電的電流密度,回程射頻儘可能達到5 Gbps將允許更合理的資料中心過載率。而達到這一切的價格會比電纜更換專案合理得多。當然,因為這還都不是IEEE標準,而且沒有任何製造商暗示他們將如何處理這個問題,我們真的還不能推測定價。它的確是可能的,然而,資本支出一定量就需要物盡其用,也就是說要充分利用這些新的速度。但是,即使我們不得不推翻現有無線站點和所有回傳接入交換機重新搭建,都比推翻電纜重新佈線來得經濟。不僅如此,無線網路不是我們看到這些變化的唯一領域。
25千兆乙太網可以改變市場
隨著資料中心變得更有效率,密度(按數量計算的虛擬機器,處理器,或廣義上的計算和儲存能力)有所增加,有一點已經很清楚:為提供高效便攜的設計,目前存在的電纜,光纖,競爭標準和速率都太多了。25千兆乙太網就是一個新興的標準,可以讓這些多樣統一化。因為可以在物理層更有效地利用通道,硬體成本顯著減少,同時,整體速度在關鍵瓶頸上突破:架頂式伺服器連線。
一種非常常見的資料中心設計是,一個交換機放在機架頂部,聚集該機架的所有乙太網流量。這個所謂的架頂式(ToR, top of rack)交換機連線到一個行聚合交換機的底端,並且所有流量最終都將回程到核心。CLOS設計—或稱為葉/脊柱設計改變了一點,但概念上基本相同:伺服器接入層逐漸聚集到更有能力的裝置上,資料中心的流量通過該裝置進出。現在伺服器停留在1 GbE或10 GbE, 而架頂式交換機吞吐量為40 GbE, 硬體費用爬升相當快,因為需要滿足相當程度的過載需求。25千兆乙太網支持者的目的是將伺服器以更快地速度連線到架頂式交換機,然後允許交換機以50 Gbps或100 Gbps的速率回傳來解決過載問題。
行業巨頭支援25千兆乙太網
25千兆乙太網的演變正處於起步階段。但是支持者都很看好它的未來—包括大多數行業巨頭如思科、Juniper、Broadcom、惠普、Marvell以及ZTE,部分是因為他們聲稱該標準在很多情況下可減少近4:1架頂式交換機密度。鑑於支持者數量龐大、設計工作的嚴肅性、以及去年IEEE投票中途建立了一個工作組的事實,所以25千兆乙太網的潛力絕對不可忽略。雖然我們短期內不太可能看到真正的適用,至少不是作為一個正式的標準,但在未來幾年可能會成功,併成為事實上的標準。
讓我們回到文章的開頭:一切可能真的會發生變化。這可能讓那些停滯不前,否認創新可能性的人坐立不安,但現實情況是,所有這些新興的建議和標準都有利於該行業。這些建議和標準都會從概念變成廣泛實施嗎?這很難說,但事實是,我們正在努力更快速地解決網路問題,比以往任何時候都證明我們已經從過去吸取了經驗教訓。如果我們想要推動行業向前,我們必須驅逐停滯的現狀,永遠的“不變”。擁抱變化。
作者:Teren Bryson 翻譯:柳芒
來源:51CTO
相關文章
- 捕獲問題SQL解決過度CPU消耗問題-- 轉載SQL
- HTTP代理可以解決哪些問題?HTTP
- 資料庫效能問題解決過程1例子資料庫
- bang能看過來嗎,幫我解決一個問題麼
- 飄在海上的艦載資料中心, 你見過嗎?
- 解決AI的小資料問題AI
- 低程式碼平臺可以解決軟體開發的所有問題嗎
- 離職,問題就解決了嗎?
- 解決React通過ajax載入資料更新頁面不加判斷會報錯的問題React
- 解決Element UI 表格元件懶載入資料重新整理問題UI元件
- 解決WPF中過載Window.OnRender函式失效問題函式
- 安裝資料庫和資料庫解決問題資料庫
- 解決hive資料庫 插入資料很慢的問題Hive資料庫
- 資料庫層面問題解決思路資料庫
- sbt配置——資料來源問題解決
- 資料探勘主要解決四類問題
- 使用bulkCollect解決資料遷移問題
- 資料過載採用exalead輕鬆解決
- 通過註解完美解決混淆問題
- 低程式碼開發可以解決哪些問題
- 解決SQL Server資料庫佔用記憶體過多的問題SQLServer資料庫記憶體
- 過濾器解決檔案上傳下載跨域問題過濾器跨域
- 解決「問題」,不要解決問題
- 解決兩相同資料庫資料同步的問題 (轉)資料庫
- Oracle資料庫訪問限制繞過漏洞 解決Oracle資料庫
- 資料編號+1 併發問題解決
- SqlServer資料庫中文亂碼問題解決SQLServer資料庫
- 【Spark篇】---Spark解決資料傾斜問題Spark
- 解決Gson解析Date資料格式的問題
- 解決被掛起的資料庫問題資料庫
- oracle 資料庫解決問題思路總結Oracle資料庫
- kingsoft資料夾可以刪除嗎 kingsoft資料夾刪不掉的解決辦法
- 一個lua問題解決過程
- 解決超過會話數問題會話
- 在Linux中,ansible可以解決哪些問題?Linux
- 解決資料庫高併發訪問瓶頸問題資料庫
- 作為企業資料安全的後盾,備份自身的問題解決了嗎?
- db4o適合負載均衡應用下的問題解決嗎負載