隨著IT部門為服務器添加輸入/輸出密集型和通信密集型的應用程序，數據中心網絡面臨的壓力顯著加大。

[[129292]]

圍繞1 GbE安裝的系統不再高效;在許多情況下，替換技術：10 GbE同樣是個網絡瓶頸。

幸好有不止一種方法可以疏通擁堵的網絡流量，從成本低、見效快的對策，到戰略性資本投入和重組，不一而足。新技術勢必會提升網絡容量，而采用網絡架構已借助多通道以太網，克服了主干網的性能瓶頸。在一些情況下，運營方面的簡單組織也能緩解擁堵情況。

將存儲與服務器放在一起

改變數據流是一種成本低、見效快的方法，可以克服網絡瓶頸。一個例子就是讓數據從聯網存儲流向服務器。

谷歌公司將聯網存儲節點和多臺服務器放在同一處，然后安排應用程序使用來自附近存儲節點的數據。這種方法讓你可以為機架內交換機添加成本低廉的端口，或者甚至可以有兩只交換機，從而允許節點上有雙以太網端口。這還很容易在存儲節點上有四個或更多個端口，因而消除了網絡瓶頸，允許數據迅速進出。機架內幾乎所有數據流都通過架頂式交換機系統來傳輸(時延低)，因而大大減少了主干網流量。

數據庫

數據庫不一樣。如今***效的系統使用一大批動態隨機存取存儲器(DRAM)雙列直插式內存模塊，建立內存中數據庫。理想情況下，IT部門購買一批定制的新服務器――其中一些服務器的DRAM存儲量高達6TB，不過舊服務器也可以用。

內存中架構的補充機制就是將高速固態硬盤(SSD)存儲系統添加到服務器中。這可以用作DRAM的暫存緩沖區，也可以用作聯網存儲資源。這兩種方法都減輕了網絡負載，但10 GbE網絡可能速度太慢，跟不上買來不到一年的系統，即便每臺服務器兩個端口也是如此。

虛擬化

虛擬化在x86服務器集群中很普遍，它帶來了自己的網絡瓶頸問題。眾所周知，趨于飽和的網絡經常出現啟動風暴(Boot storm);即使在穩定狀態運行中，創建實例也會增添負擔，因為數GB的數據會從聯網存儲系統轉移到服務器。

在這種情形下，就需要將傳統虛擬化技術換成容器模式。這意味著，放棄針對任何操作系統可靈活創建實例的優點，但這通常不是個問題。

容器方案可減少網絡流量，需要服務器中的每個實例使用容器支持的同一個操作系統。單一操作系統和應用程序架構節省了DRAM空間，因而得以讓實例數量翻番，啟動速度很快。不過，如果實例中的應用程序是網絡密集型或輸入/輸出密集型，同樣的壓力還會是出現。

未來的技術對策

使用40 GbE(四通道)鏈路的交換機間連接很常見，我們期望100 GbE代替10 GbE。這股潮流因企業紛紛部署支持四通道的25 GbE鏈路以及部署成本相對低廉的100 GbE鏈路(用于存儲設備和交換機間連接)而水漲船高。

有了25 GbE，數據中心可以使用機架內的現有線纜和交換機間的現有線纜。遺憾的是，你無法改造適配器，而是使用PCIe卡或新的節點。即使如此，盡快更換架頂式交換機以建立10/100 GbE環境，將大大提升整體的集群性能。

這項新技術正在迅速進入市場，體現了云服務提供商們的需要。交付25 GbE鏈路的項目一般問世不到12個月，需要通過IEEE的認證方可上市。用于生產環境的網卡和交換機定于2015年下半年面市。

另外還有50 GbE雙通道這種方案可供選擇。更快的速度有望符合運行內存中大數據分析任務的更龐大服務器，每臺服務器可能至少有兩條鏈路。由于當下的趨勢是，這些服務器和高性能計算系統擁有核心數量眾多的CPU或GPU，預計數據匱乏(data starvation)是個問題，將大量數據裝入到數TB內存所用的時間也是個問題。

基于軟件的解決方案也可以克服瓶頸。軟件定義網絡可以將主干網線路上的工作負載分攤到諸多服務器上。

由于存儲和架構性能迅速提高，網絡會在未來十年成為創新前沿，所以發展步伐應該很迅速。

原文標題：Dissolve a network bottleneck with these techniques