【51CTO.COM 独家翻译】通过多队列技术，10G以太网的速度可以达到9Gbit/s，我们拿它和用4个千兆网卡端口链路集合进行对比，从性能和经济角度来看，四端口链路聚合（IEEE 802.3ad）被认为是"最佳点"，但10G以太网比四端口链路集合解决方案消耗的CPU周期更少，并且速度也将近其2倍（9.5Gbit/s对比3.8Gbit/s），延迟也更小。
10G以太网卡也不是太贵，最贵的双口10G以太网卡大约600-700美元，而普通的四端口千兆网卡也要400-500美元，更贵的10G以太网卡（>1000美元）提供的带宽也更具竞争力（2x10G），每1美元换来的速率和每1瓦电力带来的速率也更可观，通常情况下，双口10G以太网卡的用电量介于6W到14W之间，最好的四口千兆以太网卡耗电量低至4.3W，高的有8.4W。
10G以太网不只是一个更大的网络通信管道，它的最大好处不是带宽，而是通过端口整合降低了总体成本，要理解这一点我们看一下面这张图便知。
图 1 机柜中总是充满了各种电缆
虚拟化服务器可能需要下面这些I/O端口：
控制台和管理通信（以太网端口）
VM（虚拟机）迁移（以太网端口）
VM应用程序网络I/O（以太网端口）
块存储I/O（光纤通道端口-FC）
文件存储I/O（以太网端口）
出于速度和可用性方面的考虑，假设上述每种通信流量需要2个端口，那么每台服务器就需要提供10个端口，如果你部署了基于IP的KVM系统和服务器远程管理功能，那还得多准备一些端口。#p#
清理电缆混乱局面
一台服务器上装有6到12块网卡就很多了，网卡数量越多，配置也越复杂，下图是从VMware/英特尔白皮书中截取来的。
图 2 物理网卡，端口组和虚拟网卡之间的关系
白皮书还没有考虑存储I/O，如果你使用两块FC卡，耗电量也会随之增加14W（7Wx2），电缆也会多出两根，我们以这样一台重度整合的服务器为例，最终它：
有10根I/O电缆（无KVM和服务器管理专用接口）
2块4端口网卡x 5W+2块FC卡x 7W=24W
24W并不大，实际上这已经是最好的情况，双插槽服务器通常需要200-350W，四插槽服务器则要250-500W，因此I/O功耗约占总功耗的5-15%。
但10根I/O电缆却是个大问题，端口和电缆越多，配置难度越大，排除故障所花的时间也会越长，不难想象，这种布线会浪费掉系统管理员太多时间，也会浪费掉太多的钱。
最大的问题当然是成本，首先，光纤通道电缆不便宜，但它和FC HBA，FC交换机和SFP比起来还是小儿科，每台服务器连接8根以太网电缆也不便宜，虽然电缆成本可以忽略不计，但敷设成本可不能忽略。
整合来救援
解决上述问题的办法就是"I/O汇聚"或"I/O整合"，即将所有I/O流引入一根电缆，结果就是使用一套I/O基础设施（以太网卡，电缆和交换机）支持所有I/O流，不再用不同的物理接口和电缆，而是在单张网卡（两张就可以实现故障转移）上整合了所有Vmotion，控制台，VM通信和存储通信，极大地降低了复杂性，耗电量，管理工作量和成本，你可能觉得这话怎么听起来象是市场营销人员口中说出来的，没错，要做到这一点确实很难。
如果所有通信全部走一根电缆，VM迁移和备份程序产生的流量足以让存储通信窒息，整个虚拟集群将会处于半死状态，因为存储通信是集群每个操作的开始和结束，因此给存储I/O预留足够的带宽相当重要，幸运的是，在现代虚拟化平台上要做到这一点很简单，VMware称之为流量整形，它允许你为某一些VM设置峰值和平均带宽限制，只需要将VM加入端口组（Port Group），然后限制端口组的流量即可。对Vmotion流量也可以做类似的限制，只需要限制连接到Vmotion内核端口组的vSwitch的流量。
图 3 VMware流量整形设置#p#
流量整形对出站通信非常管用，出站通信源于由Hypervisor管理和控制的内存空间，它和接收/入站通信完全不是一回事，入站通信首先是由网卡控制的，如果网卡在Hypervisor收到数据包之前将其丢掉，入站流量整形就没意义了。
出站流量整形在所有VMware vSphere版本中均可用，实际上，它属于标准vSwitch中的一个功能，区分入站和出站流量整形仅在最新的vNetwork分布式交换机（vNetwork Distributed Switch）上可用，这个高级功能只有你具有VMware vSphere企业增强版许可才能使用。
图 4 vNetwork分布式交换机
如果使用正确的（虚拟化）软件和配置整合10G以太网，我们可以将控制台，存储（iSCSI，NFS）和普通的网络通信整合进两个高性能的10G以太网卡。
解决虚拟化I/O难题
第一步：IOMMU和VT-d
解决高CPU负载，高延迟和低吞吐量的解决方案分为三个步骤，第一个解决方案是绕过Hypervisor，直接给网络密集的VM指定网卡，这种做法有几个优点，VM可以直接访问本地设备驱动程序，因此可以使用各种硬件加速功能，由于网卡还没有共享，所有队列和缓冲区只对一个VM可用。
但是，即使Hypervisor允许VM直接访问本地驱动程序，VM无法绕过Hypervisor的内存管理，客户机OS（操作系统）也就不能访问真实的物理内存，只能访问由Hypervisor管理的虚拟内存映射，当Hypervisor给驱动程序发送地址时，它发出的是虚拟地址，而不是物理地址（下图白色箭头）。
图 5 客户机OS只能访问虚拟地址#p#
英特尔使用VT-d，AMD使用新的IOMMU技术解决了这个问题，I/O集线器将虚拟或客户机OS假物理地址（紫色）转换成真实的物理地址（蓝色）。新的IOMMU通过给不同的设备分配不同的物理内存子集，实现了不同I/O设备相互隔离。
虚拟服务器很少使用这项功能，因为它使虚拟机迁移变成不可能完成的任务，相反，它们是从底层硬件解耦虚拟机，直接将VM分配给底层硬件，因此AMD IOMMU和英特尔VT-d技术单独使用没有多大用处，这仅仅是I/O虚拟化难题的1/3。
第二步：多队列
接下来是使网卡变得更强大，而不是让Hypervisor对所有接收到的数据包进行排序，然后再发送给正确的VM，网卡变成一个完整的硬件开关，将所有数据包排序后放入多个队列，每个VM一个。
图 6 虚拟机多队列传输
更少的中断和CPU负载。如果让Hypervisor处理数据包交换，这意味着CPU 0要被中断，检查接收到的数据包，并确定目标VM，目标VM和相关的CPU立即中断，使用网卡中的硬件开关，数据包被立即发送到正确的队列，相关CPU立即中断，并开始接收数据包。
更短的延迟。单个队列负责接收和转发多个VM的数据包会受不了，因此可能会出现丢包，让每个VM拥有自己的队列，吞吐量更高，延迟更低。
虽然虚拟机设备队列（Virtual Machine Devices Queues）解决了许多问题，但仍然还有一些CPU开销存在，每次CPU中断时，Hypervisor必须从Hypervisor空间将数据复制到VM内存空间。
最后的难题：SR-IOV
最后一步是给你多个队列设备中的每个队列添加一些缓冲区和Rx/Tx描述符，单块网卡可以伪装成数十个"小"网卡，这也是PCI SIG做的工作，它们称每个小网卡为一个虚函数（virtual functions，VF），根据PCI SIG SR-IOV规范，每块网卡最大可以提供256个虚函数（注意：SR-IOV规范不限于网卡，其它I/O设备也可以有SR-IOV功能）。
图 7 具有SR-IOV功能的网卡可以创建多个虚函数#p#
确保系统中有带有IOMMU/VT-d的芯片组，最终结果是，在无Hypervisor的帮助下，每个虚函数可以DMA数据包进出，这意味着CPU从网卡的内存空间将数据复制到VM的内存空间没有必要，带有VT-d/IOMMU功能的芯片组确保虚函数的DMA传输，并且不互相干扰，VM通过标准的半虚拟化驱动程序（如VMware的VMXnet）连接到这些虚函数，因此你可以任意迁移VM。
难题就这些，多队列，DMA传输虚拟地址到物理地址的转换，以及多头网卡一起为你提供比模拟硬件更高的吞吐量，更低的延迟和更低的CPU消耗。同时，它们提供了两个优势使得虚拟仿真硬件变得非常流行：能跨多个VM共享一个硬件设备，并能够从底层硬件分离出虚拟机。
SR-IOV支持
当然，这是所有理论，直到所有软件和硬件层一起工作支持，你需要VT-d或IOMMU芯片组，主板BIOS必须识别这些虚函数，每个虚函数必须获得内存映射IO空间，如其它PCI设备，支持SR-IOV的Hypervisor也是必需的。最后，但并非不重要，网卡厂商必须为操作系统和Hypervisor提供SR-IOV驱动。
在英特尔的强力支持下，支持SR-IOV的开源Hypervisor（Xen，KVM）和商业产品衍生物（Red Hat，Citrix）已经进入市场，截至2009年底，Xen和KVM都支持SR-IOV，更具体地说是英特尔10G以太网82599控制器，它可以提供高达64个虚函数，Citrix在XenServer 5.6中宣布开始支持SR-IOV，而VMware的ESX和微软的Hyper-V却迟迟未支持。
Neterion的解决方案
ESX 5.0和Windows Server 2008的继任者将支持SR-IOV，由于大多数数据中心的主要Hypervisor是VMware的ESX，这意味着在获得SR-IOV的好处之前，很大一部分已经虚拟化的服务器将不得不等待一年或更长时间。
图 8 Neterion网卡
Neterion是多设备队列的开创者，除了标准的SR-IOV和VMware NetQueue支持外，X3100网卡也含有专利实现。
图 9 Neterion X3100网卡属性#p#
专有解决方案只有在它们能提供更多好处时才有意义，Neterion声称网卡芯片对网络优先级和服务质量有广泛的硬件支持，硬件支持应该优于Hypervisor流量整形，特别是在接收端，如果突发流量导致网卡在接收端丢包，Hypervisor什么也做不了，因为它根本就没见着数据包通过。为了强调这一点，Neterion为X3100配备了64MB接收缓冲区，而同水平的竞争性产品最大才提供512KB接收缓冲区，即使网络流量相对暴涨，这个巨大的接收缓冲区应确保QoS得到保证。
在IBM，惠普，戴尔，富士通和日立服务器上均可看到Neterion网卡，Neterion是Exar的子公司，但它拥有自己的分销渠道，这个网卡的价格大约在745美元左右。
竞争对手：Solarflare
Solarflare是一个相对年轻的公司，成立于2001年，Solarflare的主要宗旨是"让以太网[铜]变得更好"， Solarflare网卡也支持光学媒体，但最扯眼球的是它推出的10G以太网铜产品，2006年，Solarflare第一家发布10G Base-T PHY产品，10G Base-T允许在很常见和便宜的CAT5E，CAT6和CAT6A UTP电缆上实现10Gbit/s的传输速度。Solarflare也提倡在HPC领域使用10GbE，并声称可以做到让10GbE的延迟低至4?s。在今年6月，Solarflare发布了双端口10G Base-T网卡SFN5121T，功耗12.9W。今年1月，Solarflare决定开始直接面向最终用户销售网卡。
图 10 Solarflare网卡
当我们拿到SFP+ Neterion X3120样品时，我们发现它和SFN5121T的光学弟兄产品SFN5122F差不多，这两款Solarflare网卡均支持SR-IOV，使用的都是PCIe 2.0标准，SFP+ SFN5122F功耗非常低，只有4.9W，Solarflare设计了他们自己的PHY，减少了网卡上的芯片数量。虽然我们的功率测试方法比较粗糙，但我们可以证实，Solarflare网卡是本次测试三款网卡功耗最低的。
Solarflare的网卡价格也更高一点，网上公开报价大约815美元。
旧网卡
从历史角度来看总能发现一些有趣的东西，这些新网卡会不会大比分胜过旧的呢？为此我们测试了有一定历史的Neterion XFrame-E，我们也尝试增加支持SR-IOV，有超大接收缓冲区，更多队列的英特尔82599，我们将这些网卡插入了超微Twin2进行测试。
基准测试配置
我们拿到的Twin?每个节点都使用的是相同的网卡，我们使用Ixchariot 5.4和Nttcp做了点对点测试。
图 11#p#
虚拟化节点
处理器：英特尔至强E5504（2GHz，四核）和英特尔至强X5670（2.93GHz，六核）
主板：超微X8DTT-IBXF（英特尔5500芯片组）
内存：24GB DDR3-1066
硬盘：WD1000FYPS，英特尔X25-E SLC 32GB（用于IOmeter测试）
Hypervisor：VMware ESX 4 b261974（ESX4.0u2）
虚拟化节点配备了低端的4核和高端的6核测试CPU负载，四个VM使用半虚拟化网络驱动VMXnet，这个虚拟化节点通过光纤连接到一个几乎相同的运行Windows Server 2008 R2企业版的节点，唯一的不同是CPU，Windows 2008节点采用的是至强E5540（2.53GHz，四核）。
驱动
超微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企业版的节点，我们使用IxChariot 5.4测试吞吐量，执行了两个分项测试：一种是标准的以太网帧长度（1.5KB），另一种是9KB巨型帧。所有测试开启4个线程，Windows Server 2008最有趣的一个增强是接收端缩放（Receive-Side Scaling，RSS），它负责将接收处理分散到多个CPU核心，RSS在驱动属性中启用。
图 12 在Windows Server 2008上进行本地带宽测试的结果#p#
三个参与测试的网卡在传输巨型帧时的表现都很糟糕，巨型帧将每块网卡的CPU负载从13-14%降低到了10%，但速度仅有5-5.6Gbit/s，让人相当失望。Solarflare和Neterion网卡显然是为虚拟化环境制造的，我们使用标准以太网帧测试时，Neterion和英特尔网卡的的CPU负载保持在14%左右，而Solarflare网卡需要10%左右的CPU负载，当我们开启巨型帧后，所有网卡都需要大约10%的CPU负载（至强E5504 2GHz）。
图 13 在Windows Server 2008上进行延迟测试的结果
Solarflare网卡的延迟比其它的要高，因为Solarflare为Linux开源网络堆栈OpenOnload做了许多工作，我们猜测Solarflare声称的低延迟是Linux下的网卡延迟，因为在HPC集群世界Linux占据主导地位，延迟比带宽更重要，因此Solarflare的做法很有意义。
ESX 4.0性能
让我们看看这些网卡在虚拟环境中能做什么，在ESX 4.1中做了一些测试后，我们返回到ESX 4.0u2，因为有大量的驱动问题，这肯定不是网卡厂商一家的责任，显然，VMDirectPath在ESX 4.1中遭到了破坏，幸运的是，已经有人提交了BUG报告，相信在update 1中这个问题会得到解决。
我们从Windows Server 2008节点开始测试NTttcp。
NTttcp -m 4,0, [ip number] -a 4 -t 120
在虚拟节点上，我们使用Windows 2008创建了4个VM，每个VM开启4个网络负载线程，换句话说就是，总共会有16个活动线程，它们发送的数据包全部都要经过一个网卡端口。
图 14 单虚拟机吞吐量测试#p#
英特尔网卡实现了最高的吞吐量（9.6Gb/s），紧随其后的是Solarflare（9.2Gb/s）和Neterion X3100（9.1Gb/s），老式的Xframe-E最高极限是3.4Gb/s，前3强在吞吐量方面几乎不相上下，但从上图可以看出，Neterion的X3120是唯一一块跨4个VM实现良好的网络流量负载均衡的网卡，所有VM获得的带宽几乎一致（2.2-2.3Gb/s），Solarflare SF5122F和英特尔82598表现也不差，VM获得的最低带宽也有1.8Gb/s，使用带宽测试套件Ixia Chariot 5.4获得的结果也是这样。此外，我们还测量了响应时间。
图 15 半虚拟化响应时间
从平均响应时间我们可以看出，Neterion网卡以微小的优势胜出，Solarflare SF5122则表现最差，因为有一个VM出现了双倍延迟。下面再来看看这些网卡在循环传输VM产生的网络流量时的CPU负载对比情况，这个测试是在至强E5504（2GHz）和至强X5670（2.93GHz）上完成的，所有CPU的超线程都被禁用了。
图 16 CPU负载测试
大多数情况下，9Gb/s的半虚拟化网络流量足以拖垮两颗四核2GHz至强CPU，虽然它是目前最慢的至强处理器，但也很少看到超过8Gb/s的，因此这些10GbE网卡是很耗CPU资源的，Solarflare网卡给低端至强留有一些喘息空间，Neterion网卡为了提供完美的负载均衡服务，消耗的CPU资源会更多。
但Neterion网卡有一个秘密武器：它是唯一一块可以在VMware ESX中使用虚函数的网卡，当你使用了虚函数后，CPU负载一下子就会下降很多，我们的测量结果是63%，CPU负载越低伴随着带宽也会下降。
当我们使用最快的至强处理器测试时，结果发生了显著的变化，从上图可以看出，英特尔和Neterion更好地利用额外的处理核心和更快的时钟频率。
整合和窒息
如果我们将存储、网络和管理流量整合进一条或两条10GbE电缆，一个更简单，成本更低，更容易管理的数据中心就指日可待了，那么新网卡要如何才能应付这些I/O需求呢？我们决定使用一个iSCSI启动器混合连接两类VM，一个发送大量存储通信，其它三个发送正常的网络通信，测试时我们也没有做优化配置，我们只是将一个VM连接到iSCSI启动器，其它三个则在运行IxChariot。
图 17 iSCSI混合流量测试
从上图不难看出，Neterion X3120凭借其独有的4虚函数更有效地分散了负载，iSCSI VM在Neterion网卡上要快50%，优势很明显，读取磁盘的速度快50%对最终用户来说意义非同凡响，用户体验会完全不一样。#p#
我们再来看看要控制这种残酷的网络流量需要多少CPU负载，虚拟节点上的两个CPU都是至强X5670 2.93GHz。
图 18 CPU负载测试，3网络VM+1 iSCSI QoS
Neterion网卡CPU负载稍微要低一点。
真正的理想状态：整合I/O
接下来，我们重新配置了VM：
iSCSI VM以尽可能快的速度运行Iometer；
受限的两个VM保证可以获得2Gb/s；
允许使用IxChariot 测试的VM尽可能占用更多的带宽。
这样可以避免非受限的VM堵塞iSCSI VM，IxChariot允许我们按时间绘图，我们想建立一个相互竞争的局面，因此我们决定只限制IxChariot VM。
图 19
Solarflare和英特尔网卡使用了VMware ESX 4.0出入站流量整形，Neterion网卡使用了硬件QoS和"多函数"功能。#p#
图 20
从吞吐量来看，Solarflare和英特尔网卡表现更好，但仅从这个角度来衡量是很片面的，服务质量和流量整形的理想状态是保证一定水平的性能，因此我们也应当重点思考如何让那2个QoS VM能保证获得稳定的2Gb/s带宽。
细看服务质量
首先来看英特尔82598。
图 21 英特尔82598吞吐量变化
从上图可以看出，蓝色和红色线代表的吞吐量介于0.5-2.2Gb/s之间，由于我们的脚本构成了90%的接收帧，但做入站流量整形又没有多大实际效果，要保持2Gb/s带宽的确难度很大，Solarflare网卡亦是如此。
图 22 Solarflare网卡吞吐量变化
重要的是要注意这只是Solarflare SF5122F的一个临时方案，因为它支持SR-IOV，最大可以提供256个虚函数，ESX已正式支持SR-IOV，因此SF5122F可以表现得更好。下面来看看Neterion X3120网卡的Neterion SR-IOV。
图 23
如果我们忽略前面几秒时间，你可以清楚地看到红色和蓝色线（现在的蓝色线代表无QoS的VM）非常接近于2Gb/s，而开启QoS的两个VM在最糟糕的情况也达到了1.4Gb/s，大部分时间带宽都非常接近2Gb/s，网卡中的64MB接收缓冲区和硬件QoS终于有了回报。#p#
我们的印象
首先讨论一下本次评测的限制，英特尔网卡使用的是较旧的82598。
图 24 参与测试的三块网卡（左侧是Neterion X3120，中间是Solarflare SFN5122F，右侧是英特尔82598）
对于Windows Server 2008，我不会选择Solarflare SFN5122F，因为英特尔82598才是最好的选择，但Solarflare SFN5122F是功耗最低的网卡，并且实现了SR-IOV（256个VF，硬件QoS），因此我们做的测试（无SR-IOV的Windows 2008和ESX 4.0）无法展现这款网卡的真正潜力，如果在KVM和Xen下，开启SR-IOV功能，加上Linux延时更低的TCP/IP堆栈，SFN5122F的表现会更好。
Neterion X3120除了实现标准SR-IOV外，还增加了自己独有的功能，它率先提供虚函数功能，Neterion X3120 CPU负载更低，VM带宽分配更公平（即使没有QoS），加上大型接收缓冲区和硬件QoS，它很容易保证关键VM的最低带宽需求。如果你想实践SLA，这应该会降低成本。Neterion网卡允许你为"一般可预期的"峰值流量调整端口数量和带宽，在没有QoS和VF的情况下，你需要增加更多端口满足极端峰值需要，否则就不能确保关键应用程序保持承诺的性能。
X3120也有缺点，它的散热片比较大，因此是三块网卡中功耗最大的，这方面Solarflare网卡最棒，此外，Neterion网卡需要更多调整才能表现得更好，因此Neterion X3120并不是完美的，但它目前绝对是最适合VMware vSphere的，除非你为服务器配置的功率非常低。
原文出处：http://www.anandtech.com/show/4014/10g-more-than-a-big-pipe
作者：Johan De Gelas
【51CTO.com独家译稿，非经授权谢绝转载！合作媒体转载请注明原文出处及出处！】
