【51CTO.COM 獨家翻譯】通過多隊列技術(shù)，10G以太網(wǎng)的速度可以達到9Gbit/s，我們拿它和用4個千兆網(wǎng)卡端口鏈路集合進行對比，從性能和經(jīng)濟角度來看，四端口鏈路聚合（IEEE 802.3ad）被認為是"最佳點"，但10G以太網(wǎng)比四端口鏈路集合解決方案消耗的CPU周期更少，并且速度也將近其2倍（9.5Gbit/s對比3.8Gbit/s），延遲也更小。

10G以太網(wǎng)卡也不是太貴，最貴的雙口10G以太網(wǎng)卡大約600-700美元，而普通的四端口千兆網(wǎng)卡也要400-500美元，更貴的10G以太網(wǎng)卡（>1000美元）提供的帶寬也更具競爭力（2x10G），每1美元換來的速率和每1瓦電力帶來的速率也更可觀，通常情況下，雙口10G以太網(wǎng)卡的用電量介于6W到14W之間，最好的四口千兆以太網(wǎng)卡耗電量低至4.3W，高的有8.4W。

10G以太網(wǎng)不只是一個更大的網(wǎng)絡(luò)通信管道，它的最大好處不是帶寬，而是通過端口整合降低了總體成本，要理解這一點我們看一下面這張圖便知。

圖 1 機柜中總是充滿了各種電纜

虛擬化服務(wù)器可能需要下面這些I/O端口：

控制臺和管理通信（以太網(wǎng)端口）

VM（虛擬機）遷移（以太網(wǎng)端口）

VM應(yīng)用程序網(wǎng)絡(luò)I/O（以太網(wǎng)端口）

塊存儲I/O（光纖通道端口-FC）

文件存儲I/O（以太網(wǎng)端口）

出于速度和可用性方面的考慮，假設(shè)上述每種通信流量需要2個端口，那么每臺服務(wù)器就需要提供10個端口，如果你部署了基于IP的KVM系統(tǒng)和服務(wù)器遠程管理功能，那還得多準備一些端口。#p#

清理電纜混亂局面

一臺服務(wù)器上裝有6到12塊網(wǎng)卡就很多了，網(wǎng)卡數(shù)量越多，配置也越復(fù)雜，下圖是從VMware/英特爾白皮書中截取來的。

圖 2 物理網(wǎng)卡，端口組和虛擬網(wǎng)卡之間的關(guān)系

白皮書還沒有考慮存儲I/O，如果你使用兩塊FC卡，耗電量也會隨之增加14W（7Wx2），電纜也會多出兩根，我們以這樣一臺重度整合的服務(wù)器為例，最終它：

有10根I/O電纜（無KVM和服務(wù)器管理專用接口）

2塊4端口網(wǎng)卡x 5W+2塊FC卡x 7W=24W

24W并不大，實際上這已經(jīng)是最好的情況，雙插槽服務(wù)器通常需要200-350W，四插槽服務(wù)器則要250-500W，因此I/O功耗約占總功耗的5-15%。

但10根I/O電纜卻是個大問題，端口和電纜越多，配置難度越大，排除故障所花的時間也會越長，不難想象，這種布線會浪費掉系統(tǒng)管理員太多時間，也會浪費掉太多的錢。

最大的問題當(dāng)然是成本，首先，光纖通道電纜不便宜，但它和FC HBA，F(xiàn)C交換機和SFP比起來還是小兒科，每臺服務(wù)器連接8根以太網(wǎng)電纜也不便宜，雖然電纜成本可以忽略不計，但敷設(shè)成本可不能忽略。

整合來救援

解決上述問題的辦法就是"I/O匯聚"或"I/O整合"，即將所有I/O流引入一根電纜，結(jié)果就是使用一套I/O基礎(chǔ)設(shè)施（以太網(wǎng)卡，電纜和交換機）支持所有I/O流，不再用不同的物理接口和電纜，而是在單張網(wǎng)卡（兩張就可以實現(xiàn)故障轉(zhuǎn)移）上整合了所有Vmotion，控制臺，VM通信和存儲通信，極大地降低了復(fù)雜性，耗電量，管理工作量和成本，你可能覺得這話怎么聽起來象是市場營銷人員口中說出來的，沒錯，要做到這一點確實很難。

如果所有通信全部走一根電纜，VM遷移和備份程序產(chǎn)生的流量足以讓存儲通信窒息，整個虛擬集群將會處于半死狀態(tài)，因為存儲通信是集群每個操作的開始和結(jié)束，因此給存儲I/O預(yù)留足夠的帶寬相當(dāng)重要，幸運的是，在現(xiàn)代虛擬化平臺上要做到這一點很簡單，VMware稱之為流量整形，它允許你為某一些VM設(shè)置峰值和平均帶寬限制，只需要將VM加入端口組（Port Group），然后限制端口組的流量即可。對Vmotion流量也可以做類似的限制，只需要限制連接到Vmotion內(nèi)核端口組的vSwitch的流量。

圖 3 VMware流量整形設(shè)置#p#

流量整形對出站通信非常管用，出站通信源于由Hypervisor管理和控制的內(nèi)存空間，它和接收/入站通信完全不是一回事，入站通信首先是由網(wǎng)卡控制的，如果網(wǎng)卡在Hypervisor收到數(shù)據(jù)包之前將其丟掉，入站流量整形就沒意義了。

出站流量整形在所有VMware vSphere版本中均可用，實際上，它屬于標(biāo)準vSwitch中的一個功能，區(qū)分入站和出站流量整形僅在最新的vNetwork分布式交換機（vNetwork Distributed Switch）上可用，這個高級功能只有你具有VMware vSphere企業(yè)增強版許可才能使用。

圖 4 vNetwork分布式交換機

如果使用正確的（虛擬化）軟件和配置整合10G以太網(wǎng)，我們可以將控制臺，存儲（iSCSI，NFS）和普通的網(wǎng)絡(luò)通信整合進兩個高性能的10G以太網(wǎng)卡。

解決虛擬化I/O難題

第一步：IOMMU和VT-d

解決高CPU負載，高延遲和低吞吐量的解決方案分為三個步驟，第一個解決方案是繞過Hypervisor，直接給網(wǎng)絡(luò)密集的VM指定網(wǎng)卡，這種做法有幾個優(yōu)點，VM可以直接訪問本地設(shè)備驅(qū)動程序，因此可以使用各種硬件加速功能，由于網(wǎng)卡還沒有共享，所有隊列和緩沖區(qū)只對一個VM可用。

但是，即使Hypervisor允許VM直接訪問本地驅(qū)動程序，VM無法繞過Hypervisor的內(nèi)存管理，客戶機OS（操作系統(tǒng)）也就不能訪問真實的物理內(nèi)存，只能訪問由Hypervisor管理的虛擬內(nèi)存映射，當(dāng)Hypervisor給驅(qū)動程序發(fā)送地址時，它發(fā)出的是虛擬地址，而不是物理地址（下圖白色箭頭）。

圖 5 客戶機OS只能訪問虛擬地址#p#

英特爾使用VT-d，AMD使用新的IOMMU技術(shù)解決了這個問題，I/O集線器將虛擬或客戶機OS假物理地址（紫色）轉(zhuǎn)換成真實的物理地址（藍色）。新的IOMMU通過給不同的設(shè)備分配不同的物理內(nèi)存子集，實現(xiàn)了不同I/O設(shè)備相互隔離。

虛擬服務(wù)器很少使用這項功能，因為它使虛擬機遷移變成不可能完成的任務(wù)，相反，它們是從底層硬件解耦虛擬機，直接將VM分配給底層硬件，因此AMD IOMMU和英特爾VT-d技術(shù)單獨使用沒有多大用處，這僅僅是I/O虛擬化難題的1/3。

第二步：多隊列

接下來是使網(wǎng)卡變得更強大，而不是讓Hypervisor對所有接收到的數(shù)據(jù)包進行排序，然后再發(fā)送給正確的VM，網(wǎng)卡變成一個完整的硬件開關(guān)，將所有數(shù)據(jù)包排序后放入多個隊列，每個VM一個。

圖 6 虛擬機多隊列傳輸

更少的中斷和CPU負載。如果讓Hypervisor處理數(shù)據(jù)包交換，這意味著CPU 0要被中斷，檢查接收到的數(shù)據(jù)包，并確定目標(biāo)VM，目標(biāo)VM和相關(guān)的CPU立即中斷，使用網(wǎng)卡中的硬件開關(guān)，數(shù)據(jù)包被立即發(fā)送到正確的隊列，相關(guān)CPU立即中斷，并開始接收數(shù)據(jù)包。

更短的延遲。單個隊列負責(zé)接收和轉(zhuǎn)發(fā)多個VM的數(shù)據(jù)包會受不了，因此可能會出現(xiàn)丟包，讓每個VM擁有自己的隊列，吞吐量更高，延遲更低。

雖然虛擬機設(shè)備隊列（Virtual Machine Devices Queues）解決了許多問題，但仍然還有一些CPU開銷存在，每次CPU中斷時，Hypervisor必須從Hypervisor空間將數(shù)據(jù)復(fù)制到VM內(nèi)存空間。

最后的難題：SR-IOV

最后一步是給你多個隊列設(shè)備中的每個隊列添加一些緩沖區(qū)和Rx/Tx描述符，單塊網(wǎng)卡可以偽裝成數(shù)十個"小"網(wǎng)卡，這也是PCI SIG做的工作，它們稱每個小網(wǎng)卡為一個虛函數(shù)（virtual functions，VF），根據(jù)PCI SIG SR-IOV規(guī)范，每塊網(wǎng)卡最大可以提供256個虛函數(shù)（注意：SR-IOV規(guī)范不限于網(wǎng)卡，其它I/O設(shè)備也可以有SR-IOV功能）。

圖 7 具有SR-IOV功能的網(wǎng)卡可以創(chuàng)建多個虛函數(shù)#p#

確保系統(tǒng)中有帶有IOMMU/VT-d的芯片組，最終結(jié)果是，在無Hypervisor的幫助下，每個虛函數(shù)可以DMA數(shù)據(jù)包進出，這意味著CPU從網(wǎng)卡的內(nèi)存空間將數(shù)據(jù)復(fù)制到VM的內(nèi)存空間沒有必要，帶有VT-d/IOMMU功能的芯片組確保虛函數(shù)的DMA傳輸，并且不互相干擾，VM通過標(biāo)準的半虛擬化驅(qū)動程序（如VMware的VMXnet）連接到這些虛函數(shù)，因此你可以任意遷移VM。

難題就這些，多隊列，DMA傳輸虛擬地址到物理地址的轉(zhuǎn)換，以及多頭網(wǎng)卡一起為你提供比模擬硬件更高的吞吐量，更低的延遲和更低的CPU消耗。同時，它們提供了兩個優(yōu)勢使得虛擬仿真硬件變得非常流行：能跨多個VM共享一個硬件設(shè)備，并能夠從底層硬件分離出虛擬機。

SR-IOV支持

當(dāng)然，這是所有理論，直到所有軟件和硬件層一起工作支持，你需要VT-d或IOMMU芯片組，主板BIOS必須識別這些虛函數(shù)，每個虛函數(shù)必須獲得內(nèi)存映射IO空間，如其它PCI設(shè)備，支持SR-IOV的Hypervisor也是必需的。最后，但并非不重要，網(wǎng)卡廠商必須為操作系統(tǒng)和Hypervisor提供SR-IOV驅(qū)動。

在英特爾的強力支持下，支持SR-IOV的開源Hypervisor（Xen，KVM）和商業(yè)產(chǎn)品衍生物（Red Hat，Citrix）已經(jīng)進入市場，截至2009年底，Xen和KVM都支持SR-IOV，更具體地說是英特爾10G以太網(wǎng)82599控制器，它可以提供高達64個虛函數(shù)，Citrix在XenServer 5.6中宣布開始支持SR-IOV，而VMware的ESX和微軟的Hyper-V卻遲遲未支持。

Neterion的解決方案

ESX 5.0和Windows Server 2008的繼任者將支持SR-IOV，由于大多數(shù)數(shù)據(jù)中心的主要Hypervisor是VMware的ESX，這意味著在獲得SR-IOV的好處之前，很大一部分已經(jīng)虛擬化的服務(wù)器將不得不等待一年或更長時間。

圖 8 Neterion網(wǎng)卡

Neterion是多設(shè)備隊列的開創(chuàng)者，除了標(biāo)準的SR-IOV和VMware NetQueue支持外，X3100網(wǎng)卡也含有專利實現(xiàn)。

圖 9 Neterion X3100網(wǎng)卡屬性#p#

專有解決方案只有在它們能提供更多好處時才有意義，Neterion聲稱網(wǎng)卡芯片對網(wǎng)絡(luò)優(yōu)先級和服務(wù)質(zhì)量有廣泛的硬件支持，硬件支持應(yīng)該優(yōu)于Hypervisor流量整形，特別是在接收端，如果突發(fā)流量導(dǎo)致網(wǎng)卡在接收端丟包，Hypervisor什么也做不了，因為它根本就沒見著數(shù)據(jù)包通過。為了強調(diào)這一點，Neterion為X3100配備了64MB接收緩沖區(qū)，而同水平的競爭性產(chǎn)品最大才提供512KB接收緩沖區(qū)，即使網(wǎng)絡(luò)流量相對暴漲，這個巨大的接收緩沖區(qū)應(yīng)確保QoS得到保證。

在IBM，惠普，戴爾，富士通和日立服務(wù)器上均可看到Neterion網(wǎng)卡，Neterion是Exar的子公司，但它擁有自己的分銷渠道，這個網(wǎng)卡的價格大約在745美元左右。

競爭對手：Solarflare

Solarflare是一個相對年輕的公司，成立于2001年，Solarflare的主要宗旨是"讓以太網(wǎng)[銅]變得更好"， Solarflare網(wǎng)卡也支持光學(xué)媒體，但最扯眼球的是它推出的10G以太網(wǎng)銅產(chǎn)品，2006年，Solarflare第一家發(fā)布10G Base-T PHY產(chǎn)品，10G Base-T允許在很常見和便宜的CAT5E，CAT6和CAT6A UTP電纜上實現(xiàn)10Gbit/s的傳輸速度。Solarflare也提倡在HPC領(lǐng)域使用10GbE，并聲稱可以做到讓10GbE的延遲低至4?s。在今年6月，Solarflare發(fā)布了雙端口10G Base-T網(wǎng)卡SFN5121T，功耗12.9W。今年1月，Solarflare決定開始直接面向最終用戶銷售網(wǎng)卡。

圖 10 Solarflare網(wǎng)卡

當(dāng)我們拿到SFP+ Neterion X3120樣品時，我們發(fā)現(xiàn)它和SFN5121T的光學(xué)弟兄產(chǎn)品SFN5122F差不多，這兩款Solarflare網(wǎng)卡均支持SR-IOV，使用的都是PCIe 2.0標(biāo)準，SFP+ SFN5122F功耗非常低，只有4.9W，Solarflare設(shè)計了他們自己的PHY，減少了網(wǎng)卡上的芯片數(shù)量。雖然我們的功率測試方法比較粗糙，但我們可以證實，Solarflare網(wǎng)卡是本次測試三款網(wǎng)卡功耗最低的。

Solarflare的網(wǎng)卡價格也更高一點，網(wǎng)上公開報價大約815美元。

舊網(wǎng)卡

從歷史角度來看總能發(fā)現(xiàn)一些有趣的東西，這些新網(wǎng)卡會不會大比分勝過舊的呢？為此我們測試了有一定歷史的Neterion XFrame-E，我們也嘗試增加支持SR-IOV，有超大接收緩沖區(qū)，更多隊列的英特爾82599，我們將這些網(wǎng)卡插入了超微Twin2進行測試。

基準測試配置

我們拿到的Twin?每個節(jié)點都使用的是相同的網(wǎng)卡，我們使用Ixchariot 5.4和Nttcp做了點對點測試。

圖 11#p#

虛擬化節(jié)點

處理器：英特爾至強E5504（2GHz，四核）和英特爾至強X5670（2.93GHz，六核）

主板：超微X8DTT-IBXF（英特爾5500芯片組）

內(nèi)存：24GB DDR3-1066

硬盤：WD1000FYPS，英特爾X25-E SLC 32GB（用于IOmeter測試）

Hypervisor：VMware ESX 4 b261974（ESX4.0u2）

虛擬化節(jié)點配備了低端的4核和高端的6核測試CPU負載，四個VM使用半虛擬化網(wǎng)絡(luò)驅(qū)動VMXnet，這個虛擬化節(jié)點通過光纖連接到一個幾乎相同的運行Windows Server 2008 R2企業(yè)版的節(jié)點，唯一的不同是CPU，Windows 2008節(jié)點采用的是至強E5540（2.53GHz，四核）。

驅(qū)動

超微AOC-STG-I2（英特爾82598）：ESX默認ixgbe 2.0.38.2.5-NAPI (261974, 24/05/2010)

Neterion x3120 IOV：ESX vxge 2.0.28.21239 (293373, 06/09/2010)

Solarflare Solarstorm SFN5122F：ESX sfc 3.0.5.2179 (16/07/2010)

Neterion xFrame-E：s2io 2.2.16.19752 (23/07/2010)

所有測試都開啟了netqueue。

本地帶寬：Windows Server 2008

我們的首先測試兩個安裝Windows Server 2008 R2企業(yè)版的節(jié)點，我們使用IxChariot 5.4測試吞吐量，執(zhí)行了兩個分項測試：一種是標(biāo)準的以太網(wǎng)幀長度（1.5KB），另一種是9KB巨型幀。所有測試開啟4個線程，Windows Server 2008最有趣的一個增強是接收端縮放（Receive-Side Scaling，RSS），它負責(zé)將接收處理分散到多個CPU核心，RSS在驅(qū)動屬性中啟用。

圖 12 在Windows Server 2008上進行本地帶寬測試的結(jié)果#p#

三個參與測試的網(wǎng)卡在傳輸巨型幀時的表現(xiàn)都很糟糕，巨型幀將每塊網(wǎng)卡的CPU負載從13-14%降低到了10%，但速度僅有5-5.6Gbit/s，讓人相當(dāng)失望。Solarflare和Neterion網(wǎng)卡顯然是為虛擬化環(huán)境制造的，我們使用標(biāo)準以太網(wǎng)幀測試時，Neterion和英特爾網(wǎng)卡的的CPU負載保持在14%左右，而Solarflare網(wǎng)卡需要10%左右的CPU負載，當(dāng)我們開啟巨型幀后，所有網(wǎng)卡都需要大約10%的CPU負載（至強E5504 2GHz）。

圖 13 在Windows Server 2008上進行延遲測試的結(jié)果

Solarflare網(wǎng)卡的延遲比其它的要高，因為Solarflare為Linux開源網(wǎng)絡(luò)堆棧OpenOnload做了許多工作，我們猜測Solarflare聲稱的低延遲是Linux下的網(wǎng)卡延遲，因為在HPC集群世界Linux占據(jù)主導(dǎo)地位，延遲比帶寬更重要，因此Solarflare的做法很有意義。

ESX 4.0性能

讓我們看看這些網(wǎng)卡在虛擬環(huán)境中能做什么，在ESX 4.1中做了一些測試后，我們返回到ESX 4.0u2，因為有大量的驅(qū)動問題，這肯定不是網(wǎng)卡廠商一家的責(zé)任，顯然，VMDirectPath在ESX 4.1中遭到了破壞，幸運的是，已經(jīng)有人提交了BUG報告，相信在update 1中這個問題會得到解決。

我們從Windows Server 2008節(jié)點開始測試NTttcp。

NTttcp -m 4,0, [ip number] -a 4 -t 120

在虛擬節(jié)點上，我們使用Windows 2008創(chuàng)建了4個VM，每個VM開啟4個網(wǎng)絡(luò)負載線程，換句話說就是，總共會有16個活動線程，它們發(fā)送的數(shù)據(jù)包全部都要經(jīng)過一個網(wǎng)卡端口。

圖 14 單虛擬機吞吐量測試#p#

英特爾網(wǎng)卡實現(xiàn)了最高的吞吐量（9.6Gb/s），緊隨其后的是Solarflare（9.2Gb/s）和Neterion X3100（9.1Gb/s），老式的Xframe-E最高極限是3.4Gb/s，前3強在吞吐量方面幾乎不相上下，但從上圖可以看出，Neterion的X3120是唯一一塊跨4個VM實現(xiàn)良好的網(wǎng)絡(luò)流量負載均衡的網(wǎng)卡，所有VM獲得的帶寬幾乎一致（2.2-2.3Gb/s），Solarflare SF5122F和英特爾82598表現(xiàn)也不差，VM獲得的最低帶寬也有1.8Gb/s，使用帶寬測試套件Ixia Chariot 5.4獲得的結(jié)果也是這樣。此外，我們還測量了響應(yīng)時間。

圖 15 半虛擬化響應(yīng)時間

從平均響應(yīng)時間我們可以看出，Neterion網(wǎng)卡以微小的優(yōu)勢勝出，Solarflare SF5122則表現(xiàn)最差，因為有一個VM出現(xiàn)了雙倍延遲。下面再來看看這些網(wǎng)卡在循環(huán)傳輸VM產(chǎn)生的網(wǎng)絡(luò)流量時的CPU負載對比情況，這個測試是在至強E5504（2GHz）和至強X5670（2.93GHz）上完成的，所有CPU的超線程都被禁用了。

圖 16 CPU負載測試

大多數(shù)情況下，9Gb/s的半虛擬化網(wǎng)絡(luò)流量足以拖垮兩顆四核2GHz至強CPU，雖然它是目前最慢的至強處理器，但也很少看到超過8Gb/s的，因此這些10GbE網(wǎng)卡是很耗CPU資源的，Solarflare網(wǎng)卡給低端至強留有一些喘息空間，Neterion網(wǎng)卡為了提供完美的負載均衡服務(wù)，消耗的CPU資源會更多。

但Neterion網(wǎng)卡有一個秘密武器：它是唯一一塊可以在VMware ESX中使用虛函數(shù)的網(wǎng)卡，當(dāng)你使用了虛函數(shù)后，CPU負載一下子就會下降很多，我們的測量結(jié)果是63%，CPU負載越低伴隨著帶寬也會下降。

當(dāng)我們使用最快的至強處理器測試時，結(jié)果發(fā)生了顯著的變化，從上圖可以看出，英特爾和Neterion更好地利用額外的處理核心和更快的時鐘頻率。

整合和窒息

如果我們將存儲、網(wǎng)絡(luò)和管理流量整合進一條或兩條10GbE電纜，一個更簡單，成本更低，更容易管理的數(shù)據(jù)中心就指日可待了，那么新網(wǎng)卡要如何才能應(yīng)付這些I/O需求呢？我們決定使用一個iSCSI啟動器混合連接兩類VM，一個發(fā)送大量存儲通信，其它三個發(fā)送正常的網(wǎng)絡(luò)通信，測試時我們也沒有做優(yōu)化配置，我們只是將一個VM連接到iSCSI啟動器，其它三個則在運行IxChariot。

圖 17 iSCSI混合流量測試

從上圖不難看出，Neterion X3120憑借其獨有的4虛函數(shù)更有效地分散了負載，iSCSI VM在Neterion網(wǎng)卡上要快50%，優(yōu)勢很明顯，讀取磁盤的速度快50%對最終用戶來說意義非同凡響，用戶體驗會完全不一樣。#p#

我們再來看看要控制這種殘酷的網(wǎng)絡(luò)流量需要多少CPU負載，虛擬節(jié)點上的兩個CPU都是至強X5670 2.93GHz。

圖 18 CPU負載測試，3網(wǎng)絡(luò)VM+1 iSCSI QoS

Neterion網(wǎng)卡CPU負載稍微要低一點。

真正的理想狀態(tài)：整合I/O

接下來，我們重新配置了VM：

iSCSI VM以盡可能快的速度運行Iometer；

受限的兩個VM保證可以獲得2Gb/s；

允許使用IxChariot 測試的VM盡可能占用更多的帶寬。

這樣可以避免非受限的VM堵塞iSCSI VM，IxChariot允許我們按時間繪圖，我們想建立一個相互競爭的局面，因此我們決定只限制IxChariot VM。

圖 19

Solarflare和英特爾網(wǎng)卡使用了VMware ESX 4.0出入站流量整形，Neterion網(wǎng)卡使用了硬件QoS和"多函數(shù)"功能。#p#

圖 20

從吞吐量來看，Solarflare和英特爾網(wǎng)卡表現(xiàn)更好，但僅從這個角度來衡量是很片面的，服務(wù)質(zhì)量和流量整形的理想狀態(tài)是保證一定水平的性能，因此我們也應(yīng)當(dāng)重點思考如何讓那2個QoS VM能保證獲得穩(wěn)定的2Gb/s帶寬。

細看服務(wù)質(zhì)量

首先來看英特爾82598。

圖 21 英特爾82598吞吐量變化

從上圖可以看出，藍色和紅色線代表的吞吐量介于0.5-2.2Gb/s之間，由于我們的腳本構(gòu)成了90%的接收幀，但做入站流量整形又沒有多大實際效果，要保持2Gb/s帶寬的確難度很大，Solarflare網(wǎng)卡亦是如此。

圖 22 Solarflare網(wǎng)卡吞吐量變化

重要的是要注意這只是Solarflare SF5122F的一個臨時方案，因為它支持SR-IOV，最大可以提供256個虛函數(shù)，ESX已正式支持SR-IOV，因此SF5122F可以表現(xiàn)得更好。下面來看看Neterion X3120網(wǎng)卡的Neterion SR-IOV。

圖 23

如果我們忽略前面幾秒時間，你可以清楚地看到紅色和藍色線（現(xiàn)在的藍色線代表無QoS的VM）非常接近于2Gb/s，而開啟QoS的兩個VM在最糟糕的情況也達到了1.4Gb/s，大部分時間帶寬都非常接近2Gb/s，網(wǎng)卡中的64MB接收緩沖區(qū)和硬件QoS終于有了回報。#p#

我們的印象

首先討論一下本次評測的限制，英特爾網(wǎng)卡使用的是較舊的82598。

圖 24 參與測試的三塊網(wǎng)卡（左側(cè)是Neterion X3120，中間是Solarflare SFN5122F，右側(cè)是英特爾82598）

對于Windows Server 2008，我不會選擇Solarflare SFN5122F，因為英特爾82598才是最好的選擇，但Solarflare SFN5122F是功耗最低的網(wǎng)卡，并且實現(xiàn)了SR-IOV（256個VF，硬件QoS），因此我們做的測試（無SR-IOV的Windows 2008和ESX 4.0）無法展現(xiàn)這款網(wǎng)卡的真正潛力，如果在KVM和Xen下，開啟SR-IOV功能，加上Linux延時更低的TCP/IP堆棧，SFN5122F的表現(xiàn)會更好。

Neterion X3120除了實現(xiàn)標(biāo)準SR-IOV外，還增加了自己獨有的功能，它率先提供虛函數(shù)功能，Neterion X3120 CPU負載更低，VM帶寬分配更公平（即使沒有QoS），加上大型接收緩沖區(qū)和硬件QoS，它很容易保證關(guān)鍵VM的最低帶寬需求。如果你想實踐SLA，這應(yīng)該會降低成本。Neterion網(wǎng)卡允許你為"一般可預(yù)期的"峰值流量調(diào)整端口數(shù)量和帶寬，在沒有QoS和VF的情況下，你需要增加更多端口滿足極端峰值需要，否則就不能確保關(guān)鍵應(yīng)用程序保持承諾的性能。

X3120也有缺點，它的散熱片比較大，因此是三塊網(wǎng)卡中功耗最大的，這方面Solarflare網(wǎng)卡最棒，此外，Neterion網(wǎng)卡需要更多調(diào)整才能表現(xiàn)得更好，因此Neterion X3120并不是完美的，但它目前絕對是最適合VMware vSphere的，除非你為服務(wù)器配置的功率非常低。

原文出處：http://www.anandtech.com/show/4014/10g-more-than-a-big-pipe

作者：Johan De Gelas

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